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