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

Krzysztof Kozlowski krzysztof.kozlowski at linaro.org
Fri Sep 12 02:27:38 PDT 2025


On 12/09/2025 11:21, Konrad Dybcio wrote:
> On 9/12/25 11:17 AM, Krzysztof Kozlowski wrote:
>> On 12/09/2025 11:13, Konrad Dybcio wrote:
>>> On 9/12/25 11:13 AM, 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"?
>>>
>>> "which are in turn necessary for the SoC to function"
>>
>> If this never worked and code was buggy, never booted, was sent
>> incomplete and in junk state, then sure. Say like that. :)
>>
>> But I have a feeling code was working okayish...
> 
> If Linux is unaware of resources, it can't turn them off/on, so it was
> only working courtesy of the previous boot stages messing with them.


Which is fine and present in all other cases/drivers/devices. Entire
Linux in many places relies on bootloader and that is not a "work by
coincidence".

Another thing is if you keep backwards compatibility in the driver but
want to enforce DTS to care about these resources, but that is not
explained here, I think.


Best regards,
Krzysztof



More information about the linux-arm-kernel mailing list