[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ef9dab99-f14a-4b1e-883f-d2086435b8d5@freeshell.de>
Date: Mon, 1 Sep 2025 04:07:29 -0700
From: E Shattow <e@...eshell.de>
To: Krzysztof Kozlowski <krzk@...nel.org>,
Marek Vasut <marek.vasut@...lbox.org>, Peng Fan <peng.fan@....nxp.com>
Cc: Rob Herring <robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>,
Sascha Hauer <s.hauer@...gutronix.de>,
Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>, Abel Vesa <abelvesa@...nel.org>,
Peng Fan <peng.fan@....com>, Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>, devicetree@...r.kernel.org,
imx@...ts.linux.dev, linux-arm-kernel@...ts.infradead.org,
linux-kernel@...r.kernel.org, linux-clk@...r.kernel.org
Subject: Re: [PATCH v1] dts: arm64: freescale: move imx9*-clock.h
imx9*-power.h into dt-bindings
On 9/1/25 03:54, 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.
>
>> 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.
>
>>
>>> Regardless whether you agree or
>>> not, the commit should clearly explain the reason behind.
>> 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
Powered by blists - more mailing lists