linux-kernel - Re: [PATCH 2/2] dt-bindings: clock: update rk3588 clock definitions

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <87cz4v2nr1.fsf@bloch.sibelius.xs4all.nl>
Date:   Sun, 26 Mar 2023 23:42:27 +0200
From:   Mark Kettenis <mark.kettenis@...all.nl>
To:     Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
Cc:     bigbeeshane@...il.com, robh+dt@...nel.org,
        krzysztof.kozlowski+dt@...aro.org, heiko@...ech.de,
        devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] dt-bindings: clock: update rk3588 clock definitions

> Date: Sun, 26 Mar 2023 22:02:39 +0200
> From: Krzysztof Kozlowski <krzysztof.kozlowski@...aro.org>
> 
> On 26/03/2023 19:51, Shane Francis wrote:
> >> Bootloader also does not use mainline DTS, so where is exactly the problem?
> > 
> > In this case uboot does load the target DTB, and it seems a common
> > function in rockchips
> > downstream boot process, see :
> > 
> > https://github.com/rockchip-linux/u-boot/blob/ef1dd650042f61915c4859ecc94623a09a3529fa/arch/arm/mach-rockchip/kernel_dtb.c#L70
> >

That code makes absolutely no sense.  This tries to transplant
phandles from one DTB into another DTB?  Mainline U-Boot has no code
like that.  I think this is just broken beyond repair.

> U-Boot comes with its own DTB, so what does it means "loads the target
> DTB"? From where? The one appended to the kernel zImage? No, it cannot...
> 
> Any component which operates on mainline DTB must conform to the
> bindings (with respect to the ABI), thus your arguments here mean you
> are not allowed to change ABI in the future. Never. This change,
> assuming original binding was broken, could be warranted.

The current mainline binding isn't broken; 0 is a perfectly fine clock
index.  The RK3588 clock bindings are already used by U-Boot (too late
to fix for the 2023.4 release happening in a few days) and OpenBSD
(too late to fix for the 7.3 release that will happen a few weeks).
Changing the clock binding will just create more chaos.

<rant>

What is broken here is the development process.  Rockchip shouldn't be
maintaining these heavily modified forks of U-Boot and the Linux
kernel.  But at the same time mainline Linux developers should not be
asking for arbitrary changes to the device tree bindings just to
satisfy some unwritten rules.  The clock bindings were originaly
submitted with clock numbers identical to those that Rockchip uses:

  https://lore.kernel.org/all/20220623160329.239501-2-sebastian.reichel@collabora.com/

but then changed because a reviewer wanted them to start at 0 and
didn't want any holes:

  https://lore.kernel.org/all/0841741a-22f6-40f6-c745-6065dfdbcb1d@linaro.org/

This isn't the first example where this happened.  And it invariably
leads to confusion and breakage in projects that try to follow the
mainline Linux device tree bindings.

</rant>