linux-kernel - Re: [PATCH v2 02/11] dt-bindings: hwmon: Add Apple System Management Controller hwmon schema

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: <2537878.PYKUYFuaPT@setsuna>
Date: Sun, 28 Sep 2025 10:36:03 +1000
From: James Calligeros <jcalligeros99@...il.com>
To: Janne Grunau <j@...nau.net>, Rob Herring <robh@...nel.org>
Cc: Sven Peter <sven@...nel.org>, Alyssa Rosenzweig <alyssa@...enzweig.io>,
 Neal Gompa <neal@...pa.dev>, Lee Jones <lee@...nel.org>,
 Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley <conor+dt@...nel.org>,
 Alexandre Belloni <alexandre.belloni@...tlin.com>,
 Jean Delvare <jdelvare@...e.com>, Guenter Roeck <linux@...ck-us.net>,
 Dmitry Torokhov <dmitry.torokhov@...il.com>, asahi@...ts.linux.dev,
 linux-arm-kernel@...ts.infradead.org, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-rtc@...r.kernel.org,
 linux-hwmon@...r.kernel.org, linux-input@...r.kernel.org
Subject:
 Re: [PATCH v2 02/11] dt-bindings: hwmon: Add Apple System Management
 Controller hwmon schema

Hi Rob,

On Friday, 26 September 2025 7:43:23 am Australian Eastern Standard Time Rob 
Herring wrote:
> On Thu, Sep 25, 2025 at 3:49 PM Janne Grunau <j@...nau.net> wrote:
> > On Fri, Aug 29, 2025 at 11:40:57AM -0500, Rob Herring wrote:
> > > 
> > > This should be something like this:
> > > 
> > > "^current-[A-Za-z0-9]{4}$":
> > >   $ref: "#/$defs/sensor"
> > >   unevaluatedProperties: false
> > > 
> > > With the $defs/sensor being:
> > > 
> > > $defs:
> > >   sensor:
> > >     type: object
> > >     
> > >     properties:
> > >       apple,key-id:
> > >         $ref: /schemas/types.yaml#/definitions/string
> > >         pattern: "^[A-Za-z0-9]{4}$"
> > >         
> > >         description:
> > >           The SMC FourCC key of the desired sensor. Must match the
> > >           node's suffix.
> > >       
> > >       label:
> > >         description: Human-readable name for the sensor
> > >     
> > >     required:
> > >       - apple,key-id
> > >       - label
> > > 
> > > Though in general, 'label' should never be required being just for human
> > > convenience.
> > 
> > That does not sound as it would be compatible with skipping nodes in the
> > driver if the node misses label. The driver could of course fall back
> > to create a hwmon sensors without labels.
> 
> The driver absolutely should.

The original submission (and our downstream version) do this, but I changed
it for v2 per Sven's feedback [1]. Outside of development/experimentation,
we will (should) never have a sensor in the Devicetree of uknown utility.
If we know what a sensor is for, then we should have a label for it.

> > I looks to me it would be a
> > stretch to call the presence of the labels human convenience.
> 
> Then it is an abuse of 'label". "label" is supposed to be literally
> that. Matching a sticker on a port of a device.
> 
> If you need to associate a sensor with some other piece of h/w, then
> that should be via a phandle or something.

I don't think doing so is particularly useful for this platform. Few of
the sensors that we know about are directly related to any one piece of 
hardware.
It's pretty much just the CPU cores and Broadcom module. The rest are things
like fans, palm rest area temperature sensors, ammeters and voltmeters for 
entire
rails, etc.

Even where we can reliably associate a sensor to a piece of hardware,
(e.g. the WiFi/BT board), doing so does not by itself do anything useful. We
still need to write a human-readable label for the sensor.

I was trying to avoid yet another vendor property, but would something like
'apple,sensor-label' work here?

> Rob

James

[1]: https://lore.kernel.org/asahi/4a95cbf3-b3ae-4b26-8db2-dd5cf14a4c0c@kernel.org/