libata: improve 0xff status handling
For PATA, 0xff status indicates empty port. For SATA, it depends on
how the controller emulates status register. On some controllers,
0xff is used to represent broken link or certain stage during reset.
libata currently deals SATA the same. This hasn't caused any problem
because problematic situations usually only occur after hotplug or
other link disruption events and libata blindly waited for the device
to spin up and settle after hotplug giving the link and device
whatever time to go through those stages.
libata is going to replace unconditional spinup wait with generic
timed sequence of resets, so not only getting 0xff handling right for
SATA is, well, the right thing to do, it's much more important now.
This patch makes the following changes.
* Make ata_bus_softreset() return -ENODEV if any of its wait fails
due to 0xff status.
* Fail soft/hardreset if status wait returns -ENODEV indicating 0xff
status while SStatus says the link is online. e.g. Reset fails if
status is 0xff after reset when SStatus reports the linke is online.
If SCR registers are not available, everything is the same as
before.
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
diff --git a/drivers/ata/sata_inic162x.c b/drivers/ata/sata_inic162x.c
index 25b747e..b3b62e9 100644
--- a/drivers/ata/sata_inic162x.c
+++ b/drivers/ata/sata_inic162x.c
@@ -453,7 +453,8 @@
msleep(150);
rc = ata_wait_ready(ap, deadline);
- if (rc && rc != -ENODEV) {
+ /* link occupied, -ENODEV too is an error */
+ if (rc) {
ata_port_printk(ap, KERN_WARNING, "device not ready "
"after hardreset (errno=%d)\n", rc);
return rc;