kernel/git/stable/linux.git/drivers/ata, branch linux-2.6.31.y

pata_hpt3x2n: fix clock turnaround

2010-01-06T22:26:29+00:00

commit 256ace9bbd4cdb6d48d5f55d55d42fa20527fad1 upstream. The clock turnaround code still doesn't work for several reasons: - 'USE_DPLL' flag in 'ap->host->private_data' is never initialized or updated, so the driver can only set the chip to the DPLL clock mode, not the PCI mode; - the driver doesn't serialize access to the channels depending on the current clock mode like the vendor drivers, so the clock turnaround is only executed "optionally", not always as it should be; - the wrong ports are written to when hpt3x2n_set_clock() is called for the secondary channel; - hpt3x2n_set_clock() can inadvertently enable the disabled channels when resetting the channel state machines. Signed-off-by: Sergei Shtylyov Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

pata_cmd64x: fix overclocking of UDMA0-2 modes

2010-01-06T22:26:29+00:00

commit 509426bd46ad0903dca409803e0ee3d30f99f1e8 upstream. adev->dma_mode stores the transfer mode value not UDMA mode number so the condition in cmd64x_set_dmamode() is always true and the higher UDMA clock is always selected. This can potentially result in data corruption when UDMA33 device is used, when 40-wire cable is used or when the error recovery code decides to lower the device speed down. The issue was introduced in the commit 6a40da0 ("libata cmd64x: whack into a shape that looks like the documentation") which goes back to kernel 2.6.20. Signed-off-by: Bartlomiej Zolnierkiewicz Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

pata_hpt{37x|3x2n}: fix timing register masks (take 2)

2009-12-18T21:43:27+00:00

commit 5600c70e576199a7552e1c0fff43f3fe16f5566e upstream. These drivers inherited from the older 'hpt366' IDE driver the buggy timing register masks in their set_piomode() metods. As a result, too low command cycle active time is programmed for slow PIO modes. Quite fortunately, it's later "fixed up" by the set_dmamode() methods which also "helpfully" reprogram the command timings, usually to PIO mode 4; unfortunately, setting an UltraDMA mode #N also reprograms already set PIO data timings, usually to MWDMA mode # max(N, 2) timings... However, the drivers added some breakage of their own too: the bit that they set/clear to control the FIFO is sometimes wrong -- it's actually the MSB of the command cycle setup time; also, setting it in DMA mode is wrong as this bit is only for PIO actually and clearing it for PIO modes is not needed as no mode in any timing table has it set... Fix all this, inverting the masks while at it, like in the 'hpt366' and 'pata_hpt366' drivers; bump the drivers' versions, accounting for recent patches that forgot to do it... Signed-off-by: Sergei Shtylyov Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

pata_via: extend the rev_max for VT6330

2009-11-10T00:23:16+00:00

commit 7d948b1114c7eded14e5a31f440af751d70ecde0 upstream. Fix the VT6330 issue, it's because the rev_max of VT6330 exceeds 0x2f. The VT6415 and VT6330 share the same device ID. Signed-off-by: Joseph Chan Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

sata_via: Remove redundant device ID for VIA VT8261

2009-11-10T00:23:16+00:00

commit f38e35b43f2924b3b4e51147b7193f32e9276db4 upstream. Just remove redundant device ID for VIA VT8261. The device ID 0x9000 and 0x9040 are redundant (for VT8261). The 0x9040 is reserved for other usage. Signed-off-by: Joseph Chan Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

pata_sc1200: Fix crash on boot

2009-11-10T00:22:52+00:00

commit 6d4f950e9ea15816c6a4f266ce6b9e438346771e upstream. The SC1200 needs a NULL terminator or it may cause a crash on boot. Bug #14227 Also correct a bogus comment as the driver had serializing added so can run dual port. Signed-off-by: Alan Cox Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

ahci: revert "Restore SB600 sata controller 64 bit DMA"

2009-11-10T00:21:55+00:00

revert commit 58a09b38cfcd700b796ea07ae3d2e0efbb28b561 ("[libata] ahci: Restore SB600 SATA controller 64 bit DMA") Upstream commit 58a09b38cfcd700b796ea07ae3d2e0efbb28b561 does nearly the same thing but this patch is simplified for 2.6.31 Disables 64-bit DMA for _all_ boards, unlike 2.6.32 which adds a whitelist. (The whitelist function requires a fairly large patch that touches unrelated code.) Doesn't revert the DMI part as other backported patches might need the exported symbol. Applies to 2.6.31.4 Signed-off-by: Chuck Ebbert Acked-by: Tejun Heo Signed-off-by: Greg Kroah-Hartman

sata_nv: make sure link is brough up online when skipping hardreset

2009-11-10T00:21:48+00:00

commit 6489e3262e6b188a1a009b65e8a94b7aa17645b7 upstream. prereset doesn't bring link online if hardreset is about to happen and nv_hardreset() may skip if conditions are not right so softreset may be entered with non-working link status if the system firmware didn't bring it up before entering OS code which can happen during resume. This patch makes nv_hardreset() to bring up the link if it's skipping reset. This bug was reported by frodone@gmail.com in the following bug entry. http://bugzilla.kernel.org/show_bug.cgi?id=14329 Signed-off-by: Tejun Heo Reported-by: frodone@gmail.com Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

libata: fix PMP initialization

2009-11-10T00:21:47+00:00

commit 4f7c2874995ac48a4622755b8bd159eb2fb6d8f4 upstream. Commit 842faa6c1a1d6faddf3377948e5cf214812c6c90 fixed error handling during attach by not committing detected device class to dev->class while attaching a new device. However, this change missed the PMP class check in the configuration loop causing a new PMP device to go through ata_dev_configure() as if it were an ATA or ATAPI device. As PMP device doesn't have a regular IDENTIFY data, this makes ata_dev_configure() tries to configure a PMP device using an invalid data. For the most part, it wasn't too harmful and went unnoticed but this ends up clearing dev->flags which may have ATA_DFLAG_AN set by sata_pmp_attach(). This means that SATA_PMP_FEAT_NOTIFY ends up being disabled on PMPs and on PMPs which honor the flag breaks hotplug support. This problem was discovered and reported by Ethan Hsiao. Signed-off-by: Tejun Heo Reported-by: Ethan Hsiao Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

libata: fix internal command failure handling

2009-11-10T00:21:47+00:00

commit f4b31db92d163df8a639f5a8c8633bdeb6e8432d upstream. When an internal command fails, it should be failed directly without invoking EH. In the original implemetation, this was accomplished by letting internal command bypass failure handling in ata_qc_complete(). However, later changes added post-successful-completion handling to that code path and the success path is no longer adequate as internal command failure path. One of the visible problems is that internal command failure due to timeout or other freeze conditions would spuriously trigger WARN_ON_ONCE() in the success path. This patch updates failure path such that internal command failure handling is contained there. Signed-off-by: Tejun Heo Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman