linux-kernel - Re: [PATCH] arm64: dts: rockchip: Make RK3588 GPU OPP table naming uniform

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <f34b6fad7768dd88b40284fa330af4f2@manjaro.org>
Date: Sat, 06 Sep 2025 14:57:55 +0200
From: Dragan Simic <dsimic@...jaro.org>
To: Heiko Stübner <heiko@...ech.de>
Cc: Diederik de Haas <didi.debian@...ow.org>,
 linux-rockchip@...ts.infradead.org, robh@...nel.org, krzk+dt@...nel.org,
 conor+dt@...nel.org, linux-arm-kernel@...ts.infradead.org,
 linux-kernel@...r.kernel.org, devicetree@...r.kernel.org
Subject: Re: [PATCH] arm64: dts: rockchip: Make RK3588 GPU OPP table naming
 uniform

Hello Heiko,

On 2025-09-06 14:21, Heiko Stübner wrote:
> Am Samstag, 6. September 2025, 14:10:22 Mitteleuropäische Sommerzeit
> schrieb Dragan Simic:
>> On 2025-09-06 13:40, Diederik de Haas wrote:
>> > On Sat Sep 6, 2025 at 12:01 PM CEST, Dragan Simic wrote:
>> >> Unify the naming of the existing GPU OPP table nodes found in the
>> >> RK3588
>> >> and RK3588J SoC dtsi files with the other SoC's GPU OPP nodes,
>> >> following
>> >> the more "modern" node naming scheme.
>> >
>> > Like we discussed in private (without an agreement), I think it would
>> > be
>> > beneficial if the (gpu) opp naming would be made consistent across SoC
>> > series as right now there are several different naming schemes applied.
>> > They're all valid, but inconsistent. And if consistency is improved,
>> > which I like, then let's go 'all the way'?
>> 
>> As we discussed it already in private, I fully agree about performing
>> the "opp-table-X => opp-table-{clusterX,gpu}" naming cleanup
>> consistently
>> for all Rockchip SoCs, but I'm afraid it would be seen as an 
>> unnecessary
>> "code churn" at this point, especially because my upcoming Rockchip 
>> SoC
>> binning patch series is a good candidate for such a cleanup.
>> 
>> On top of that, I'd be a bit weary about performing at least some of 
>> the
>> testing associated with such a platform-wide cleanup, despite actually
>> performing no functional changes and being a safe change.  On the 
>> other
>> hand, "bundling" such a cleanup with the Rockchip SoC binning patches
>> would get us detailed testing for free, so to speak.
>> 
>> Of course, if the maintainers see this as a good opportunity to 
>> perform
>> a platform-wide cleanup at this point, instead of seeing it as a "code
>> churn", I'll still be happy to extend this small patch into a 
>> platform-
>> wide naming cleanup of the "opp-table-X" nodes.  On the other hand, if
>> this patch remains as-is, it may hit a good balance between resolving
>> the currently present naming ambiguity and the amount of introduced
>> changes.
> 
> Personally I'm always for the "we strive to get there eventually" 
> thing.
> If there is an established goal to reach, steps can be incremental :-) 
> .
> 
> And also short and scope-limited patches are easier to review anyway.

I see.  After thinking a bit more about it, I'll turn this patch into
a small series, in which this patch becomes the 1/2, and the 2/2 is
a new, larger patch that extends the "opp-table-X" naming cleanup to
the entire platform.  That way, the 1/2 kind of fixes something, while
the 2/2 performs a cleanup, which may be helpful in the unlikely case
that some regression is found down the road.