Tejun Heo wrote:
Now I see what you're saying. We should be able to know/clear
interrupt by reading ATA_STATUS. So, not having explicit interrupt
pending bit can be compensated by following changes in ATA_STATUS (so
the state machine), right? Thanks a lot for putting up with my ignorance.
Correct. Just never forget there is a side effect to reading the Status
register -- it clears any interrupt event it also signals.
So, how about a port status bit to tell interrupt handler whether or
not we are expecting an interrupt currently? That would solve the race
from I tried to fix in the first patchset. If that's okay with you,
I'll redo all four patches accordingly.
I'm a bit skeptical, TBH. I would prefer some sort of approach whereby
the code knows where the port is, inside the host state machine, and may
deduce from that "location" whether or not an interrupt is expected.
That's precisely how the code functions now with ATA DMA and non-data,
at least (or should...).
If we find out where the bug in the "I know when I expect an interrupt"
logic is, then your race should be easy to fix. Currently, I can see
that (a) ATAPI interrupt can race with called-immediately EH, and (b)
ATAPI may throw an interrupt to indicate CDB is ready to be sent [see
ATA-4], and libata doesn't yet support such a state in its host state
machine (HSM) implementation.
That said, if you still wish to send such a patch, I will give it an
open and honest review.
Maybe your bit flag approach plugs the hole in the existing HSM -- I
would just like to know _where_ this hole is. So far I don't see it,
except for (a) and (b) ATAPI examples above.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
