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: <20250925204925.GA637503@robin.jannau.net>
Date: Thu, 25 Sep 2025 22:49:25 +0200
From: Janne Grunau <j@...nau.net>
To: Rob Herring <robh@...nel.org>
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 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. I looks to me it would be a
stretch to call the presence of the labels human convenience.

Janne

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ