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] [day] [month] [year] [list]

Message-ID: <20250311-immature-quit-81066aec062e@spud>
Date: Tue, 11 Mar 2025 20:51:07 +0000
From: Conor Dooley <conor@...nel.org>
To: John Madieu <john.madieu.xa@...renesas.com>
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

On Tue, Mar 11, 2025 at 11:24:59AM +0000, John Madieu wrote:
> 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 ?

How to change it from userspace ain't my domain, sorry. Just drop the
property since isn't something determined by the hardware, but rather by
what you put into the registers.

Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)