Re: [PATCH 11/14] libata-hp-prep: make ops->tf_read() optional

[Tejun Heo <htejun@gmail.com>]

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@gmail.com>
> 
> 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