On Tue, Mar 11, 2025 at 11:24:59AM +0000, John Madieu wrote:

Hi Conor,

quoted

-----Original Message-----
From: Conor Dooley <conor@kernel.org>
Sent: Monday, March 10, 2025 5:15 PM
To: John Madieu <john.madieu.xa@bp.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:

quoted

Hi Conor,

quoted

quoted

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.