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] [day] [month] [year] [list]

Message-ID: <f4bb786d-09b2-4237-84bd-cdfe297f8165@cjdns.fr>
Date: Mon, 24 Mar 2025 13:25:27 +0100
From: Caleb James DeLisle <cjd@...ns.fr>
To: Krzysztof Kozlowski <krzk@...nel.org>, 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 08:13, Krzysztof Kozlowski wrote:
> 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.
>
I mean I don't know, the person writing the DTS for that SoC needs to know.


Per your preference, I'll do the following:


// 2 blocks accepted

compatible = "econet,en751627-timer", "econet,en751221-timer";

// 1 block accepted

compatible = "econet,en751221-timer";


If someone has an SoC with more than 2 timers, it is not supported so they
should update the binding, or (in downstream) they might write an invalid
DTS. FWIW I have no evidence of any >2 core processor which uses this, so
2 timers is probably the maximum.


Lastly I'll change the driver name to timer-econet-en751221.c to avoid the
proliferation of different names.


Thanks,

Caleb