ChangeSet@1.1543, 2005-01-05 07:06:02-02:00, zaitcev@redhat.com
  [PATCH] USB: Add user defined IDs to ftdi
  
  This should be self-evident. Patch by Rogier Wolff.

ChangeSet@1.1542, 2005-01-04 19:02:18-02:00, khali@linux-fr.org
  [PATCH] I2C: Cleanup a couple media/video drivers
  
  Hi Marcelo, hi all,
  
  Two media/video drivers in 2.4 have a compatibility trick to make them
  work when the kernel tree is patched with i2c 2.8.x. The trick also
  allowed to share the same code between Linux 2.4 and 2.5/2.6.
  Unfortunately, the trick relies on one define (I2C_PEC) to define (or
  not) structure members that are not related with that define at all.
  That define was picked just because it happened to be present in i2c
  2.8.x and the 2.5/2.6 kernel trees, but not in the (unpatched) 2.4
  kernel tree. Basically, the trick was to switch to the new structure
  members (found in i2c 2.8.x and the 2.5/2.6 kernels) if I2C_PEC was
  defined.
  
  The problem now is that i2c 2.9.0, which was just released, has stepped
  back on the changes that had made i2c 2.8.x uncompatible with the 2.4
  kernels, to the great joy of i2c/lm_sensors distro packagers and i2c
  patch maintainer (i.e. me). Because i2c 2.9.0 still defines I2C_PEC but
  uses the old structure members, the trick doesn't work anymore. (No
  surprise, that's what happens when you rely on something to take an
  unrelated decision just because it seems to work at some point.) Since
  the 2.8.x series of i2c is now considered deprecated and unsupported,
  the easiest way to get things back in order is to get rid of the trick
  altogether. This will make i2c 2.9.0 work while breaking i2c 2.8.x,
  which is OK.
  
  The affected drivers are bttv-if and tvmixer. I asked Gerd and he told
  me he had no objection to the cleanups I propose.
  
  Note that both the trick and its removal only have an effect when
  patching the kernel tree with i2c 2.8.0 or later. This means that the
  proposed change is necessarily safe for vanilla kernel users.
  
  Patch follows, please apply. The patch is also available online at:
  http://khali.linux-fr.org/devel/i2c/linux-2.4.28/linux-2.4.28-i2c-2.9.0-drivers-media-video.diff
  
  Thanks.
  
  Signed-off-by: Jean Delvare <khali@linux-fr.org>

ChangeSet@1.1527.3.6, 2004-12-27 15:51:46-05:00, stkn@gentoo.org
  [libata] add #include (fixes 2.4 alpha build)

ChangeSet@1.1527.3.5, 2004-12-27 15:51:34-05:00, albertcc@tw.ibm.com
  [libata] verify ATAPI DMA for a given request is OK
  
  After some testing, it seems that some PATA host adapter (ex. pdc20275) cannot 
  work reliably with specific request buffer sizes under ATAPI DMA mode.
  
  Detailed test result:
  4096, 2048, 1024, 512, 256: OK
  384, 257, 255, 128, 96, 64, 32:  failed (irq lost)
   
  It seems multiple of 256 bytes are the safe ATAPI DMA buffer sizes to use.
  
  Attached please find the patch to fix the pdc2027x ATAPI DMA problem.
  
  Changes:
  1. Add a callback function "check_atapi_dma()" to ata_port_operations such that libata core
  can ask the driver: "Can this command be processed in ATAPI DMA mode safely? " 
  when the the command is received.
  2. ATAPI DMA is off by default if the callback function is not provided by the driver
  
  If the callback function is not provided by the driver, the ATAPI DMA should be as is.
  The ATAPI DMA is already controlled by dev->flags.
  
  BTW, the patch isolates the ATAPI DMA workaround to the pdc20275 driver itself,
  not impacting libata core .
   
  Signed-off-by: Albert Lee <albertcc@tw.ibm.com>

ChangeSet@1.1527.3.4, 2004-12-27 15:51:04-05:00, albertcc@tw.ibm.com
  [libata] PIO error handling improvement
  
  Tested burning CD-RW with libata-dev-2.6 and cdrecord:
  1. ATAPI DMA mode - tested OK
  2. ATAPI PIO mode - test failed when cdrecord finishes burning and issues MODE_SELECT to the device.
  
   After checking the log, it showed that MODE_SELECT caused ata_pio_complete() 
  to return error.
  However, the error is not handled by ata_pio_task().
  
  Attached please find the patch for ata_pio_task() error handling for your review.
    
  Changes in the patch:
  1. End the PIO task when PIO_ST_IDLE state is entered
  2. End the PIO task after PIO_ST_TMOUT and PIO_ST_ERR state handled by ata_pio_error()
  3. Remove the first "if" statement to handle the error condition returned from
     ata_pio_block(), ata_pio_complete() and ata_pio_poll().
  
  Change #2 is not so necessary since ata_pio_error() will put the cmd to  PIO_ST_IDLE state
  after the error condition is handled. The change just saves a function call to queue_work().
  
  Tested OK on on my machine with pdc20275 and ASUS CD-RW drive.
  
  Signed-off-by: Albert Lee <albertcc@tw.ibm.com>

ChangeSet@1.1527.3.3, 2004-12-27 15:46:51-05:00, albertcc@tw.ibm.com
  [libata] use PIO mode for request sense
  
  Signed-off-by: Albert Lee <albertcc@tw.ibm.com>

ChangeSet@1.1527.3.2, 2004-12-27 15:45:49-05:00, jgarzik@pobox.com
  [libata sata_uli] add 5281 support, fix SATA phy setup for others
  
  Contributed by Peer Chen @ ULi and tested by a user.

ChangeSet@1.1527.3.1, 2004-12-27 15:43:33-05:00, jgarzik@pobox.com
  [libata sata_nv] fix dev detect by removing sata-reset flag
  
  Remove ATA_FLAG_SATA_RESET.  See comment in code and
  http://bugme.osdl.org/show_bug.cgi?id=3352 for more details.
  
  This problem needs more investigation.  Removing the flag
  appears to fix the problems in the field, so it's the best
  temporary solution.

ChangeSet@1.1540, 2004-12-27 13:02:06-02:00, a.pugachev@pcs-net.net
  [PATCH] drivers/net/appletalk/Config.in depends on CONFIG_ATALK
  
  This patch makes "Appletalk devices" subscreen menu dependant on CONFIG_ATALK

ChangeSet@1.1539, 2004-12-27 13:00:25-02:00, mhw@wittsend.com
  [PATCH] Computone driver update
  
  Fixed jiffies math in ii2DelayTimer...
  Dumped some groady tracing code that hasn't been used (or tested) in
       years and was only a source of warning messages.
  PCI fixes submitted by Bjorn Helgaas
       Added calls to Add pci_enable_device()/pci_disable_device() per
       submitted patches.  My thanks to Bjorn Helgaas <bjorn.helgaas@hp.com>.
  Yet another shot at the busy board timing window (use the poll timer).
       Because of this, the poll timer is always enabled...
  Cleaned up some comments on immediate interrupt mode (ppp code elsewhere
       has been fixed and the new busy board logic won't throw a hairball).

ChangeSet@1.1538, 2004-12-23 21:33:57-02:00, paulus@samba.org
  [PATCH] PPC64 signal code cleanup
  
  This patch cleans up the signal handling for PPC64 in 2.4.  There was
  some old code in there that was never used, and also the signal
  delivery code was saving some state in the thread_struct (in the
  saved_msr and saved_softe fields).  That is of course bogus because
  the kernel doesn't actually know when the process exits the signal
  handler, and because signal handlers can be nested.  This patch
  dispenses with the use of those thread_struct fields.  It also fixes a
  possible race by using set_current_state (which has a barrier) rather
  than setting current->state directly, removes some unused code,
  removes some debug cruft, and fixes some compile warnings.
  
  Please apply.
  
  Signed-off-by: Paul Mackerras <paulus@samba.org>

ChangeSet@1.1537, 2004-12-22 14:00:27-02:00, ak@suse.de
  [PATCH] [CAN-2004-1144] Fix int 0x80 hole in 2.4 x86-64 linux kernels
  
  Petr Vandrovec discovered an exploitable root hole on all 2.4 x86-64 kernels.
  The problem occurs because the eax register on the 32bit int 0x80 syscall
  handler is not properly 64bit zero extended, which can be used to overflow the
  system call table.
  
  The problem only occurs on 2.4 x86-64 kernels, 2.6 doesn't have this
  hole because some unrelated changes in 2.5 fixed it as a side effect.
  
  Marcelo should be releasing a new pre* kernel with this fix
  shortly, there should be also update kernel from the various
  linux distributions.
  
  It is recommended that everybody who runs a 2.4 x86-64 kernel with
  shell user access updates to a kernel which has this patch applied.
  
  Patch is for 2.4.29pre2, but should apply to pretty much any
  2.4.x x86-64 kernel.
  
  -Andi
  TAG: v2.4.29-pre3