Mark Lord wrote:
Note that, while this does work for sata_mv, I'm still thinking about it.
I'm not totally clear yet (more reading to do) as to how/when
the ATA shadow/taskfile registers get updated to reflect those
for the currently selected pmp..
It would seem that with other parts of libata-sff directly reading
from the ctl, status, and altstatus "registers" during polling,
command setup, and probing, that there might (?) be a loophole
somewhere in this strategy.
Is this scenario going to be possible: somebody calls sata_pmp_read()
as part of, say, hotplug polling, and after that operation completes
we then have code that calls ata_check_status() prior to the next
tf_load / command issue ? If so, they'll see the wrong cached shadow
status register.
..
Answering my own question here: the above scenario really doesn't matter.
They'll see 0x50 in the status register, and be happy regardless.
Because that's what should have been there before the command issue
by sata_pmp_read() in the first place. So not-a-problem.
And for that matter, is it possible for sata_pmp_read() to be called
while the link is active with another command ? Not today, it seems,
but what about when hotplug polling gets implemented ?
..
That's the one I'm most concerned about. Should I be?
-ml
-
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
