linux-kernel - RE: [PATCH v2 3/7] dt-bindings: thermal: r9a09g047-tsu: Document the TSU unit

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]

Message-ID:
 <OSBPR01MB2775B3826A9FE602AC08172BFFD12@OSBPR01MB2775.jpnprd01.prod.outlook.com>
Date: Tue, 11 Mar 2025 11:24:59 +0000
From: John Madieu <john.madieu.xa@...renesas.com>
To: Conor Dooley <conor@...nel.org>
CC: "robh@...nel.org" <robh@...nel.org>, "geert+renesas@...der.be"
	<geert+renesas@...der.be>, "magnus.damm@...il.com" <magnus.damm@...il.com>,
	"mturquette@...libre.com" <mturquette@...libre.com>, "sboyd@...nel.org"
	<sboyd@...nel.org>, "rafael@...nel.org" <rafael@...nel.org>,
	"daniel.lezcano@...aro.org" <daniel.lezcano@...aro.org>,
	"rui.zhang@...el.com" <rui.zhang@...el.com>, "lukasz.luba@....com"
	<lukasz.luba@....com>, "krzk+dt@...nel.org" <krzk+dt@...nel.org>,
	"conor+dt@...nel.org" <conor+dt@...nel.org>, "p.zabel@...gutronix.de"
	<p.zabel@...gutronix.de>, "catalin.marinas@....com"
	<catalin.marinas@....com>, "will@...nel.org" <will@...nel.org>,
	"john.madieu@...il.com" <john.madieu@...il.com>,
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
	"linux-pm@...r.kernel.org" <linux-pm@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, Biju Das <biju.das.jz@...renesas.com>
Subject: RE: [PATCH v2 3/7] dt-bindings: thermal: r9a09g047-tsu: Document the
 TSU unit

Hi Conor,

> -----Original Message-----
> From: Conor Dooley <conor@...nel.org>
> Sent: Monday, March 10, 2025 5:15 PM
> To: John Madieu <john.madieu.xa@...renesas.com>
> Subject: Re: [PATCH v2 3/7] dt-bindings: thermal: r9a09g047-tsu: Document
> the TSU unit
> 
> On Sun, Mar 09, 2025 at 10:39:27AM +0000, John Madieu wrote:
> > Hi Conor,
> > > > Changes are not possible at runtime. Some customers may want
> > > > software, while other may want the external trigger, and this is
> > > > immutable configuration.
> > >
> > > What makes it immutable? Set by some wiring on the board? I couldn't
> > > find the user in your driver patches to better understand how you
> > > were using it.
> >
> > I haven't prototyped ELC trigger yet. Since the hardware manual
> > describes about ELC trigger, I have documented it in bindings. If you
> > think, it is not needed at this stage, then I can drop it now and
> > revisit later.
> 
> Ideally a binding is complete, even if the driver isn't. To me "immutable"
> would mean something like "the trigger type is determined by hardware or
> firmware configuration", but if it is determined by register writes (e.g.
> wired up for elc trigger, but you can opt for software trigger in the
> driver) then it should be a userspace control.

It is complete, and I confirm, this can be changed by register writes.
Apart from defining default to 0, should I implement userspace change
support now ?

Or should I keep it as it is, just setting default to 0 (thus making
the property optional), and add support for userspace change when I add
ELC support.

My other question is, in case I must add userspace change support now, would
sysfs be Ok ? If yes, is there any path recommendations ?


Regards,
John