| 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
| ||
|
Message-ID: <CANAwSgTKkFQNW5egYu5cdWx4nkwVL1tXigYUvdnAJRUOdCrxpw@mail.gmail.com>
Date: Wed, 8 May 2024 18:21:17 +0530
From: Anand Moon <linux.amoon@...il.com>
To: Dragan Simic <dsimic@...jaro.org>
Cc: Alexey Charkov <alchark@...il.com>, Diederik de Haas <didi.debian@...ow.org>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>, Conor Dooley <conor+dt@...nel.org>,
Heiko Stuebner <heiko@...ech.de>, Daniel Lezcano <daniel.lezcano@...aro.org>,
Viresh Kumar <viresh.kumar@...aro.org>, Chen-Yu Tsai <wens@...nel.org>, devicetree@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org, linux-rockchip@...ts.infradead.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 2/6] arm64: dts: rockchip: enable thermal management on
all RK3588 boards
Hi Dragan, Alexey,
On Wed, 8 May 2024 at 18:08, Dragan Simic <dsimic@...jaro.org> wrote:
>
> Hello Alexey,
>
> On 2024-05-08 14:30, Alexey Charkov wrote:
> > On Wed, May 8, 2024 at 3:46 PM Dragan Simic <dsimic@...jaro.org> wrote:
> >> On 2024-05-08 13:40, Anand Moon wrote:
> >> > On Mon, 6 May 2024 at 18:24, Alexey Charkov <alchark@...il.com> wrote:
> >> >> On Mon, May 6, 2024 at 4:29 PM Diederik de Haas
> >> >> <didi.debian@...ow.org> wrote:
> >> >> > On Monday, 6 May 2024 11:36:33 CEST Alexey Charkov wrote:
> >> >> > > This enables the on-chip thermal monitoring sensor (TSADC) on all
> >> >> > > RK3588(s) boards that don't have it enabled yet. It provides temperature
> >> >> > > monitoring for the SoC and emergency thermal shutdowns, and is thus
> >> >> > > important to have in place before CPU DVFS is enabled, as high CPU
> >> >> > > operating performance points can overheat the chip quickly in the
> >> >> > > absence of thermal management.
> >> >> > >
> >> >> > > Signed-off-by: Alexey Charkov <alchark@...il.com>
> >> >> > > ---
> >> >> > > arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts | 4 ++++
> >> >> > > 8 files changed, 32 insertions(+)
> >> >> > >
> >> >> > > diff --git a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> >> >> > > b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts index
> >> >> > > b8e15b76a8a6..21e96c212dd8 100644
> >> >> > > --- a/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> >> >> > > +++ b/arch/arm64/boot/dts/rockchip/rk3588-rock-5b.dts
> >> >> > > @@ -742,6 +742,10 @@ regulator-state-mem {
> >> >> > > };
> >> >> > > };
> >> >> > >
> >> >> > > +&tsadc {
> >> >> > > + status = "okay";
> >> >> > > +};
> >> >> > > +
> >> >> > > &uart2 {
> >> >> > > pinctrl-0 = <&uart2m0_xfer>;
> >> >> > > status = "okay";
> >> >> >
> >> >> > I built a kernel with v3 of your patch set and someone tested it on a ROCK 5B
> >> >> > 'for me' and it had the following line in dmesg:
> >> >> >
> >> >> > rockchip-thermal fec00000.tsadc: Missing rockchip,grf property
> >> >> >
> >> >> > I'm guessing that turned up due to enabling tsadc, but (also) in v4 I didn't
> >> >> > see a change wrt "rockchip,grf".
> >> >> > Should that be done? (asking; I don't know)
> >> >>
> >> >> I'm getting the same. Neither the mainline TSADC driver [1], nor the
> >> >> downstream one [2] seems to use the grf pointer on RK3588 at all. It
> >> >> still works in spite of that warning, although I can't see how (or if)
> >> >> it configures the reset mechanism without those GRF registers.
> >> >>
> >> >> Best regards,
> >> >> Alexey
> >> >>
> >> >> [1]
> >> >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/thermal/rockchip_thermal.c#n818
> >> >> [2]
> >> >> https://github.com/radxa/kernel/blob/stable-5.10-rock5/drivers/thermal/rockchip_thermal.c#L961
> >> >>
> >> >
> >> > If the following changes fix the warning.
> >> >
> >> > Checking the Rockchip RK3588 TRM V1.0-Part1-20220309.pdf
> >> > PMU1GRF_SOC_CON3 which has tsadc_shut_reset_trigger_en bit
> >> > to control the Enable TSADC shut reset trigger for DDR fail safe.
> >> >
> >> > diff --git a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
> >> > b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
> >> > index 85c25d5efdad..5490a44e093e 100644
> >> > --- a/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
> >> > +++ b/arch/arm64/boot/dts/rockchip/rk3588s.dtsi
> >> > @@ -2662,6 +2662,7 @@ tsadc: tsadc@...00000 {
> >> > rockchip,hw-tshut-temp = <120000>;
> >> > rockchip,hw-tshut-mode = <0>; /* tshut mode 0:CRU
> >> > 1:GPIO */
> >> > rockchip,hw-tshut-polarity = <0>; /* tshut polarity
> >> > 0:LOW 1:HIGH */
> >> > + rockchip,pmu = <&pmu1grf>;
> >> > pinctrl-0 = <&tsadc_gpio_func>;
> >> > pinctrl-1 = <&tsadc_shut>;
> >> > pinctrl-names = "gpio", "otpout";
> >>
> >> Basically, the rockchip_thermal driver doesn't use GRF at all on
> >> the RK3588(s), so virtually any value specified as "rockchip,pmu"
> >> can eliminate the warning.
> >
> > To me, specifying an arbitrary GRF in the device tree just to silence
> > a warning that the current driver emits sounds bad. If the GRF is not
> > needed for TSADC initialization on RK3588, then it should not be in
> > the device tree (and it looks like the case here) - otherwise the
> > device tree ceases to be a truthful description of the hardware.
>
> After thinking a bit more about it, I think you're right. If the
> rockchip_thermal driver ever gets changed to require use of GRF on
> the RK3588(s), only then adding that property to the DT would be
> the right thing to do.
>
> > I'm not sure if we need that "DDR fail safe" logic mentioned in the
> > TRM that Anand quoted, given that neither Rockchip downstream nor
> > current mainline driver implement it, and furthermore none of the
> > other SoC revisions supported by the driver mention it. If we do in
> > fact need it, we should probably first test it along with respective
> > driver code before committing to an upstream DT and thus making it
> > part of the ABI.
> >
> > IMO this is more of a driver issue than a device tree issue: maybe a
> > small patch to demote this warning to an info message would be better?
> > It's harmless anyway.
>
> After having second thoughts, I'll see to improve the rockchip_thermal
> driver to emit that warning only when having "rockchip,grf" specified
> is actually needed for the particular Rockchip SoC. That's how it
> should
> behave, yelling about the wrong hardware description only when that's
> actually the case.
We need to handle the GRF TSADC for rk3588 tmu driver.
For rk3568 we control the GRF TSADC which seems to be missing in rk3588
[[0] https://elixir.bootlin.com/linux/v6.8.9/source/drivers/thermal/rockchip_thermal.c#L798
Thanks
-Anand
Powered by blists - more mailing lists