Re: [RFC] SATA : Implemented NXP errata A008402

[Ard Biesheuvel <ard.biesheuvel@linaro.org>]

On 11 January 2018 at 02:25, Ni, Ruiyu <ruiyu.ni@intel.com> wrote:
> On 1/10/2018 5:52 PM, Ard Biesheuvel wrote:
>>
>> On 10 January 2018 at 09:43, Udit Kumar <udit.kumar@nxp.com> wrote:
>>>
>>> Hi Ruiyu,
>>>
>>>> -----Original Message-----
>>>>>
>>>>>
>>>>> And this change will not impact any other hardware so no one is
>>>>> basically
>>>>
>>>> impacted by this change.
>>>>
>>>> Your buggy HW only need the value zero. But the addition of PCD exposes
>>>> an interface that can use any size of PRD.
>>>> I am not sure the AtaAtapiPassThru can work if some platform sets the
>>>> PCD
>>>> value to others than 0 or 3F_FFFFh.
>>>
>>>
>>> I don't see someone using this driver will set Pcd randomly, but I agree
>>> on this
>>> point other value should be handled.
>>> Error or Assert could be added, if Pcd value is not 0 or 3F_FFFFh.
>>>
>>>> Can you please
>>>>    just duplicate the AtaAtapiPassThru in your platform?
>>>> Because the driver is very stable today, not much code sync effort will
>>>> be
>>>> needed if core version is changed.
>>>
>>>
>>> Duplicating is always a possibility :), but When we will push this
>>> duplicated driver
>>> (just for one line change) for upstreaming.
>>> will this be acceptable ??
>>
>>
>> My main concern with this (and with using a PCD) is that the setting
>> affects all SATA controllers in the system, including ones the you
>> stick into a PCIe slot.
>>
>> So I think forking the driver is the only possible solution, but it
>> will not be a one-line change: you need to ensure that you apply the
>> workaround only to the SATA controllers in the SoC.
>>
>
> Depending on the new driver's location. The package owner decides
> whether forking is acceptable :)
>

I think forking is reasonable in this case: the workaround does not
belong in generic code, and it seems only early silicon is affected
anyway.