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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
