On 9/12/25 11:27 AM, Krzysztof Kozlowski wrote:

On 12/09/2025 11:21, Konrad Dybcio wrote:

quoted

On 9/12/25 11:17 AM, Krzysztof Kozlowski wrote:

quoted

On 12/09/2025 11:13, Konrad Dybcio wrote:

quoted

On 9/12/25 11:13 AM, Konrad Dybcio wrote:

quoted

On 9/12/25 9:04 AM, Krzysztof Kozlowski wrote:

quoted

On Tue, Sep 09, 2025 at 09:39:11PM +0800, Luo Jie wrote:

quoted

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.

I don't feel like arguing axiology today ;) But I see your point and I
won't object to either outcome, so long as the property is *allowed*

As a sidenote the IPQ SoCs have a rather thin layer of fw

Konrad