1. 27 Feb, 2004 31 commits
  2. 26 Feb, 2004 9 commits
    • Jeff Garzik's avatar
      [PATCH] Fix broken PIIX build · 61ee834a
      Jeff Garzik authored
      Fix the build.
      
      Pass me a brown paper bag.
      61ee834a
    • Linus Torvalds's avatar
      Merge bk://kernel.bkbits.net/davem/sparc-2.6 · 4c848133
      Linus Torvalds authored
      into ppc970.osdl.org:/home/torvalds/v2.5/linux
      4c848133
    • Linus Torvalds's avatar
      Merge bk://gkernel.bkbits.net/libata-2.5 · 4915aff2
      Linus Torvalds authored
      into ppc970.osdl.org:/home/torvalds/v2.5/linux
      4915aff2
    • Jeff Garzik's avatar
      [libata ata_piix] Update PCI quirk with new Intel SATA devices · 818c7f39
      Jeff Garzik authored
      And also make a note in ata_piix.c so this is not forgotten
      in the future.
      818c7f39
    • Jeff Garzik's avatar
      [libata ata_piix] add support for ICH6 · 16924d77
      Jeff Garzik authored
      16924d77
    • Jeff Garzik's avatar
      [libata] limit S/G table size to 128 entries · dcc6993c
      Jeff Garzik authored
      Agreeing with Ben H's recommendation, I reduce the max-hw-segments
      number to 128, to match max-phys-segments number.  This shouldn't
      affect performance because 128*64K is far above the max transfer size
      for most current IDE devices.  Even 128*4K is OK.
      dcc6993c
    • Andrew Morton's avatar
      [PATCH] fbdev cursor fix · 87447e7a
      Andrew Morton authored
      From: James Simmons <jsimmons@infradead.org>
      
      This patch creates a separate cursor image drawing region and regular drawing
      region.
      87447e7a
    • Andrew Morton's avatar
      [PATCH] rename other MODULE_VERSION users · 737cff56
      Andrew Morton authored
      Avoid cpp clash with the new MODULE_VERSION
      737cff56
    • Andrew Morton's avatar
      [PATCH] Add a MODULE_VERSION macro · ccec1be4
      Andrew Morton authored
      From: Rusty Russell <rusty@au1.ibm.com>
      
      The way it works is that the .mod file contains the name of the module (as
      before), but succeeding lines are the constituent parts (assumed to be .c
      files, which usually works: if they use MODULE_VERSION in a file for which
      this isn't true we'll get a warning).
      
      As we postprocess modules, we look in the .modinfo section for a
      "version=", which is placed by the MODULE_VERSION() macro.  This will be of
      form "version=<macroarg>" "\0" [24 chars] "\0".  The 24 chars are replaced
      by the md4 sum of the .c files and any files they #include using '#include
      "file"' which are found in the current directory.  Whitespace is collapsed
      outside strings, and comments are ignored for purposes of the sum.
      
      The result is a .modinfo entry such as
      
      	version=1.16ac-rustytest B13E9451C4CA3B89577DEFF
      
      
      
      At the kernel summit, various people asked for a MODULE_VERSION macro to
      store module strings (for later access through sysfs).  A simple md4 is
      needed to identify changes in modules which, inevitably, do not update the
      version.  It skips whitespace and comments, and includes #includes which
      are in the same dir.
      
      The module versions should be set according to this definition, based on
      the RPM one, or CVS Revision tags.  Violators will be shot.
      
       [<epoch>`:']<version>[`-'<extraversion>]
       <epoch>: A (small) unsigned integer which allows you to start versions
                anew. If not mentioned, it's zero.  eg. "2:1.0" is after
           "1:2.0".
       <version>: The <version> may contain only alphanumerics.
       <extraversion>: Like <version>, but inserted for local
                customizations, eg "rh3" or "rusty1".
      
      Comparison of two versions (assuming same epoch):
      
      Split each into all-digit and all-alphabetical parts.  Compare each one one
      at a time: digit parts numerically, alphabetical in ASCII order.  So 0.10
      comes after 0.9.
      ccec1be4