[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<OSCPR01MB146472833398C4E61B9C5B160FF22A@OSCPR01MB14647.jpnprd01.prod.outlook.com>
Date: Tue, 5 Aug 2025 09:22:07 +0000
From: John Madieu <john.madieu.xa@...renesas.com>
To: geert <geert@...ux-m68k.org>
CC: "conor+dt@...nel.org" <conor+dt@...nel.org>, "daniel.lezcano@...aro.org"
<daniel.lezcano@...aro.org>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
"rafael@...nel.org" <rafael@...nel.org>, Biju Das
<biju.das.jz@...renesas.com>, "devicetree@...r.kernel.org"
<devicetree@...r.kernel.org>, "john.madieu@...il.com"
<john.madieu@...il.com>, "linux-kernel@...r.kernel.org"
<linux-kernel@...r.kernel.org>, "linux-pm@...r.kernel.org"
<linux-pm@...r.kernel.org>, "linux-renesas-soc@...r.kernel.org"
<linux-renesas-soc@...r.kernel.org>, "lukasz.luba@....com"
<lukasz.luba@....com>, magnus.damm <magnus.damm@...il.com>, "robh@...nel.org"
<robh@...nel.org>, "rui.zhang@...el.com" <rui.zhang@...el.com>,
"sboyd@...nel.org" <sboyd@...nel.org>,
"niklas.soderlund+renesas@...natech.se"
<niklas.soderlund+renesas@...natech.se>
Subject: RE: [PATCH v6 3/5] thermal: renesas: rzg3e: Add thermal driver for
the Renesas RZ/G3E SoC
Hi Geert,
Thanks for the feedback!
> -----Original Message-----
> From: Geert Uytterhoeven <geert@...ux-m68k.org>
> Sent: Tuesday, August 5, 2025 10:47 AM
> To: John Madieu <john.madieu.xa@...renesas.com>
> Subject: Re: [PATCH v6 3/5] thermal: renesas: rzg3e: Add thermal driver for
> the Renesas RZ/G3E SoC
>
> Hi John,
>
> On Tue, 5 Aug 2025 at 10:27, John Madieu <john.madieu.xa@...renesas.com>
> wrote:
> > > From: Geert Uytterhoeven <geert@...ux-m68k.org> On Thu, 22 May 2025
> > > at 20:23, John Madieu <john.madieu.xa@...renesas.com>
> > > wrote:
> > > > The RZ/G3E SoC integrates a Temperature Sensor Unit (TSU) block
> > > > designed to monitor the chip's junction temperature. This sensor
> > > > is connected to channel 1 of the APB port clock/reset and provides
> > > temperature measurements.
> > >
> > > RZ/V2H and RZ/V2N have a second set of trim values for the second
> > > TSU instance. So I guess you want to specify the offset in DT instead.
> >
> > What do you think of 'renesas,tsu-channel' property or alike Property
> > to specify the channel being used ?
>
> While I agree instance IDs canbe useful (sometimes), the DT maintainers do
> not like them very much, cfr. commit 6a57cf210711c068 ("docs: dt:
> writing-bindings: Document discouraged instance IDs"), which prefers
> cell/phandle arguments.
>
> For this particular case:
> 1. The instance ID for the single TSU on RZ/G3E would be one, not zero
> (oh, the SYS_LSI_OTPTSU1TRMVAL[01] register names do contain "TSU1"),
> 2. It will break the moment a new SoC is released that stores trim
> values at different offsets in the SYSC block.
>
> Hence a property containing a SYSC phandle and register offset sounds
> better to me.
This sounds good to me. I see something like:
renesas,tsu-channel1 = <&sysc off1>;
renesas,tsu-channel2 = <&sysc off2>; /* Optional, for V2H */
/* or */
renesas,tsu-channel-map = <&sysc off1 off2>;
I would go for the first option to make it easier for V2H
(while adding support for it later) so it can choose using
either, or both, regardless of the index.
What do you think ?
> Thoughts?
>
> Gr{oetje,eeting}s,
>
> Geert
>
Regards,
John
> --
> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-
> m68k.org
>
> In personal conversations with technical people, I call myself a hacker.
> But when I'm talking to journalists I just say "programmer" or something
> like that.
> -- Linus Torvalds
Powered by blists - more mailing lists