Jeff Garzik wrote:
Tejun Heo wrote:
This means that we need to make custom readiness tests for controllers
using 0x77 or 0x7f. Eeeek... Both groups of controllers are behaving
in incorrect way. Controllers shouldn't use 0x77 or 0x7f for either
busy or ready states - it's invalid for both, yet, some use the 77/7f
for busy while others use them for ready state. Great. :-(
I think that's assuming too much? PATA and SATA are quite different
here... in PATA the status is mostly the value from the device directly
off the wires. in SATA, it may be from the device or from the
controller. And "smart" or firmware-based controllers may generate
their own status, too, apart from the device's status.
>
So that results in varied status returns, and not all the time is a
definite "ready" or "not ready" obvious.
I think it's pretty safe to say that these weird ready values are from
TF emulation on controller side. The ready/not ready distinction is
probably too simplistic but those values aren't supposed to appear
during post-reset readiness test.
Sorry about the big regression. Heh... It's amazing how all the
controllers I tested didn't show the problem and I did test a good
number of combinations.
I still think it would be better to have a unified readiness test
function. The problem is subtle (device misdetection on hotplug of
certain drives) and went unnoticed quite some time for JMB ahcis && test
coverage over those things can't be good. I'll try to think about
something better.
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
