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: <CAL_JsqK-9n3_H6vS80bZuZiSPi9UNuMzHEPFL_EzYTeyNS1cYg@mail.gmail.com>
Date: Thu, 25 Sep 2025 16:43:23 -0500
From: Rob Herring <robh@...nel.org>
To: Janne Grunau <j@...nau.net>
Cc: James Calligeros <jcalligeros99@...il.com>, 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

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:
> > On Wed, Aug 27, 2025 at 09:22:36PM +1000, James Calligeros wrote:
> > > Apple Silicon devices integrate a vast array of sensors, monitoring
> > > current, power, temperature, and voltage across almost every part of
> > > the system. The sensors themselves are all connected to the System
> > > Management Controller (SMC). The SMC firmware exposes the data
> > > reported by these sensors via its standard FourCC-based key-value
> > > API. The SMC is also responsible for monitoring and controlling any
> > > fans connected to the system, exposing them in the same way.
> > >
> > > For reasons known only to Apple, each device exposes its sensors with
> > > an almost totally unique set of keys. This is true even for devices
> > > which share an SoC. An M1 Mac mini, for example, will report its core
> > > temperatures on different keys to an M1 MacBook Pro. Worse still, the
> > > SMC does not provide a way to enumerate the available keys at runtime,
> > > nor do the keys follow any sort of reasonable or consistent naming
> > > rules that could be used to deduce their purpose. We must therefore
> > > know which keys are present on any given device, and which function
> > > they serve, ahead of time.
> > >
> > > Add a schema so that we can describe the available sensors for a given
> > > Apple Silicon device in the Devicetree.
> > >
> > > Signed-off-by: James Calligeros <jcalligeros99@...il.com>
> > > ---
> > >  .../bindings/hwmon/apple,smc-hwmon.yaml  | 132 +++++++++++++++++++++++++
> > >  .../bindings/mfd/apple,smc.yaml          |  36 +++++++
> > >  MAINTAINERS                              |   1 +
> > >  3 files changed, 169 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/hwmon/apple,smc-hwmon.yaml b/Documentation/devicetree/bindings/hwmon/apple,smc-hwmon.yaml
> > > new file mode 100644
> > > index 0000000000000000000000000000000000000000..08cc4f55f3a41ca8b3b428088f96240266fa42e8
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/hwmon/apple,smc-hwmon.yaml
> > > @@ -0,0 +1,132 @@
> >
> > 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.

> 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.

Rob