kernel.git/drivers/ata/libata-core.c, branch linux-2.6.23.y

libata: port and host should be stopped before hardware resources are released

2008-02-08T20:01:47Z

This is backport of 32ebbc0c0d5d18c0135b55d1eb0029f48c54aff0 and fixes oops on driver module unload. Port / host stop calls used to be made from ata_host_release() which is called after all hardware resources acquired after host allocation are released. This is wrong as port and host stop routines often access the hardware. Add separate devres for port / host stop which is invoked right after IRQ is released but with all other hardware resources intact. The devres is added iff ->host_stop and/or ->port_stop exist. This problem has been spotted by Mark Lord. Signed-off-by: Tejun Heo Cc: Mark Lord Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

libata: kill spurious NCQ completion detection

2007-12-14T17:51:15Z

patch 459ad68893a84fb0881e57919340b97edbbc3dc7 in mainline. Spurious NCQ completion detection implemented in ahci was incorrect. On AHCI receving and processing FISes and raising interrupts are not interlocked and spurious interrupts are expected. For example, if an interrupt occurs while interrupt handler is running and the running interrupt handler handles the event the new IRQ indicated, after IRQ handler finishes, it will be executed again because IRQ pending bit is set by the new interrupt but there won't be anything to process. Please read the following message for more information. http://article.gmane.org/gmane.linux.ide/26012 This patch... * Removes all spurious IRQ whining from ahci. Spurious NCQ completion detection was completely wrong. Spurious D2H Register FIS taught us that some early drives send spurious D2H Register FIS with I bit set while NCQ commands are in progress but none of recent drives does that and even the ones which show such behavior can do NCQ fine. * Kills all NCQ blacklist entries which were added because of spurious NCQ completions. I tracked down each commit and verified all removed ones are actually added because of spurious completions. WD740ADFD-00NLR1 wasn't deleted but moved upward because the drive not only had spurious NCQ completions but also is slow on sequential data transfers if NCQ is enabled. Maxtor 7V300F0 was added by 0e3dbc01d53940fe10e5a5cfec15ede3e929c918 from Alan Cox. I can only find evidences that the drive only had troubles with spuruious completions by searching the mailing list. This entry needs to be verified and removed if it doesn't have other NCQ related problems. Signed-off-by: Tejun Heo Cc: Alan Cox Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

libata: add HTS542525K9SA00 to NCQ blacklist

2007-11-16T17:30:24Z

patch e14cbfa630cd3ab2631ee21b718b290928f47868 in mainline. Another one doing spurious NCQ completions. Blacklist it. Signed-off-by: Tejun Heo Cc: Luca Tettamanti Signed-off-by: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

libata: sync NCQ blacklist with upstream

2007-11-16T17:30:21Z

Synchronize NCQ blacklist with the current upstream. Based on changes already in Linus's 2.6.24-rc kernel tree. Signed-off-by: Tejun Heo Cc: Jeff Garzik Signed-off-by: Greg Kroah-Hartman

libata: Update the blacklist with a few more devices

2007-09-20T19:58:26Z

Signed-off-by: Alan Cox Signed-off-by: Jeff Garzik

libata clear horkage on ata_dev_init()

2007-09-11T02:07:42Z

dev->horkage should be cleared over device hotunplug/plug. Clear it in ata_dev_init(). Signed-off-by: Tejun Heo Signed-off-by: Jeff Garzik

libata: implement BROKEN_HPA horkage and apply it to affected drives

2007-08-31T08:21:13Z

Some drives choke on READ_NATIVE_MAX_ADDRESS[_EXT]. Implement ATA_HORKAGE_BROKEN_HPA and apply it to affected drives. Signed-off-by: Tejun Heo Signed-off-by: Jeff Garzik

libata-core: Allow translation setting to fail

2007-08-31T07:37:55Z

On some early drives (pre ATA1) this feature is not supported. If it fails then we know the drive geometry is the hardware geometry and the one we tried to set anyway so just carry on. Signed-off-by: Alan Cox Signed-off-by: Jeff Garzik

libata: don't check n_sectors during revalidation if zero

2007-08-23T09:34:05Z

If the initial configuration fails early, n_sectors is left at zero. Checking against it during revalidation makes retried configuration fail due to n_sectors mismatch. Ignore zero n_sectors during revalidation. Signed-off-by: Tejun Heo Signed-off-by: Jeff Garzik

libata: fix n_sectors failure handling during revalidation

2007-08-23T09:23:14Z

If revalidation fails because device has different n_sectors after configuration the original n_sectors should be restored before failing revalidation. Without this fix, n_sectors difference will incorrectly and silently pass revalidation when revalidation is retried. Signed-off-by: Tejun Heo Acked-by: Alan Cox Signed-off-by: Jeff Garzik