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>