linux-kernel - Re: [PATCH v3 2/4] dt-bindings: net: Add Loongson-1 Ethernet Controller

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: <d6f796aa-c468-037c-3f53-d0c4306c8890@linaro.org>
Date:   Mon, 28 Aug 2023 09:15:17 +0200
From:   Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
To:     Serge Semin <fancer.lancer@...il.com>
Cc:     Keguang Zhang <keguang.zhang@...il.com>, netdev@...r.kernel.org,
        devicetree@...r.kernel.org, linux-mips@...r.kernel.org,
        linux-kernel@...r.kernel.org, Lee Jones <lee@...nel.org>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Conor Dooley <conor+dt@...nel.org>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Jose Abreu <joabreu@...opsys.com>,
        Serge Semin <Sergey.Semin@...kalelectronics.ru>
Subject: Re: [PATCH v3 2/4] dt-bindings: net: Add Loongson-1 Ethernet
 Controller

On 27/08/2023 23:01, Serge Semin wrote:
> Hi Krzysztof
> 
> On Sun, Aug 27, 2023 at 09:56:06AM +0200, Krzysztof Kozlowski wrote:
>> On 26/08/2023 23:04, Serge Semin wrote:
>>>> +  clock-names:
>>>> +    items:
>>>> +      - const: stmmaceth
>>>
>>>   clock-names:
>>>     const: stmmaceth
>>> ?
>>
> 
>> The existing syntax is correct. This is a string array.
> 
> Could you please clarify whether it's a requirement (always specify
> items: property for an array) or just an acceptable option (another
> one is suggested in my comment)? I am asking because:
> 1. In this case the "clock-names" array is supposed to have only one
> item. Directly setting "const: stmmaceth" with no items: property
> shall simplify it.
> 2. There are single-entry "clock-names" property in the DT-bindings
> defined as I suggested.
> 3. There is a "compatible" property which is also a string array but
> it can be defined as I suggested (omitting the items property).
> 
> so based on all of that using the "items:"-based constraint here seems
> redundant. Am I wrong to think like that? If so in what aspect?

Syntax is correct in both cases. However the single list compatible
*cannot grow*, while single list clock might, when developer notices
that the binding was incomplete. People add binding matching drivers,
not the hardware, thus having incomplete list of clocks is happening all
the time.

Best regards,
Krzysztof