Re: [PATCH v1] dts: arm64: freescale: move imx9*-clock.h imx9*-power.h into dt-bindings

[Marek Vasut <marek.vasut@mailbox.org>]

On 9/1/25 12:54 PM, Krzysztof Kozlowski wrote:
> On 01/09/2025 12:30, Marek Vasut wrote:
>> On 9/1/25 5:33 AM, Krzysztof Kozlowski wrote:
>>> On 01/09/2025 04:22, Marek Vasut wrote:
>>>> On 9/1/25 5:22 AM, Peng Fan wrote:
>>>>> On Sun, Aug 31, 2025 at 01:04:45PM -0700, E Shattow wrote:
>>>>>> Move imx9*-{clock,power}.h headers into
>>>>>> include/dt-bindings/{clock,power}/ and fix up the DTs
>>>>>
>>>>> No. The files should be under arch/arm64/boot/dts/freescale/
>>>> Why ? Linux already has include/dt-bindings/clock/ and
>>>> include/dt-bindings/power directories for exactly those headers , why
>>>> did iMX9 suddenly start conflating them into arch/arm64/boot/dts/freescale ?
>>>
>>>
>>> Because maybe these are not bindings?
>>
>> Please compare arch/arm64/boot/dts/freescale/imx95-clock.h and
>> include/dt-bindings/clock/imx8mp-clock.h and clarify to me, why the
>> imx95-clock.h is not bindings and the imx8mp-clock.h is bindings.
> 
> That's uno reverse card. I do not have to prove why these are different.
> You need to prove why imx95 are bindings.
> 
>>
>> Both files list clock IDs for the clock nodes, one clock one is SCMI
>> clock (iMX95), the other clock node is CCM clock (iMX8MP), and they are
> 
> Yeah, entirely different things. Like comparing apples and oranges.
> 
>> both (SCMI and CCM) clock nodes in DT. Both header files may have to be
>> included in drivers, the iMX8MP headers already are, the iMX95 headers
> 
> No, the SCMI cannot be used in the drivers, because these are not
> abstract IDs mapping between driver and DTS.

The SCMI clock protocol on iMX9 uses fixed clock IDs (the ones in 
imx95-clock.h), just like the iMX CCM clock driver uses fixed clock IDs 
(the ones in imx8mp-clock.h).

Where does the "SCMI cannot be used in the drivers" come from ? Can you 
elaborate on this part ?

>> currently are included only in U-Boot drivers.
>>
>> I really don't see the difference here, sorry.
> 
> You just pointed out difference - no usage in drivers, no ABI!

Surely at least the SCMI clock protocol clock driver does use those SCMI 
clock IDs , so that is "yes usage in drivers" ?

Also, the SCMI clock protocol clock IDs are being used in U-Boot 
drivers, which does make those IDs an ABI .

> Instead of playing this "I found this code somewhere, so I can do
> whatever the same" answer the first implied question - why these are
> bindings? Provide arguments what do they bind.

I am not sure how to answer this, but what I can write is, that if I 
scramble these IDs in either the DT or the firmware (which provides the 
SCMI clock service), then the system cannot work. I am not sure if this 
is the answer you are looking for.