Jeff Garzik wrote:
Tejun Heo wrote:
Not all controllers have single TF image and ops->tf_read() is
inappropriate for them. Newly implemented hotplug probing will allow
drivers for such controllers to get rid of ops->tf_read() completely.
Make ops->tf_read() optional in core layer.
Signed-off-by: Tejun Heo <htejun@xxxxxxxxx>
NAK.
At the present time, the controller model expects to be able to obtain
correct values from the shadow registers. For FIS-based controllers,
this may imply that the driver needs to maintain an accurate shadow
register image, if the chip doesn't automatically supply one.
I think this is a quite reasonable expectation, given that ATA continues
to have specifically defined shadow register outputs, and even in the
face of NCQ, we have defined states where the shadow registers are
available.
On this basis, attempts to make ->check_status() optional are also NAK'd.
The reasons why I did this are...
* For controllers which don't maintain shadow register image, the cached
value gets out of sync easily and cause malfunction. In some cases, the
only way is to fake safe values.
* With generic TF access, LLDs cannot determine when TF will be accessed
and why. It must try to keep TF as up-to-date as possible. e.g. sil24
skips TF loading after a qc completion, this makes the cached TF go out
of sync, which can easily cause problems depending on the previous
cached value and how it will be used later.
* With PM, on both AHCI and sil24, each port's TF image must be
cached/faked. I think this would be true for many controllers.
* libata is heading toward high-level ops. At least, that's the plan.
With high-level qc_issue/complete interface, there's no reason for
libata-core layer to access TF directly.
Currently, for FIS-based controllers, the only places where libata-core
layer accesses TF are...
* waiting for !BSY. This is often broken (cache TF gets out of sync,
uncleared previous FIS value...)
* loading qc->result_tf when ATA_QCFLAG_RESULT_TF is set or the qc
failed. As noted above, I think it's best done in LLD completion routine.
I'll drop this and related patches from hotplug series, but I really
don't want to cache/fake TFs for all ports of PM. The cached values
wouldn't be accurate, sometimes values will have to be faked to bypass
TF accesses, and all those should be implemented in LLDs.
Thanks.
--
tejun
-
: 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
