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
-
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
