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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Filesystems]     [Linux SCSI]     [Linux RAID]     [Git]     [Kernel Newbies]     [Linux Newbie]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Samba]     [Device Mapper]

  Powered by Linux