linux-kernel - Re: [RFC PATCH] arm64: dts: rockchip: Make preparations for per-RK3588-variant OPPs

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] [thread-next>] [day] [month] [year] [list]

Date: Wed, 29 May 2024 13:57:45 +0400
From: Alexey Charkov <alchark@...il.com>
To: Dragan Simic <dsimic@...jaro.org>
Cc: linux-rockchip@...ts.infradead.org, heiko@...ech.de, 
	linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org, 
	robh+dt@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org, 
	linux-kernel@...r.kernel.org, quentin.schulz@...rry.de, wens@...nel.org, 
	daniel.lezcano@...aro.org, didi.debian@...ow.org, 
	krzysztof.kozlowski+dt@...aro.org, viresh.kumar@...aro.org
Subject: Re: [RFC PATCH] arm64: dts: rockchip: Make preparations for
 per-RK3588-variant OPPs

Hi Dragan,

On Wed, May 29, 2024 at 6:14 AM Dragan Simic <dsimic@...jaro.org> wrote:
>
> Rename and modify the RK3588 dtsi files a bit, to make preparations for
> the ability to specify different CPU and GPU OPPs for each of the supported
> RK3588 SoC variants, including the RK3588J.
>
> As already discussed, [1][2][3] some of the different RK3588 SoC variants
> require different OPPs, and it makes more sense to have the OPPs already
> defined when a board dts includes one of the SoC dtsi files (rk3588.dtsi,
> rk3588j.dtsi or rk3588s.dtsi), rather than requiring the board dts file to
> also include a separate rk3588*-opp.dtsi file.  The choice of the SoC variant
> is already made by the inclusion of the SoC dtsi file, and it doesn't make
> much sense to, effectively, allow the board dts file to include and use an
> incompatible set of OPPs for the already selected SoC variant.

Indeed, including just one .dtsi for the correct SoC variant and not
having to bother about what other bits and pieces are required to use
the full SoC functionality sounds great! Thanks for putting this
together so promptly!

Some considerations below.

> No intended functional changes are introduced.  (Still to be additionally
> verified if the patch moves forward from the RFC state.)
>
> [1] https://lore.kernel.org/linux-rockchip/646a33e0-5c1b-471c-8183-2c0df40ea51a@cherry.de/
> [2] https://lore.kernel.org/linux-rockchip/CABjd4Yxi=+3gkNnH3BysUzzYsji-=-yROtzEc8jM_g0roKB0-w@mail.gmail.com/
> [3] https://lore.kernel.org/linux-rockchip/035a274be262528012173d463e25b55f@manjaro.org/
>
> Signed-off-by: Dragan Simic <dsimic@...jaro.org>
> ---
>  ...inctrl.dtsi => rk3588-common-pinctrl.dtsi} |    0

Renaming the pinctrl includes seems superfluous - maybe keep them as
they were to minimize churn?

>  .../{rk3588s.dtsi => rk3588-common.dtsi}      |    2 +-
>  ...nctrl.dtsi => rk3588-fullfat-pinctrl.dtsi} |    0
>  .../{rk3588.dtsi => rk3588-fullfat.dtsi}      |    4 +-

To me, "fullfat" doesn't look super descriptive, albeit fun :)

How about we rename the existing rk3588.dtsi and rk3588s.dtsi to
something like rk3588-devices.dtsi and rk3588s-devices.dtsi
(preserving the inheritance between them), and then I add
rk3588s-opp.dtsi and rk3588j-opp.dtsi in a follow-up patch?

Then we keep "thin" versions of rk3588.dtsi, rk3588s.dtsi and
rk3588j.dtsi for board files to include. The mix-and-match of
different on-chip devices and different OPPs then gets transparently
represented within those "thin" .dtsi, something like this:

rk3588.dtsi:
#include "rk3588-devices.dtsi"
#include "rk3588s-opp.dtsi"

rk3588s.dtsi:
#include "rk3588s-devices.dtsi"
#include "rk3588s-opp.dtsi"

rk3588j.dtsi:
#include "rk3588-devices.dtsi"
#include "rk3588j-opp.dtsi"

>  arch/arm64/boot/dts/rockchip/rk3588.dtsi      |  414 +--
>  arch/arm64/boot/dts/rockchip/rk3588j.dtsi     |    6 +-
>  arch/arm64/boot/dts/rockchip/rk3588s.dtsi     | 2671 +----------------

Rename detection didn't do a particularly great job here - wonder if
we can do anything about it to minimize the patch size and ensure that
the change history is preserved for git blame...

Best regards,
Alexey