dts: arm64: freescale: move imx9-clock.h imx9-power.h into dt-bindings

PATCH In review E Shattow 5 participants 16 messages Aug 31, 2025 – Nov 2, 2025

Subsystems (4)

Device tree bindings Arm i.MX and Layerscape Common clk NXP i.MX clock drivers

lore

Share & tools

lore

E Shattow

author

2025-08-31 20:06 UTC #0 lore raw

PATCH 1/1 dts: arm64: freescale: move imx9*-clock.h imx9*-power.h into dt-bindings

Move imx9*-{clock,power}.h headers into include/dt-bindings/{clock,power}/ and fix up the DTs

Reported-by Marek Vasut <[email protected]>

Signed-off-by E Shattow <[email protected]>

---
 arch/arm64/boot/dts/freescale/imx94.dtsi                      | 4 ++--
 arch/arm64/boot/dts/freescale/imx95.dtsi                      | 4 ++--
 .../dts/freescale => include/dt-bindings/clock}/imx94-clock.h | 0
 .../dts/freescale => include/dt-bindings/clock}/imx95-clock.h | 0
 .../dts/freescale => include/dt-bindings/power}/imx94-power.h | 0
 .../dts/freescale => include/dt-bindings/power}/imx95-power.h | 0
 6 files changed, 4 insertions(+), 4 deletions(-)
 rename {arch/arm64/boot/dts/freescale => include/dt-bindings/clock}/imx94-clock.h (100%)
 rename {arch/arm64/boot/dts/freescale => include/dt-bindings/clock}/imx95-clock.h (100%)
 rename {arch/arm64/boot/dts/freescale => include/dt-bindings/power}/imx94-power.h (100%)
 rename {arch/arm64/boot/dts/freescale => include/dt-bindings/power}/imx95-power.h (100%)

arch/arm64/boot/dts/freescale/imx94.dtsi +2 -2

index 44dee2cbd42d..1fe6ef4518a8 100644
@@ -8,9 +8,9 @@
 #include <dt-bindings/input/input.h>
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 
-#include "imx94-clock.h"
+#include <dt-bindings/clock/imx94-clock.h>
 #include "imx94-pinfunc.h"
-#include "imx94-power.h"
+#include <dt-bindings/power/imx94-power.h>
 
 / {
 	#address-cells = <2>;

arch/arm64/boot/dts/freescale/imx95.dtsi +2 -2

index 4ca6a7ea586e..787d3f829816 100644
@@ -10,9 +10,9 @@
 #include <dt-bindings/interrupt-controller/arm-gic.h>
 #include <dt-bindings/thermal/thermal.h>
 
-#include "imx95-clock.h"
+#include <dt-bindings/clock/imx95-clock.h>
 #include "imx95-pinfunc.h"
-#include "imx95-power.h"
+#include <dt-bindings/power/imx95-power.h>
 
 / {
 	interrupt-parent = <&gic>;

include/dt-bindings/clock/imx94-clock.h renamed from arch/arm64/boot/dts/freescale/imx94-clock.h +0 -0

similarity index 100%
rename from arch/arm64/boot/dts/freescale/imx94-clock.h
rename to include/dt-bindings/clock/imx94-clock.h

include/dt-bindings/clock/imx95-clock.h renamed from arch/arm64/boot/dts/freescale/imx95-clock.h +0 -0

similarity index 100%
rename from arch/arm64/boot/dts/freescale/imx95-clock.h
rename to include/dt-bindings/clock/imx95-clock.h

include/dt-bindings/power/imx94-power.h renamed from arch/arm64/boot/dts/freescale/imx94-power.h +0 -0

similarity index 100%
rename from arch/arm64/boot/dts/freescale/imx94-power.h
rename to include/dt-bindings/power/imx94-power.h

include/dt-bindings/power/imx95-power.h renamed from arch/arm64/boot/dts/freescale/imx95-power.h +0 -0

similarity index 100%
rename from arch/arm64/boot/dts/freescale/imx95-power.h
rename to include/dt-bindings/power/imx95-power.h

base-commit: 5c3b3264e5858813632031ba58bcd6e1eeb3b214

Signature · 1 line

2.50.0

Peng Fan

2025-09-01 02:10 UTC #1 lore raw

Quoted 2 lines · E Shattow

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/ What issue are you trying to fix?

Regards
Peng

Marek Vasut

2025-09-01 02:23 UTC #2 lore raw

Quoted 5 lines · Peng Fan

Quoted 2 lines · E Shattow
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 ?

Krzysztof Kozlowski

2025-09-01 03:34 UTC #3 lore raw

Quoted 9 lines · Marek Vasut

Quoted 5 lines · Peng Fan
Quoted 2 lines · E Shattow
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? Regardless whether you agree or not, the commit should clearly explain the reason behind.

Best regards,
Krzysztof

Peng Fan

reviewer

2025-09-01 06:09 UTC #4 lore raw

Quoted 9 lines

Subject: Re: [PATCH v1] dts: arm64: freescale: move imx9*-clock.h imx9*-power.h into dt-bindings
Quoted 5 lines · Marek Vasut
Quoted 4 lines · Peng Fan
Quoted 2 lines · E Shattow
Move imx9*-{clock,power}.h headers into include/dt-bindings/{clock,power}/ and fix up the DTs

Quoted 8 lines

Quoted 4 lines
Quoted 1 line
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?

Right. These IDs are firmware exported entries, not bindings.

Thanks,
Peng.

Regardless whether you agree

Quoted 5 lines

or not, the commit should clearly explain the reason behind.
Best regards,
Krzysztof

Marek Vasut

2025-09-01 10:30 UTC #5 lore raw

In reply to Krzysztof Kozlowski

Quoted 6 lines · Krzysztof Kozlowski

Quoted 5 lines · Marek Vasut
Quoted 4 lines · Peng Fan
Quoted 2 lines · E Shattow
Move imx9*-{clock,power}.h headers into include/dt-bindings/{clock,power}/ and fix up the DTs

Quoted 7 lines

Quoted 4 lines
Quoted 1 line
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.

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 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 currently are included only in U-Boot drivers.

I really don't see the difference here, sorry.

Quoted 2 lines

Regardless whether you agree or
not, the commit should clearly explain the reason behind.

Which commit ?

Krzysztof Kozlowski

2025-09-01 10:54 UTC #6 lore raw

Quoted 13 lines · Marek Vasut

Quoted 12 lines · Krzysztof Kozlowski
Quoted 9 lines · Marek Vasut
Quoted 5 lines · Peng Fan
Quoted 2 lines · E Shattow
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 ?

Quoted 5 lines

Quoted 1 line
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.

Quoted 3 lines

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.

Quoted 2 lines

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.

Quoted 3 lines

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!

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.

Quoted 4 lines

Quoted 3 lines
Regardless whether you agree or
not, the commit should clearly explain the reason behind.
Which commit ?

This patch.

Best regards,
Krzysztof

E Shattow

author

2025-09-01 11:07 UTC #7 lore raw

Quoted 48 lines · Krzysztof Kozlowski

Quoted 13 lines · Marek Vasut
Quoted 12 lines · Krzysztof Kozlowski
Quoted 9 lines · Marek Vasut
Quoted 5 lines · Peng Fan
Quoted 2 lines · E Shattow
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 ?
Quoted 5 lines
Quoted 1 line
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.
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 3 lines
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!
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.
Quoted 3 lines
Quoted 3 lines
Regardless whether you agree or
not, the commit should clearly explain the reason behind.

Quoted 7 lines

Quoted 1 line
Which commit ?
This patch.
Best regards,
Krzysztof

Providing some clarification, the user of this (in U-Boot) via devicetree-rebasing leads to some path gymnastics:

(U-Boot code base) arch/arm/mach-imx/imx9/scmi/clock.c:9:#include "../../../../../dts/upstream/src/arm64/freescale/imx95-clock.h"

Compared to the patterns of what else is going on I would guess this should instead be:

#include <dt-bindings/clock/imx95-clock.h>

which agrees with how it is done for all the other closely similar build targets and is less fragile in that build context (although you may not be interested in this since it's not Linux kernel code base). Ideally I'm trying to make U-Boot flexible to build against different locations of devicetree-rebasing or perhaps Linux kernel source tree. This is a "one thing is not like the others" moment and it was suggested I send a patch.

Whatever is best I'm open to improve the commit message, or take what you think ought to be fixed in U-Boot there to improve.

What do we expect users of devicetree-rebasing to do, then?

Thanks,

E Shattow

Krzysztof Kozlowski

2025-09-01 12:15 UTC #8 lore raw

Quoted 56 lines · E Shattow

Quoted 53 lines · Krzysztof Kozlowski
Quoted 13 lines · Marek Vasut
Quoted 12 lines · Krzysztof Kozlowski
Quoted 9 lines · Marek Vasut
Quoted 5 lines · Peng Fan
Quoted 2 lines · E Shattow
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 ?
Quoted 5 lines
Quoted 1 line
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.
Quoted 3 lines
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.
Quoted 2 lines
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.
Quoted 3 lines
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!
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.
Quoted 4 lines
Quoted 3 lines
Regardless whether you agree or
not, the commit should clearly explain the reason behind.
Which commit ?
This patch.

Quoted 8 lines

Quoted 2 lines
Best regards,
Krzysztof
Providing some clarification, the user of this (in U-Boot) via devicetree-rebasing leads to some path gymnastics:
(U-Boot code base) arch/arm/mach-imx/imx9/scmi/clock.c:9:#include "../../../../../dts/upstream/src/arm64/freescale/imx95-clock.h"

Why nothing like this was described in the commit msg? We really do not need lengthy discussions to discover the basic needs why patch is being sent.

Anyway, U-boot driver requesting clocks in C code not via DTS is the culprit here and not necessarily right approach.

Quoted 6 lines

Compared to the patterns of what else is going on I would guess this should instead be:
#include <dt-bindings/clock/imx95-clock.h>

Quoted 7 lines

which agrees with how it is done for all the other closely similar build targets and is less fragile in that build context (although you may not be interested in this since it's not Linux kernel code base). Ideally I'm trying to make U-Boot flexible to build against different locations of devicetree-rebasing or perhaps Linux kernel source tree. This is a "one thing is not like the others" moment and it was suggested I send a patch.

Why instead not fixing U-boot and not taking these via DT property, like every other case? see include/clk.h for the API.

Quoted 3 lines

Whatever is best I'm open to improve the commit message, or take what you think ought to be fixed in U-Boot there to improve.

You should rather align with other U-boot maintainers and contributors how clock consumers should be written. Proposed patches depend on that outcome. If you just ask me, then I am telling you the same - requesting clocks by consumers should be via DT, not via C code. Someone just added ABI for driver consumers, not even providers...

Best regards,
Krzysztof

Marek Vasut

2025-09-01 23:32 UTC #9 lore raw

In reply to Krzysztof Kozlowski

Quoted 27 lines · Krzysztof Kozlowski

Quoted 13 lines · Marek Vasut
Quoted 12 lines · Krzysztof Kozlowski
Quoted 9 lines · Marek Vasut
Quoted 5 lines · Peng Fan
Quoted 2 lines · E Shattow
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 ?
Quoted 5 lines
Quoted 1 line
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.
Quoted 3 lines
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

Quoted 7 lines

Yeah, entirely different things. Like comparing apples and oranges.
Quoted 2 lines
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 ?

Quoted 5 lines

Quoted 3 lines
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 .

Quoted 3 lines

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.

Peng Fan

2025-09-04 08:23 UTC #10 lore raw

On Tue, Sep 02, 2025 at 01:32:38AM +0200, Marek Vasut wrote:
[snip]

Quoted 8 lines

Instead of playing this "I found this code somewhere, so I can do
Quoted 2 lines
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.

Marek,
Some U-Boot code indeed directly use the IDs to configure the clock without relying on any drivers. Since the SCMI IDs could not be moved to dt-bindings, the possible method to do in U-Boot is to duplicate a copy of the file, and highlight this files should be aligned with the ones under dts/upstream/src/arm64/freescale/imx95-*.h.

Regards
Peng

Marek Vasut

2025-09-08 23:39 UTC #11 lore raw

On 9/4/25 11:34 AM, Peng Fan wrote:

Hi,

sorry for my late reply.

Quoted 4 lines

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

Quoted 8 lines

Quoted 4 lines
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.
Marek,
Some U-Boot code indeed directly use the IDs to configure the clock without relying on any drivers. Since the SCMI IDs could not be moved to dt-bindings,

Why can they not be moved to DT bindings ?

They are part of the ABI.

This is the part I do not understand, the SCMI IDs are no different than any other clock IDs used in DT, is that not so ?

Quoted 1 line

the possible method to do in U-Boot is to duplicate a copy of the file,

No.

Peng Fan

reviewer

2025-09-10 07:07 UTC #12 lore raw

Hi Marek,

Quoted 19 lines

Subject: Re: [PATCH v1] dts: arm64: freescale: move imx9*-clock.h imx9*-power.h into dt-bindings
On 9/4/25 11:34 AM, Peng Fan wrote:
Hi,
sorry for my late reply.
Quoted 2 lines
Quoted 2 lines
Instead of playing this "I found this code somewhere, so I can do
Quoted 1 line
whatever the same" answer the first implied question - why these
are
Quoted 7 lines
Quoted 6 lines
Quoted 1 line
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.

Quoted 7 lines

Quoted 2 lines
Marek,
Some U-Boot code indeed directly use the IDs to configure the clock
without
Quoted 2 lines
relying on any drivers. Since the SCMI IDs could not be moved to
dt-bindings,
Why can they not be moved to DT bindings ?

DT maintainers suggested to keep the files under
arch/arm64/boot/dts/freescale/

https://lore.kernel.org/all/[email protected]/

Regards
Peng

E Shattow

author

2025-10-02 05:27 UTC #13 lore raw

Quoted 29 lines · Peng Fan

Hi Marek,
Quoted 19 lines
Subject: Re: [PATCH v1] dts: arm64: freescale: move imx9*-clock.h imx9*-power.h into dt-bindings
On 9/4/25 11:34 AM, Peng Fan wrote:
Hi,
sorry for my late reply.
Quoted 2 lines
Quoted 2 lines
Instead of playing this "I found this code somewhere, so I can do
Quoted 1 line
whatever the same" answer the first implied question - why these
are
Quoted 7 lines
Quoted 6 lines
Quoted 1 line
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.
Quoted 7 lines
Quoted 2 lines
Marek,
Some U-Boot code indeed directly use the IDs to configure the clock
without
Quoted 2 lines
relying on any drivers. Since the SCMI IDs could not be moved to
dt-bindings,
Why can they not be moved to DT bindings ?

Quoted 7 lines

DT maintainers suggested to keep the files under
arch/arm64/boot/dts/freescale/
https://lore.kernel.org/all/[email protected]/
Regards
Peng

Follow up FYI to all this is resolved from U-Boot [1] as not using the header and duplicating the information.

1:
https://lore.kernel.org/u-boot/[email protected]/

There was yet some IRC discussion about what justification can be for avoiding this maintenance and duplication.

I am dropping this suggestion to move imx9*-clock.h imx9*-power.h into dt-bindings. There is some better way of doing this, maybe a future dt-firmware includes? That is not at all my area of interest or expertise, however. I just noticed something out-of-place and bring it to our attention.

My great appreciation is due for the reviews and discussion about this. Thanks, everyone!

-E

Marek Vasut

2025-11-02 17:42 UTC #14 lore raw

In reply to Peng Fan

On 9/10/25 9:07 AM, Peng Fan wrote:

Hello Peng,

Quoted 6 lines

Quoted 6 lines
Quoted 2 lines
Marek,
Some U-Boot code indeed directly use the IDs to configure the clock
without
Quoted 2 lines
relying on any drivers. Since the SCMI IDs could not be moved to
dt-bindings,

Quoted 6 lines

Quoted 1 line
Why can they not be moved to DT bindings ?
DT maintainers suggested to keep the files under
arch/arm64/boot/dts/freescale/
https://lore.kernel.org/all/[email protected]/

I think the larger question really is -- are the SCMI clock IDs part of DT ABI or not ? The SCMI clock IDs are part of firmware ABI, for sure. Does that imply they are part of DT ABI too ?

Or, is there by any chance a plan to allow e.g. resolution of SCMI clock IDs by their shortnames, and allow SCMI clock IDs to change across different firmware versions, even on the same platform ?

Signature · 2 lines

Best regards,
Marek Vasut

Krzysztof Kozlowski

2025-09-01 03:33 UTC #15 lore raw

In reply to E Shattow

Quoted 2 lines · E Shattow

Move imx9*-{clock,power}.h headers into include/dt-bindings/{clock,power}/ and fix up the DTs

Huh? Why?

Quoted 2 lines

Reported-by Marek Vasut <[email protected]>

What sort of bug are you fixing? Nothing in commit msg explains that at all.

Quoted 1 line

Signed-off-by E Shattow <[email protected]>

Best regards,
Krzysztof