1. 08 12月, 2007 2 次提交
  2. 05 12月, 2007 4 次提交
  3. 02 12月, 2007 8 次提交
  4. 27 11月, 2007 2 次提交
    • T
      libata: bump transfer chunk size if it's odd · e190222d
      Tejun Heo 提交于
      None of the drives I have follows what the standard says about
      transfer chunk size.  Of the four SATA and six PATA ATAPI devices
      tested, four ignore transfer chunk size completely and the ones which
      honor it don't behave according to the spec when it's odd.
      
      According to the spec, transfer chunk size can be odd if the amount of
      data to transfer equals or is smaller than the chunk size and the
      device can indicate the same odd number and transfer the whole thing
      at one go with a pad byte appended.  However, in reality, none of the
      drives I have does that.  They all indicate and transfer even number
      of bytes one byte shorter than the chunk size first; then indicate and
      transfer two bytes, which is clearly out of spec.
      
      In addition to unnecessary second PIO data phase, this also creates a
      weird problem when combined with SATA controllers which perform PIO
      via DMA.  Some of these controllers use actualy number of bytes
      received to update DMA pointer so chunks which are sized 4n + 2 makes
      DMA pointer off by two bytes.  This causes data corruption and buffer
      overruns.
      
      This patch rounds nbytes up to the nearest even number such that ATAPI
      devices don't split data transfer for the last odd byte.  This
      shouldn't confuse controllers which depend on transfer chunk size as
      devices will report the rounded-up number, actually transfer that much
      and padding buffer is there to receive them.
      Signed-off-by: NTejun Heo <htejun@gmail.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      e190222d
    • S
      libata: Return proper ATA INT status in pata_bf54x driver · dc86f6d4
      sonic zhang 提交于
      INT status can be OR.
      Signed-off-by: NSonic Zhang <sonic.zhang@analog.com>
      Signed-off-by: NJeff Garzik <jeff@garzik.org>
      dc86f6d4
  5. 24 11月, 2007 10 次提交
  6. 19 11月, 2007 9 次提交
  7. 10 11月, 2007 1 次提交
  8. 09 11月, 2007 4 次提交