linux/drivers/ide, branch v2.6.32

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6

2009-11-30T22:02:34Z

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6: ide: fix ioctl to pass requested transfer mode to ide_find_dma_mode instead of UDMA6

ide: fix ioctl to pass requested transfer mode to ide_find_dma_mode instead of UDMA6

2009-11-25T23:04:54Z

Currently, ide_cmd_ioctl when invoked for setting DMA transfer mode calls ide_find_dma_mode with requested mode as XFER_UDMA_6. This prevents setting DMA mode to any other value than the default (maximum) supported by the device (or UDMA6, if supported) irrespective of the actual requested transfer mode and returns error. For example, setting mode to UDMA2 using hdparm, where UDMA4 is the default transfer mode gives following error: # ./hdparm -d1 -Xudma2 /dev/hda /dev/hda:hda: UDMA/66 mode selected setting using_dma to 1 (on) hda: UDMA/66 mode selected setting xfermode to 66 (UltraDMA mode2) HDIO_DRIVE_CMD(setxfermode) failed: Invalid argument using_dma = 1 (on) This patch fixes the issue. Signed-off-by: Hemant Pedanekar Acked-by: Bartlomiej Zolnierkiewicz Acked-by: Sergei Shtylyov Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6

2009-11-09T17:50:55Z

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6: Revert "ide: try to use PIO Mode 0 during probe if possible"

Revert "ide: try to use PIO Mode 0 during probe if possible"

2009-11-06T12:52:50Z

This reverts commit 6029336426a2b43e4bc6f4a84be8789a047d139e. Ok, we really do need to revert this, even with Bart's sis5513.c fix in there. The problem is that several driver's ->set_pio_mode() method depends upon the drive->media type being set properly. Most of them use this to enable prefetching, which can only be done for disk media. But the commit being reverted here calls ->set_pio_mode() before it's setup. Actually it considers everything disk because that is the default media type set by ide_port_init_devices_data(). The set of drivers that depend upon the media type in their ->set_pio_method() are: drivers/ide/alim15x3.c drivers/ide/it8172.c drivers/ide/it8213.c drivers/ide/pdc202xx_old.c drivers/ide/piix.c drivers/ide/qd65xx.c drivers/ide/sis5513.c drivers/ide/slc90e66.c And it is possible that we could fix this by guarding the prefetching and other media dependent setting changes with a test on IDE_PFLAG_PROBING in hwif->port_flags, that's simply too risky for 2.6.32-rcX and -stable. Signed-off-by: David S. Miller

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6

2009-10-29T16:22:34Z

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6: ide: Serialize CMD643 and CMD646 to fix a hardware bug with SSD

ide: Serialize CMD643 and CMD646 to fix a hardware bug with SSD

2009-10-29T10:02:06Z

CMD646 corrupts data on concurrent transfers on both channels when IDE SSD is connected to one of the channels. Setup that demonstrates this hardware bug: Ultra 5, onboard CMD646, rev 3. /dev/hda is 8GB Seagate ST38410A in MWDMA2 /dev/hdd is 32GB SSD SiliconHardDisk in MWDMA2 - When reading /dev/hdd (for example with dd or fsck), reads from /dev/hda are corrupted, there are twiddled single bits 1->0 and some full 32-bit words corrupted, sometimes commands fail (which switches /dev/hda to PIO mode but the corruptions happen even in PIO). - Reads from /dev/hdd don't seem to be corrupted (i.e. fsck passes fine). - When I connected normal rotating harddisk to /dev/hdd, there was no corruption, so the corruption is something specific to SSD. - I tried the same setup on a PCI card with CMD649 and saw no corruption. This patch serializes the operation for CMD646 and 643 (I didn't test CMD643 but it may have the same hw bug too because it's earlier design). CMD649 is good. I don't know anything about CMD 648. Signed-off-by: Mikulas Patocka Tested-by: Frans Pop Signed-off-by: David S. Miller

ahci / atiixp / pci quirks: rename AMD SB900 into Hudson-2

2009-10-16T10:21:20Z

This patch renames the code name SB900 into Hudson-2 Signed-off-by: Shane Huang Signed-off-by: Jeff Garzik

Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6

2009-10-08T18:59:06Z

* git://git.kernel.org/pub/scm/linux/kernel/git/davem/ide-2.6: Revert "Revert "ide: try to use PIO Mode 0 during probe if possible"" sis5513: fix PIO setup for ATAPI devices

Revert "Revert "ide: try to use PIO Mode 0 during probe if possible""

2009-10-07T11:07:18Z

This reverts commit 24df31acaff8465d797f0006437b45ad0f2a5cb1. The root cause of reported system hangs was (now fixed) sis5513 bug and not "ide: try to use PIO Mode 0 during probe if possible" change (commit 6029336426a2b43e4bc6f4a84be8789a047d139e) so the revert was incorrect (it simply replaced one regression with the other one). Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: David S. Miller

sis5513: fix PIO setup for ATAPI devices

2009-10-07T11:07:17Z

Clear prefetch setting before potentially (re-)enabling it in config_drive_art_rwp() so the transition of the device type on the port from ATA to ATAPI (i.e. during warm-plug operation) is handled correctly. This is a really old bug (it probably goes back to very early days of the driver) but it was only affecting warm-plug operation until the recent "ide: try to use PIO Mode 0 during probe if possible" change (commit 6029336426a2b43e4bc6f4a84be8789a047d139e). Signed-off-by: Bartlomiej Zolnierkiewicz Tested-by: David Fries Signed-off-by: David S. Miller