linux-kernel - Re: [PATCH v1 4/8] dt-bindings: timer: Add EcoNet HPT CPU Timer

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <b3fea7b9-b7ea-4987-9fe7-b0adb9346f07@kernel.org>
Date: Mon, 24 Mar 2025 08:13:41 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Caleb James DeLisle <cjd@...ns.fr>, linux-mips@...r.kernel.org
Cc: Thomas Gleixner <tglx@...utronix.de>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
 <conor+dt@...nel.org>, Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
 Daniel Lezcano <daniel.lezcano@...aro.org>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, benjamin.larsson@...exis.eu
Subject: Re: [PATCH v1 4/8] dt-bindings: timer: Add EcoNet HPT CPU Timer

On 24/03/2025 00:53, Caleb James DeLisle wrote:
>>>>> +  compatible:
>>>>> +    const: econet,timer-hpt
>>>> Soc components must have soc-based compatible and then filename matching
>>>> whatever you use as fallback.
>>> I have so far been unable to find good documentation on writing DT bindings
>>> specifically for SoC devices. If you have anything to point me to, I will read it.
>>> If not, even a good example of someone else doing it right is helpful.
>>>
>>> Currently, I see qcom,pdc.yaml appears to do what you say, so I in absence
>>> of any other advice, I can try to do what they do.
>> Just don't use generic fallback.
> 
> 
> Ok I watched your "Accepted in Less Than 10 Iterations" lecture (I'm doing my
> homework). If I understand this correctly, you prefer that I use something specific
> like econet,en751221-timer as the fallback case, so for example on EN751627,
> it would be:
> 
> compatible = "econet,en751627-timer", "econet,en751221-timer";

Yes

> 
> The reason why I didn't do this is because this timer seems to show up in a lot of
> places. Vendor code says that it's older than EN751221, and (if my reading is

Just like every other SoC component for every other SoC.

> correct) it has found it's way into chips branded TrendChip, MediaTek and Ralink
> as well as EcoNet.
> 
> Now that I'll be adding strict checks on the number of register blocks, this way
> also has the advantage of allowing a case for users of the timer in SoCs we don't
> know about:
> 
> // Only valid with 2 register blocks
> compatible = "econet,en751627-timer", "econet,timer-hpt";
> 
> // Only valid with 1 register block
> compatible = "econet,en751612-timer", "econet,timer-hpt";

Above do not differ...

> 
> // No restriction because we don't know how many timers the SoC has
> compatible = "econet,timer-hpt";

How can you not know? This is strictly defined on given hardware.

> 
> 
> That said, I'm fine to do it however you want as long as I'm clear on what you're
> asking for and you have all of the context behind my original decision.

Generic compatible as fallback is accepted if you have evidence that it
is the same IP, with same programming interface, across all these SoCs.
Or if its version is discoverable. If you do not know about other SoC
implementations it is rather a proof that above statement cannot be
fulfilled - you just don't know how it is implemented.


Best regards,
Krzysztof