netdev - Re: [PATCH v5 02/10] dt-bindings: clock: Add required "interconnect-cells" property

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 for Android: free password hash cracker in your pocket

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

Message-ID: <1e7d7066-fa0b-4ebc-8f66-e3208bb6f948@quicinc.com>
Date: Tue, 16 Sep 2025 22:03:14 +0800
From: Luo Jie <quic_luoj@...cinc.com>
To: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>,
        Konrad Dybcio
	<konrad.dybcio@....qualcomm.com>
CC: Bjorn Andersson <andersson@...nel.org>,
        Michael Turquette
	<mturquette@...libre.com>,
        Stephen Boyd <sboyd@...nel.org>,
        "Varadarajan
 Narayanan" <quic_varada@...cinc.com>,
        Georgi Djakov <djakov@...nel.org>, "Rob
 Herring" <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        "Conor
 Dooley" <conor+dt@...nel.org>,
        Anusha Rao <quic_anusha@...cinc.com>,
        "Manikanta Mylavarapu" <quic_mmanikan@...cinc.com>,
        Devi Priya
	<quic_devipriy@...cinc.com>,
        Philipp Zabel <p.zabel@...gutronix.de>,
        "Richard
 Cochran" <richardcochran@...il.com>,
        Konrad Dybcio <konradybcio@...nel.org>,
        Catalin Marinas <catalin.marinas@....com>,
        Will Deacon <will@...nel.org>, <linux-arm-msm@...r.kernel.org>,
        <linux-clk@...r.kernel.org>, <linux-kernel@...r.kernel.org>,
        <linux-pm@...r.kernel.org>, <devicetree@...r.kernel.org>,
        <netdev@...r.kernel.org>, <linux-arm-kernel@...ts.infradead.org>,
        <quic_kkumarcs@...cinc.com>, <quic_linchen@...cinc.com>,
        <quic_leiwei@...cinc.com>, <quic_pavir@...cinc.com>,
        <quic_suruchia@...cinc.com>
Subject: Re: [PATCH v5 02/10] dt-bindings: clock: Add required
 "interconnect-cells" property



On 9/12/2025 5:16 PM, Krzysztof Kozlowski wrote:
> On 12/09/2025 11:13, Konrad Dybcio wrote:
>> On 9/12/25 9:04 AM, Krzysztof Kozlowski wrote:
>>> On Tue, Sep 09, 2025 at 09:39:11PM +0800, Luo Jie wrote:
>>>> The Networking Subsystem (NSS) clock controller acts as both a clock
>>>> provider and an interconnect provider. The #interconnect-cells property
>>>> is mandatory in the Device Tree Source (DTS) to ensure that client
>>>> drivers, such as the PPE driver, can correctly acquire ICC clocks from
>>>> the NSS ICC provider.
>>>>
>>>> Although this property is already present in the NSS CC node of the DTS
>>>> for CMN PLL for IPQ9574 SoC which is currently supported, it was previously
>>>> omitted from the list of required properties in the bindings documentation.
>>>> Adding this as a required property is not expected to break the ABI for
>>>> currently supported SoC.
>>>>
>>>> Marking #interconnect-cells as required to comply with Device Tree (DT)
>>>> binding requirements for interconnect providers.
>>>
>>> DT bindings do not require interconnect-cells, so that's not a correct
>>> reason. Drop them from required properties.
>>
>> "Mark #interconnect-cells as required to allow consuming the provided
>> interconnect endpoints"?
> 
> 
> The point is they do not have to be required.

The reason for adding this property as required is to enforce
the DTS to define this important resource correctly. If this property
is missed from the DTS, the client driver such as PPE driver will not
be able to initialize correctly. This is necessary irrespective of
whether these clocks are enabled by bootloader or not. The IPQ9574 SoC
DTS defines this property even though the property was not marked as
mandatory in the bindings, and hence the PPE driver is working.

By now marking it as required, we can enforce that DTS files going
forward for newer SoC (IPQ5424 and later) are properly defining this
resource. This prevents any DTS misconfiguration and improves bindings
validation as new SoCs are introduced.

> 
> Best regards,
> Krzysztof