linux-kernel - Re: [PATCH v2] arm64: dts: rockchip: Add GPU OPP voltage ranges to RK356x SoC dtsi

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: <78a743a9828741e029f14d165ad8d3a6@manjaro.org>
Date: Sun, 30 Jun 2024 17:51:49 +0200
From: Dragan Simic <dsimic@...jaro.org>
To: Diederik de Haas <didi.debian@...ow.org>
Cc: linux-rockchip@...ts.infradead.org, heiko@...ech.de,
 linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
 robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org,
 linux-kernel@...r.kernel.org, Jonas Karlman <jonas@...boo.se>
Subject: Re: [PATCH v2] arm64: dts: rockchip: Add GPU OPP voltage ranges to
 RK356x SoC dtsi

Hello Diederik,

On 2024-06-30 17:43, Diederik de Haas wrote:
> On Sunday, 30 June 2024 14:04:50 CEST Dragan Simic wrote:
>> > I also expected that (for v1) there would be a similar construct as was
>> > recently added for rk3588. But I should interpret Heiko's comments as
>> > that strategy should not be applied to rk356x?
>> 
>> The trouble with applying the same strategy, ...
> 
> One of the reasons I like/hoped for it is that I'm a 'sucker' for
> consistency.

I also like consistency, but doing it that way simply wasn't feasible
in this case.  Maybe I'll rework the RK3399 SoC dtsi files a bit, so
we'd end up with more overall consistency. :)

>> ... the need for voltage ranges depends on one of the board features,
>> i.e. the GPU and NPU voltage regulators.  As such, it still has to
>> affect the RK356x SoC dtsi, which may warrant separate
>> rk356x-gpu-range.dtsi, for example, but the troubles would arise ...
> 
> ... but it's probably better if I (generally) abstain from taking part
> in the discussion about the correct/desired implementation as I don't
> understand the material in enough detail to meaningfully contribute.

I find your responses useful, so as far as I'm concerned, you're more
than welcome to take part in the discussions.