[PATCH RESEND v8 1/4] arm64: arch_timer: Add device tree binding for hisilicon-161010101 erratum

[dingtianhong@huawei.com (Ding Tianhong)]

On 2017/1/19 20:10, Mark Rutland wrote:
> On Thu, Jan 19, 2017 at 07:46:43PM +0800, Ding Tianhong wrote:
>> This erratum describes a bug in logic outside the core, so MIDR can't be
>> used to identify its presence, and reading an SoC-specific revision
>> register from common arch timer code would be awkward.  So, describe it
>> in the device tree.
>>
>> Signed-off-by: Ding Tianhong <dingtianhong@huawei.com>
>> Acked-by: Rob Herring <robh@kernel.org>
>> ---
>>  Documentation/devicetree/bindings/arm/arch_timer.txt | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/arm/arch_timer.txt b/Documentation/devicetree/bindings/arm/arch_timer.txt
>> index ad440a2..9116934 100644
>> --- a/Documentation/devicetree/bindings/arm/arch_timer.txt
>> +++ b/Documentation/devicetree/bindings/arm/arch_timer.txt
>> @@ -31,6 +31,14 @@ to deliver its interrupts via SPIs.
>>    This also affects writes to the tval register, due to the implicit
>>    counter read.
>>  
>> +- hisilicon,erratum-161010101 : A boolean property. Indicates the presence of
>> +  erratum 161010101, which says that reading the counter is unreliable unless
>> +  reading twice on the register and the value of the second read is larger
>> +  than the first by less than 32. If the verification is unsuccessful, then
>> +  discard the value of this read and repeat this procedure until the verification
>> +  is successful.  This also affects writes to the tval register, due to the
>> +  implicit counter read.
> 
> This describes the workaround, which shouldn't be necessary.
> 
> My understanding (from the cover letter) is that reads of the
> {virtual,physical} counters may return a value precisely 32 above the
> true value.
> 
> So it would be better to say:
> 
> - hisilicon,erratum-161010101 : A boolean property. Indicates the
>   presence of Hisilicon erratum 161010101, which says that reading the
>   counters is unreliable in some cases, and reads may return a value 32
>   beyond the correct value. This also affects writes to the tval
>   registers, due to the implicit counter read.
> 
> Thanks,
> Mark.

Looks more accurate.

Thanks.
Ding

> 
> .
>