linux-kernel - Re: [PATCH v2 02/11] clk: rockchip: introduce auxiliary GRFs

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: <2240109.Mh6RI2rZIc@diego>
Date: Thu, 01 May 2025 14:38:25 +0200
From: Heiko Stübner <heiko@...ech.de>
To: Michael Turquette <mturquette@...libre.com>,
 Stephen Boyd <sboyd@...nel.org>, Rob Herring <robh@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 Liam Girdwood <lgirdwood@...il.com>, Mark Brown <broonie@...nel.org>,
 Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
 Philipp Zabel <p.zabel@...gutronix.de>,
 Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>,
 Sugar Zhang <sugar.zhang@...k-chips.com>,
 Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Cc: Luca Ceresoli <luca.ceresoli@...tlin.com>,
 Sebastian Reichel <sebastian.reichel@...labora.com>, kernel@...labora.com,
 linux-clk@...r.kernel.org, devicetree@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
 linux-kernel@...r.kernel.org, linux-sound@...r.kernel.org,
 Nicolas Frattaroli <nicolas.frattaroli@...labora.com>
Subject: Re: [PATCH v2 02/11] clk: rockchip: introduce auxiliary GRFs

Hi Nicolas,

Am Donnerstag, 10. April 2025, 21:39:54 Mitteleuropäische Sommerzeit schrieb Nicolas Frattaroli:
> The MUXGRF clock branch type depends on having access to some sort of
> GRF as a regmap to be registered. So far, we could easily get away with
> only ever having one GRF stowed away in the context.
> 
> However, newer Rockchip SoCs, such as the RK3576, have several GRFs
> which are relevant for clock purposes. It already depends on the pmu0
> GRF for MUXGRF reasons, but could get away with not refactoring this
> because it didn't need the sysgrf at all, so could overwrite the pointer
> in the clock provider to the pmu0 grf regmap handle.
> 
> In preparation for needing to finally access more than one GRF per SoC,
> let's untangle this. Introduce an auxiliary GRF hashmap, and a GRF type
> enum. The hasmap is keyed by the enum, and clock branches now have a
> struct member to store the value of that enum, which defaults to the
> system GRF.
> 
> The SoC-specific _clk_init function can then insert pointers to GRF
> regmaps into the hashmap based on the grf type.
> 
> During clock branch registration, we then pick the right GRF for each
> branch from the hashmap if something other than the sys GRF is
> requested.
> 
> The reason for doing it with this grf type indirection in the clock
> branches is so that we don't need to define the MUXGRF branches in a
> separate step, just to have a direct pointer to a regmap available
> already.
> 
> Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@...labora.com>

like the concept and also implementation :-) .

> ---
>  drivers/clk/rockchip/clk-rk3328.c |  6 +++---
>  drivers/clk/rockchip/clk-rk3568.c |  2 +-
>  drivers/clk/rockchip/clk-rk3576.c | 32 ++++++++++++++++++++++----------

the only "hair in the soup" are some missing socs ;-) .

As you're changing the MUXGRF type, you should adapt all socs using it
please. Missing rk3288 and rv1126 it seems - ARM32, which may have helped
these slipping through.


Heiko