Re: new ata_port_operations for .pmp_{read,write} ?

[Mark Lord <liml@rtr.ca>]

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