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

[Jeff Garzik <jeff@garzik.org>]

Tejun Heo wrote:
> Yeah, this is an interesting problem.  There are basically multiple sets
> of TF registers and the SFF way of assuming single set doesn't really
> work well and I don't really think adding ->pmp_read/write is the
> correct long term solution to the problem.  We need to confine direct TF
> register accesses to SFF layer only as controllers which don't implement
> SFF interface may or may not emulate TF registers and even when they do,
> it sometimes can't really match the SFF behavior.

Strongly agreed.


> I wish things are a bit clearer now.  I think the problem here is that
> we're assuming SFF TF access on controllers which aren't really SFF.
> For sil24 and ahci, the driver emulates it and it isn't too difficult.
> The picture gets more interesting for sata_mv as its hardware interface
> much closer to SFF than sil24 or ahci and TF registers matter much more.
>  For ahci and sil24, LLD can just fool libata core layer which assumes
> ubiquitous TF access.  TF registers don't really matter to controller
> operation anyway and feeding bogus values work well.  For sata_mv, it's
> different.  Those registers are integral part of controller operation
> and sata_mv can't really tolerate core layer stepping in w/o notifying LLD.

I would definitely like to move away from the model where non-SFF 
drivers have to emulate SFF in any way.

Re-reviewing the code, I don't see a lot of TF accesses outside of 
SFF-specific code, so we are already in pretty good shape.

I think the picture gets more complicated with sata_mv and similar 
drivers (soon sata_svw, too), because they use the SFF code but only for 
certain TF protocols.  The emulation question is not as clear, with 
those drivers.

	Jeff