* [PATCH] rtc: optee: make optee_rtc_pm_ops static
From: alexandre.belloni @ 2025-10-05 20:19 UTC (permalink / raw)
To: Clément Léger, Alexandre Belloni
Cc: kernel test robot, linux-rtc, linux-kernel
From: Alexandre Belloni <alexandre.belloni@bootlin.com>
Fix sparse warningg:
drivers/rtc/rtc-optee.c:714:1: sparse: sparse: symbol 'optee_rtc_pm_ops' was not
declared. Should it be static?
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202509230549.L26lw7UZ-lkp@intel.com/
Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
---
drivers/rtc/rtc-optee.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-optee.c b/drivers/rtc/rtc-optee.c
index 3d5662aa1bd8..184c6d142801 100644
--- a/drivers/rtc/rtc-optee.c
+++ b/drivers/rtc/rtc-optee.c
@@ -712,7 +712,7 @@ static int optee_rtc_suspend(struct device *dev)
return 0;
}
-DEFINE_SIMPLE_DEV_PM_OPS(optee_rtc_pm_ops, optee_rtc_suspend, NULL);
+static DEFINE_SIMPLE_DEV_PM_OPS(optee_rtc_pm_ops, optee_rtc_suspend, NULL);
static const struct tee_client_device_id optee_rtc_id_table[] = {
{UUID_INIT(0xf389f8c8, 0x845f, 0x496c,
--
2.51.0
^ permalink raw reply related
* Re: [PATCH 0/2] rtc: optee: Fix a couple error codes
From: Alexandre Belloni @ 2025-10-05 18:53 UTC (permalink / raw)
To: Clément Le Goffic, Dan Carpenter
Cc: Clément Léger, linux-kernel, linux-rtc
In-Reply-To: <cover.1758182509.git.dan.carpenter@linaro.org>
On Thu, 18 Sep 2025 12:48:39 +0300, Dan Carpenter wrote:
> Fix a couple error codes detected by Smatch.
>
> Dan Carpenter (2):
> rtc: optee: fix error code in probe()
> rtc: optee: Fix error code in optee_rtc_read_alarm()
>
> drivers/rtc/rtc-optee.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> [...]
Applied, thanks!
[1/2] rtc: optee: fix error code in probe()
https://git.kernel.org/abelloni/c/8bbd727453b4
[2/2] rtc: optee: Fix error code in optee_rtc_read_alarm()
https://git.kernel.org/abelloni/c/eb7392a01964
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] dt-bindings: rtc: Convert apm,xgene-rtc to DT schema
From: Alexandre Belloni @ 2025-10-05 18:51 UTC (permalink / raw)
To: Krzysztof Kozlowski, Conor Dooley, Khuong Dinh, Rob Herring (Arm)
Cc: linux-rtc, devicetree, linux-kernel
In-Reply-To: <20250924222848.2949235-1-robh@kernel.org>
On Wed, 24 Sep 2025 17:28:46 -0500, Rob Herring (Arm) wrote:
> Convert the APM XGene RTC binding to DT schema format. It's a
> straight-forward conversion.
>
>
Applied, thanks!
[1/1] dt-bindings: rtc: Convert apm,xgene-rtc to DT schema
https://git.kernel.org/abelloni/c/a6b4f791cdc5
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] rtc: fix error return in pm80x_rtc_read_alarm()
From: Markus Elfring @ 2025-10-03 15:00 UTC (permalink / raw)
To: Alexandr Sapozhnikov, linux-rtc, lvc-project; +Cc: LKML, Alexandre Belloni
In-Reply-To: <20251002091822.26-1-alsp705@gmail.com>
> The regmap_raw_read() function may return an error.
* Would a corresponding imperative wording become helpful for an improved change description?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.17#n94
* How do you think about to add any tags (like “Fixes” and “Cc”) accordingly?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH] rtc: fix error return in pm80x_rtc_set_time()
From: Markus Elfring @ 2025-10-03 14:08 UTC (permalink / raw)
To: Alexandr Sapozhnikov, linux-rtc, lvc-project; +Cc: LKML, Alexandre Belloni
In-Reply-To: <20251002092045.11-1-alsp705@gmail.com>
> The regmap_raw_read() function may return an error.
* Would you like to choose another imperative wording for an improved change description?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.17#n94
* How do you think about to add any tags (like “Fixes” and “Cc”) accordingly?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH] rtc: fix error checking in wdt_disable()
From: Markus Elfring @ 2025-10-03 13:50 UTC (permalink / raw)
To: Alexandr Sapozhnikov, linux-rtc, lvc-project; +Cc: LKML, Alexandre Belloni
In-Reply-To: <20251002092456.11-1-alsp705@gmail.com>
> The i2c_transfer() function may return an error.
> Ignoring errors returned by functions is bad practice.
See also:
https://cwe.mitre.org/data/definitions/252.html
…
> If the second function call succeeds, data corruption will occur.
Should the function return values be checked for both passed messages?
* Would a corresponding imperative wording become helpful for an improved change description?
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v6.17#n94
* How do you think about to add any tags (like “Fixes” and “Cc”) accordingly?
Regards,
Markus
^ permalink raw reply
* Re: [PATCH v3 0/6] rtc: m41t93: add new features alarm, clock out, watchdog
From: Akhilesh Patil @ 2025-10-02 15:51 UTC (permalink / raw)
To: alexandre.belloni, krzk+dt, robh, conor+dt
Cc: skhan, linux-rtc, devicetree, linux-kernel, akhileshpatilvnit
In-Reply-To: <cover.1758379856.git.akhilesh@ee.iitb.ac.in>
On Sat, Sep 20, 2025 at 08:30:59PM +0530, Akhilesh Patil wrote:
> This patch series adds following to m41t93 rtc driver.
>
> Functionalities:
> - Alarm support (support to configure alarm 1)
> - Square wave output support
> - Watchdog support
>
> Code improvements:
> this series migrates existing driver to use standard regmap interface
> for spi instead of direct spi calls and uses regmap for new features.
>
> Device tree support:
> Adds device tree support to the driver along with binding documentation.
>
> Testing:
> This patch series is validated on TI am62x board with m41t93 rtc chip
> connected to spi0 bus.
> regmap migration is additionally tested by observing spi transfers
> with the help of logic analyzer. Short summary of test flow is added in
> commit message of respective features.
>
> Datasheet:
> https://www.st.com/resource/en/datasheet/m41t93.pdf
>
> patch 4 to 6 depend on patch 3 (regmap patch)
>
> Signed-off-by: Akhilesh Patil <akhilesh@ee.iitb.ac.in>
> ---
Hi Alexandre, I would like to follow-up on this patch series for review
and feedback for rtc code. Let me know if any additional improvements needed.
I am willing to volunteer to support this driver in the kernel, in case
needed, as a reviewer/maintainer. I have this m41t93 RTC hardware with
me. Given we are in 6.18 merge window, looking forward for
this patch series.
Regards,
Akhilesh
> Changes in v3:
> - Address comments on bindings from Krzysztof and add myself
> as a maintainer.
> - Re-validation/testing on top of v6.17-rc6
> - Link to v2: https://lore.kernel.org/lkml/cover.1757510157.git.akhilesh@ee.iitb.ac.in/
>
> Changes in v2:
> - Address DTS and bindings coding style feedback from Krzysztof
> - Verify bindings using $ make dt_binding_check
> - Update example in binding documentation after testing.
> - Analyze and Fix build warnings as suggested by kernel test robot.
> - Drop patch 5 from series (device detect logic change).
> This will be taken separately. Focus on functionalities in this series.
> - Update commit messages with short test steps for each feature.
> - Link to v1: https://lore.kernel.org/lkml/cover.1756908788.git.akhilesh@ee.iitb.ac.in/
> ---
>
> Akhilesh Patil (6):
> dt-bindings: rtc: Add ST m41t93
> rtc: m41t93: add device tree support
> rtc: m41t93: migrate to regmap api for register access
> rtc: m41t93: Add alarm support
> rtc: m41t93: Add square wave clock provider support
> rtc: m41t93: Add watchdog support
>
> .../devicetree/bindings/rtc/st,m41t93.yaml | 50 ++
> drivers/rtc/rtc-m41t93.c | 488 ++++++++++++++++--
> 2 files changed, 486 insertions(+), 52 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/rtc/st,m41t93.yaml
>
> --
> 2.34.1
>
^ permalink raw reply
* [PATCH] rtc: fix error checking in wdt_disable()
From: Alexandr Sapozhnkiov @ 2025-10-02 9:24 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Alexandr Sapozhnikov, linux-rtc, linux-kernel, lvc-project
From: Alexandr Sapozhnikov <alsp705@gmail.com>
The i2c_transfer() function may return an error.
Ignoring errors returned by functions is bad practice.
Especially when these functions perform core functionality.
What's the point of continuing to call the same function
after an error is returned?
If the second function call succeeds, data corruption will occur.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Alexandr Sapozhnikov <alsp705@gmail.com>
---
drivers/rtc/rtc-m41t80.c | 10 +++++-----
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/rtc/rtc-m41t80.c b/drivers/rtc/rtc-m41t80.c
index 0013bff0447d..b24d09c57816 100644
--- a/drivers/rtc/rtc-m41t80.c
+++ b/drivers/rtc/rtc-m41t80.c
@@ -677,11 +677,11 @@ static void wdt_disable(void)
};
i2c_data[0] = 0x09;
- i2c_transfer(save_client->adapter, msgs0, 2);
-
- i2c_data[0] = 0x09;
- i2c_data[1] = 0x00;
- i2c_transfer(save_client->adapter, msgs1, 1);
+ if (!i2c_transfer(save_client->adapter, msgs0, 2)) {
+ i2c_data[0] = 0x09;
+ i2c_data[1] = 0x00;
+ i2c_transfer(save_client->adapter, msgs1, 1);
+ }
}
/**
--
2.43.0
^ permalink raw reply related
* [PATCH] rtc: fix error return in pm80x_rtc_set_time()
From: Alexandr Sapozhnkiov @ 2025-10-02 9:20 UTC (permalink / raw)
To: Alexandre Belloni, linux-rtc, linux-kernel
Cc: Alexandr Sapozhnikov, lvc-project
From: Alexandr Sapozhnikov <alsp705@gmail.com>
The regmap_raw_read() function may return an error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Alexandr Sapozhnikov <alsp705@gmail.com>
---
drivers/rtc/rtc-88pm80x.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-88pm80x.c b/drivers/rtc/rtc-88pm80x.c
index f40cc06b0979..50266d2e078a 100644
--- a/drivers/rtc/rtc-88pm80x.c
+++ b/drivers/rtc/rtc-88pm80x.c
@@ -119,6 +119,7 @@ static int pm80x_rtc_read_time(struct device *dev, struct rtc_time *tm)
static int pm80x_rtc_set_time(struct device *dev, struct rtc_time *tm)
{
+ int ret;
struct pm80x_rtc_info *info = dev_get_drvdata(dev);
unsigned char buf[4];
unsigned long ticks, base, data;
@@ -126,7 +127,9 @@ static int pm80x_rtc_set_time(struct device *dev, struct rtc_time *tm)
ticks = rtc_tm_to_time64(tm);
/* load 32-bit read-only counter */
- regmap_raw_read(info->map, PM800_RTC_COUNTER1, buf, 4);
+ ret = regmap_raw_read(info->map, PM800_RTC_COUNTER1, buf, 4);
+ if (ret)
+ return ret;
data = ((unsigned long)buf[3] << 24) | (buf[2] << 16) |
(buf[1] << 8) | buf[0];
base = ticks - data;
--
2.43.0
^ permalink raw reply related
* [PATCH] rtc: fix error return in pm80x_rtc_set_time()
From: Alexandr Sapozhnkiov @ 2025-10-02 9:19 UTC (permalink / raw)
To: Alexandre Belloni, linux-rtc, linux-kernel
Cc: Alexandr Sapozhnikov, lvc-project
From: Alexandr Sapozhnikov <alsp705@gmail.com>
The regmap_raw_write() function may return an error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Alexandr Sapozhnikov <alsp705@gmail.com>
---
drivers/rtc/rtc-88pm80x.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-88pm80x.c b/drivers/rtc/rtc-88pm80x.c
index f40cc06b0979..71d4cc7e595c 100644
--- a/drivers/rtc/rtc-88pm80x.c
+++ b/drivers/rtc/rtc-88pm80x.c
@@ -136,9 +136,7 @@ static int pm80x_rtc_set_time(struct device *dev, struct rtc_time *tm)
buf[1] = (base >> 8) & 0xFF;
buf[2] = (base >> 16) & 0xFF;
buf[3] = (base >> 24) & 0xFF;
- regmap_raw_write(info->map, PM800_RTC_EXPIRE2_1, buf, 4);
-
- return 0;
+ return regmap_raw_write(info->map, PM800_RTC_EXPIRE2_1, buf, 4);
}
static int pm80x_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
--
2.43.0
^ permalink raw reply related
* [PATCH] rtc: fix error return in pm80x_rtc_read_alarm()
From: Alexandr Sapozhnkiov @ 2025-10-02 9:18 UTC (permalink / raw)
To: Alexandre Belloni, linux-rtc, linux-kernel
Cc: Alexandr Sapozhnikov, lvc-project
From: Alexandr Sapozhnikov <alsp705@gmail.com>
The regmap_raw_read() function may return an error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Alexandr Sapozhnikov <alsp705@gmail.com>
---
drivers/rtc/rtc-88pm80x.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-88pm80x.c b/drivers/rtc/rtc-88pm80x.c
index f40cc06b0979..3651dc8436f0 100644
--- a/drivers/rtc/rtc-88pm80x.c
+++ b/drivers/rtc/rtc-88pm80x.c
@@ -153,7 +153,9 @@ static int pm80x_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
(buf[1] << 8) | buf[0];
dev_dbg(info->dev, "%x-%x-%x-%x\n", buf[0], buf[1], buf[2], buf[3]);
- regmap_raw_read(info->map, PM800_RTC_EXPIRE1_1, buf, 4);
+ ret = regmap_raw_read(info->map, PM800_RTC_EXPIRE1_1, buf, 4);
+ if (ret)
+ return ret;
data = ((unsigned long)buf[3] << 24) | (buf[2] << 16) |
(buf[1] << 8) | buf[0];
ticks = base + data;
--
2.43.0
^ permalink raw reply related
* [PATCH] rtc: fix error return in pm80x_rtc_read_alarm()
From: Alexandr Sapozhnkiov @ 2025-10-02 9:18 UTC (permalink / raw)
To: Alexandre Belloni, linux-rtc, linux-kernel
Cc: Alexandr Sapozhnikov, lvc-project
From: Alexandr Sapozhnikov <alsp705@gmail.com>
The regmap_raw_read() function may return an error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Alexandr Sapozhnikov <alsp705@gmail.com>
---
drivers/rtc/rtc-88pm80x.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/rtc/rtc-88pm80x.c b/drivers/rtc/rtc-88pm80x.c
index f40cc06b0979..44d324c3101c 100644
--- a/drivers/rtc/rtc-88pm80x.c
+++ b/drivers/rtc/rtc-88pm80x.c
@@ -148,7 +148,9 @@ static int pm80x_rtc_read_alarm(struct device *dev, struct rtc_wkalrm *alrm)
unsigned long ticks, base, data;
int ret;
- regmap_raw_read(info->map, PM800_RTC_EXPIRE2_1, buf, 4);
+ ret = regmap_raw_read(info->map, PM800_RTC_EXPIRE2_1, buf, 4);
+ if (ret)
+ return ret;
base = ((unsigned long)buf[3] << 24) | (buf[2] << 16) |
(buf[1] << 8) | buf[0];
dev_dbg(info->dev, "%x-%x-%x-%x\n", buf[0], buf[1], buf[2], buf[3]);
--
2.43.0
^ permalink raw reply related
* [PATCH] rtc: fix error return in pm80x_rtc_set_alarm()
From: Alexandr Sapozhnkiov @ 2025-10-02 9:16 UTC (permalink / raw)
To: Alexandre Belloni, linux-rtc, linux-kernel
Cc: Alexandr Sapozhnikov, lvc-project
From: Alexandr Sapozhnikov <alsp705@gmail.com>
The regmap_raw_read() function may return an error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Alexandr Sapozhnikov <alsp705@gmail.com>
---
drivers/rtc/rtc-88pm80x.c | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/rtc/rtc-88pm80x.c b/drivers/rtc/rtc-88pm80x.c
index f40cc06b0979..f26d8a1e827b 100644
--- a/drivers/rtc/rtc-88pm80x.c
+++ b/drivers/rtc/rtc-88pm80x.c
@@ -173,17 +173,21 @@ static int pm80x_rtc_set_alarm(struct device *dev, struct rtc_wkalrm *alrm)
struct rtc_time now_tm, alarm_tm;
unsigned long ticks, base, data;
unsigned char buf[4];
- int mask;
+ int mask, ret;
regmap_update_bits(info->map, PM800_RTC_CONTROL, PM800_ALARM1_EN, 0);
- regmap_raw_read(info->map, PM800_RTC_EXPIRE2_1, buf, 4);
+ ret = regmap_raw_read(info->map, PM800_RTC_EXPIRE2_1, buf, 4);
+ if (ret)
+ return ret;
base = ((unsigned long)buf[3] << 24) | (buf[2] << 16) |
(buf[1] << 8) | buf[0];
dev_dbg(info->dev, "%x-%x-%x-%x\n", buf[0], buf[1], buf[2], buf[3]);
/* load 32-bit read-only counter */
- regmap_raw_read(info->map, PM800_RTC_COUNTER1, buf, 4);
+ ret = regmap_raw_read(info->map, PM800_RTC_COUNTER1, buf, 4);
+ if (ret)
+ return ret;
data = ((unsigned long)buf[3] << 24) | (buf[2] << 16) |
(buf[1] << 8) | buf[0];
ticks = base + data;
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] drivers rtc-pcf8523.c: add "clockout-disable" property
From: Rob Herring @ 2025-10-02 1:59 UTC (permalink / raw)
To: Rodolfo Giometti
Cc: linux-rtc, devicetree, Alexandre Belloni, Conor Dooley,
Sam Ravnborg
In-Reply-To: <20250926091038.2262571-1-giometti@enneenne.com>
On Fri, Sep 26, 2025 at 11:10:38AM +0200, Rodolfo Giometti wrote:
> Some systems may require disabling clock generation on the CLKOUT pin
> even if there is no IRQ management.
>
> Signed-off-by: Rodolfo Giometti <giometti@enneenne.com>
> ---
> .../devicetree/bindings/rtc/nxp,pcf8523.yaml | 5 +++++
Bindings should be a separate patch.
> drivers/rtc/rtc-pcf8523.c | 13 +++++++++----
> 2 files changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf8523.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf8523.yaml
> index d11c8bc16bc0..d18c396c06cd 100644
> --- a/Documentation/devicetree/bindings/rtc/nxp,pcf8523.yaml
> +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf8523.yaml
> @@ -25,6 +25,11 @@ properties:
> enum: [ 7000, 12500 ]
> default: 12500
>
> + clockout-disable:
Needs a vendor prefix (nxp,)
> + type: boolean
> + description:
> + Disable the clock generation on CLKOUT pin.
> +
> required:
> - compatible
> - reg
^ permalink raw reply
* Re: [PATCH 03/25] dt-bindings: gpio: rda: Make interrupts optional
From: Linus Walleij @ 2025-10-01 6:24 UTC (permalink / raw)
To: Dang Huynh
Cc: Manivannan Sadhasivam, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Bartosz Golaszewski, Alexandre Belloni,
Michael Turquette, Stephen Boyd, Philipp Zabel, Sebastian Reichel,
Vinod Koul, Kees Cook, Gustavo A. R. Silva, Ulf Hansson,
linux-arm-kernel, linux-unisoc, devicetree, linux-kernel,
linux-gpio, linux-rtc, linux-clk, linux-pm, dmaengine,
linux-hardening, linux-mmc
In-Reply-To: <20250917-rda8810pl-drivers-v1-3-74866def1fe3@mainlining.org>
On Tue, Sep 16, 2025 at 10:09 PM Dang Huynh <dang.huynh@mainlining.org> wrote:
> The GPIO controller from the modem does not have an interrupt.
>
> Signed-off-by: Dang Huynh <dang.huynh@mainlining.org>
Can you split out the GPIO patches (like the 3? of them?)
into it's own series and send them separately? They seem
to be possible to review and apply separately.
Yours,
Linus Walleij
^ permalink raw reply
* Re: [PATCH v2 02/11] dt-bindings: hwmon: Add Apple System Management Controller hwmon schema
From: Guenter Roeck @ 2025-09-28 2:09 UTC (permalink / raw)
To: James Calligeros, Janne Grunau, Rob Herring
Cc: Sven Peter, Alyssa Rosenzweig, Neal Gompa, Lee Jones,
Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Dmitry Torokhov, asahi, linux-arm-kernel,
devicetree, linux-kernel, linux-rtc, linux-hwmon, linux-input
In-Reply-To: <2537878.PYKUYFuaPT@setsuna>
On 9/27/25 17:36, James Calligeros wrote:
> 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@jannau.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.
>
Label attributes are optional in hwmon drivers. Period.
Guenter
^ permalink raw reply
* Re: [PATCH v2 02/11] dt-bindings: hwmon: Add Apple System Management Controller hwmon schema
From: James Calligeros @ 2025-09-28 0:36 UTC (permalink / raw)
To: Janne Grunau, Rob Herring
Cc: Sven Peter, Alyssa Rosenzweig, Neal Gompa, Lee Jones,
Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, asahi,
linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input
In-Reply-To: <CAL_JsqK-9n3_H6vS80bZuZiSPi9UNuMzHEPFL_EzYTeyNS1cYg@mail.gmail.com>
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@jannau.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/
^ permalink raw reply
* [PATCH] drivers rtc-pcf8523.c: add "clockout-disable" property
From: Rodolfo Giometti @ 2025-09-26 9:10 UTC (permalink / raw)
To: linux-rtc, devicetree
Cc: Alexandre Belloni, Rob Herring, Conor Dooley, Sam Ravnborg,
Rodolfo Giometti
Some systems may require disabling clock generation on the CLKOUT pin
even if there is no IRQ management.
Signed-off-by: Rodolfo Giometti <giometti@enneenne.com>
---
.../devicetree/bindings/rtc/nxp,pcf8523.yaml | 5 +++++
drivers/rtc/rtc-pcf8523.c | 13 +++++++++----
2 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf8523.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf8523.yaml
index d11c8bc16bc0..d18c396c06cd 100644
--- a/Documentation/devicetree/bindings/rtc/nxp,pcf8523.yaml
+++ b/Documentation/devicetree/bindings/rtc/nxp,pcf8523.yaml
@@ -25,6 +25,11 @@ properties:
enum: [ 7000, 12500 ]
default: 12500
+ clockout-disable:
+ type: boolean
+ description:
+ Disable the clock generation on CLKOUT pin.
+
required:
- compatible
- reg
diff --git a/drivers/rtc/rtc-pcf8523.c b/drivers/rtc/rtc-pcf8523.c
index 2c63c0ffd05a..7ecbee4f9c6b 100644
--- a/drivers/rtc/rtc-pcf8523.c
+++ b/drivers/rtc/rtc-pcf8523.c
@@ -418,6 +418,7 @@ static int pcf8523_probe(struct i2c_client *client)
struct pcf8523 *pcf8523;
struct rtc_device *rtc;
bool wakeup_source = false;
+ bool clockout_disable;
u32 value;
int err;
@@ -467,16 +468,20 @@ static int pcf8523_probe(struct i2c_client *client)
set_bit(RTC_FEATURE_ALARM_RES_MINUTE, rtc->features);
clear_bit(RTC_FEATURE_UPDATE_INTERRUPT, rtc->features);
+ clockout_disable = of_property_read_bool(client->dev.of_node,
+ "clockout-disable");
+ if (client->irq > 0 || clockout_disable) {
+ err = regmap_write(pcf8523->regmap,
+ PCF8523_TMR_CLKOUT_CTRL, 0x38);
+ if (err < 0)
+ return err;
+ }
if (client->irq > 0) {
unsigned long irqflags = IRQF_TRIGGER_LOW;
if (dev_fwnode(&client->dev))
irqflags = 0;
- err = regmap_write(pcf8523->regmap, PCF8523_TMR_CLKOUT_CTRL, 0x38);
- if (err < 0)
- return err;
-
err = devm_request_threaded_irq(&client->dev, client->irq,
NULL, pcf8523_irq,
IRQF_SHARED | IRQF_ONESHOT | irqflags,
--
2.34.1
^ permalink raw reply related
* Re: [PATCH v2 00/11] mfd: macsmc: add rtc, hwmon and hid subdevices
From: Janne Grunau @ 2025-09-25 22:13 UTC (permalink / raw)
To: James Calligeros
Cc: Sven Peter, Alyssa Rosenzweig, Neal Gompa, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, asahi,
linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, Mark Kettenis, Hector Martin
In-Reply-To: <20250827-macsmc-subdevs-v2-0-ce5e99d54c28@gmail.com>
On Wed, Aug 27, 2025 at 09:22:34PM +1000, James Calligeros wrote:
> Hi all,
>
> This series adds support for the remaining SMC subdevices. These are the
> RTC, hwmon, and HID devices. They are being submitted together as the RTC
> and hwmon drivers both require changes to the SMC DT schema.
I we would instantiate all sub devices via MFD_CELL_OF macsmc-hid (or
-input) and the omitted macsmc-power would require SMC dt-binding
changes as well. I'm conflicted on that since both use SMC to determine
if they are present.
Janne
^ permalink raw reply
* Re: [PATCH v2 10/11] arm64: dts: apple: Add common hwmon sensors and fans
From: Janne Grunau @ 2025-09-25 22:02 UTC (permalink / raw)
To: James Calligeros
Cc: Sven Peter, Alyssa Rosenzweig, Neal Gompa, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, asahi,
linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input
In-Reply-To: <20250827-macsmc-subdevs-v2-10-ce5e99d54c28@gmail.com>
On Wed, Aug 27, 2025 at 09:22:44PM +1000, James Calligeros wrote:
> Each Apple Silicon device exposes a unique set of sensors and fans,
> however some have been found to be reliably common across devices.
>
> Add these as .dtsi files so that they can be combined with any
> device-specific sensors without excessive repetition.
>
> Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
> ---
> .../boot/dts/apple/hwmon-common.dtsi | 37 +++++++++++++++++++++++++
> .../boot/dts/apple/hwmon-fan-dual.dtsi | 24 ++++++++++++++++
> arch/arm64/boot/dts/apple/hwmon-fan.dtsi | 19 +++++++++++++
> .../boot/dts/apple/hwmon-laptop.dtsi | 35 +++++++++++++++++++++++
> .../boot/dts/apple/hwmon-mac-mini.dtsi | 17 ++++++++++++
> 5 files changed, 132 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/apple/hwmon-common.dtsi b/arch/arm64/boot/dts/apple/hwmon-common.dtsi
> new file mode 100644
> index 0000000000000000000000000000000000000000..bac4e44d3f9892fe8ad04125e47dcccb2bcf57a0
> --- /dev/null
> +++ b/arch/arm64/boot/dts/apple/hwmon-common.dtsi
> @@ -0,0 +1,37 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later OR MIT
> +/*
> + * Hardawre monitoring sensors expected to be found on all Apple Silicon devices
typo: "Hardawre"
> + *
> + * Copyright The Asahi Linux Contributors
> + */
> +
> +&smc {
> + hwmon {
> + compatible = "apple,smc-hwmon";
I think it woiuld make more sense to add the hwmon child node with the
compatible in the SoC *.dtsi and then only add the sensor nodes to
"&smc_hwmon" in these hwmon-*.dtsi files
Janne
^ permalink raw reply
* Re: [PATCH v2 08/11] mfd: macsmc: Wire up Apple SMC HID subdevice
From: Janne Grunau @ 2025-09-25 21:55 UTC (permalink / raw)
To: James Calligeros
Cc: Sven Peter, Alyssa Rosenzweig, Neal Gompa, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, asahi,
linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input
In-Reply-To: <20250827-macsmc-subdevs-v2-8-ce5e99d54c28@gmail.com>
On Wed, Aug 27, 2025 at 09:22:42PM +1000, James Calligeros wrote:
> Add the new SMC HID function to the mfd device
>
> Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
> ---
> drivers/mfd/macsmc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mfd/macsmc.c b/drivers/mfd/macsmc.c
> index 286dc150aa6cfdd6d29f769094278daaddabe7c3..893fc47d62b2c956d966d1841895a3fa2b9a3005 100644
> --- a/drivers/mfd/macsmc.c
> +++ b/drivers/mfd/macsmc.c
> @@ -45,6 +45,7 @@
> #define SMC_TIMEOUT_MS 500
>
> static const struct mfd_cell apple_smc_devs[] = {
> + MFD_CELL_NAME("macsmc-hid"),
I think it would make sense to use MFD_CELL_OF and device nodes for all
macsmc even though it's in the case of macsmc-input (or -hid) not
strictly necessary
> MFD_CELL_OF("macsmc-gpio", NULL, NULL, 0, 0, "apple,smc-gpio"),
> MFD_CELL_OF("macsmc_hwmon", NULL, NULL, 0, 0, "apple,smc-hwmon"),
> MFD_CELL_OF("macsmc-reboot", NULL, NULL, 0, 0, "apple,smc-reboot"),
Janne
^ permalink raw reply
* Re: [PATCH v2 07/11] input: macsmc-hid: New driver to handle the Apple Mac SMC buttons/lid
From: Janne Grunau @ 2025-09-25 21:49 UTC (permalink / raw)
To: James Calligeros
Cc: Sven Peter, Alyssa Rosenzweig, Neal Gompa, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, asahi,
linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input, Hector Martin
In-Reply-To: <20250827-macsmc-subdevs-v2-7-ce5e99d54c28@gmail.com>
On Wed, Aug 27, 2025 at 09:22:41PM +1000, James Calligeros wrote:
> From: Hector Martin <marcan@marcan.st>
>
> This driver implements power button and lid switch support for Apple Mac
> devices using SMC controllers driven by the macsmc driver.
>
> In addition to basic input support, this also responds to the final
> shutdown warning (when the power button is held down long enough) by
> doing an emergency kernel poweroff. This allows the NVMe controller to
> be cleanly shut down, which prevents data loss for in-cache data.
>
> Signed-off-by: Hector Martin <marcan@marcan.st>
> Co-developed-by: Sven Peter <sven@kernel.org>
> Signed-off-by: Sven Peter <sven@kernel.org>
> Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
> ---
> MAINTAINERS | 1 +
> drivers/input/misc/Kconfig | 11 ++
> drivers/input/misc/Makefile | 1 +
> drivers/input/misc/macsmc-hid.c | 209 +++++++++++++++++++++++++
I would rename this driver to macsmc-input. I would expect hid driver to
live in drivers/hid/ and use HID report descriptors
> 4 files changed, 222 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 2eb23522654dd050262eb06e077587030cc335aa..b3b5220fcd0d4bbef67613c8ee9afa880c0aa45d 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2412,6 +2412,7 @@ F: drivers/hwmon/macsmc_hwmon.c
> F: drivers/pmdomain/apple/
> F: drivers/i2c/busses/i2c-pasemi-core.c
> F: drivers/i2c/busses/i2c-pasemi-platform.c
> +F: drivers/input/misc/macsmc-hid.c
> F: drivers/input/touchscreen/apple_z2.c
> F: drivers/iommu/apple-dart.c
> F: drivers/iommu/io-pgtable-dart.c
> diff --git a/drivers/input/misc/Kconfig b/drivers/input/misc/Kconfig
> index 0fb21c99a5e3d1230d7f40f99e0c2d360bbe80e8..a430c50e7f63f245bba56bd526026ec7901cf821 100644
> --- a/drivers/input/misc/Kconfig
> +++ b/drivers/input/misc/Kconfig
> @@ -961,4 +961,15 @@ config INPUT_STPMIC1_ONKEY
> To compile this driver as a module, choose M here: the
> module will be called stpmic1_onkey.
>
> +config INPUT_MACSMC_HID
> + tristate "Apple Mac SMC lid/buttons"
> + depends on MFD_MACSMC
> + help
> + Say Y here if you want to use the input events delivered via the
> + SMC controller on Apple Mac machines using the macsmc driver.
> + This includes lid open/close and the power button.
> +
> + To compile this driver as a module, choose M here: the
> + module will be called macsmc-hid.
> +
> endif
> diff --git a/drivers/input/misc/Makefile b/drivers/input/misc/Makefile
> index d468c8140b93da5bb537e8a3baea2b90e7bb4229..95b8ebbb9ebbe6f3afc9db724d2ebeba1d75d1a6 100644
> --- a/drivers/input/misc/Makefile
> +++ b/drivers/input/misc/Makefile
> @@ -51,6 +51,7 @@ obj-$(CONFIG_INPUT_IQS7222) += iqs7222.o
> obj-$(CONFIG_INPUT_KEYSPAN_REMOTE) += keyspan_remote.o
> obj-$(CONFIG_INPUT_KXTJ9) += kxtj9.o
> obj-$(CONFIG_INPUT_M68K_BEEP) += m68kspkr.o
> +obj-$(CONFIG_INPUT_MACSMC_HID) += macsmc-hid.o
> obj-$(CONFIG_INPUT_MAX77650_ONKEY) += max77650-onkey.o
> obj-$(CONFIG_INPUT_MAX77693_HAPTIC) += max77693-haptic.o
> obj-$(CONFIG_INPUT_MAX8925_ONKEY) += max8925_onkey.o
> diff --git a/drivers/input/misc/macsmc-hid.c b/drivers/input/misc/macsmc-hid.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..c7cd56e5c17f08936cc623f7d3690f27e05012a5
> --- /dev/null
> +++ b/drivers/input/misc/macsmc-hid.c
> @@ -0,0 +1,209 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Apple SMC input event driver
> + * Copyright The Asahi Linux Contributors
> + *
> + * This driver exposes HID events from the SMC as an input device.
> + * This includes the lid open/close and power button notifications.
> + */
> +
> +#include <linux/device.h>
> +#include <linux/input.h>
> +#include <linux/mfd/core.h>
> +#include <linux/mfd/macsmc.h>
> +#include <linux/module.h>
> +#include <linux/reboot.h>
> +
> +/**
> + * struct macsmc_hid
> + * @dev: Underlying struct device for the HID sub-device
> + * @smc: Pointer to apple_smc struct of the mfd parent
> + * @input: Allocated input_dev; devres managed
> + * @nb: Notifier block used for incoming events from SMC (e.g. button pressed down)
> + * @wakeup_mode: Set to true when system is suspended and power button events should wake it
> + */
> +struct macsmc_hid {
> + struct device *dev;
> + struct apple_smc *smc;
> + struct input_dev *input;
> + struct notifier_block nb;
> + bool wakeup_mode;
> +};
> +
> +#define SMC_EV_BTN 0x7201
> +#define SMC_EV_LID 0x7203
> +
> +#define BTN_POWER 0x01 /* power button on e.g. Mac Mini chasis pressed */
> +#define BTN_TOUCHID 0x06 /* combined TouchID / power button on MacBooks pressed */
> +#define BTN_POWER_HELD_SHORT 0xfe /* power button briefly held down */
> +#define BTN_POWER_HELD_LONG 0x00 /* power button held down; sent just before forced poweroff */
> +
> +static void macsmc_hid_event_button(struct macsmc_hid *smchid, unsigned long event)
> +{
> + u8 button = (event >> 8) & 0xff;
> + u8 state = !!(event & 0xff);
> +
> + switch (button) {
> + case BTN_POWER:
> + case BTN_TOUCHID:
> + if (smchid->wakeup_mode) {
> + if (state)
> + pm_wakeup_hard_event(smchid->dev);
> + } else {
> + input_report_key(smchid->input, KEY_POWER, state);
> + input_sync(smchid->input);
> + }
> + break;
> + case BTN_POWER_HELD_SHORT: /* power button held down; ignore */
> + break;
> + case BTN_POWER_HELD_LONG:
> + /*
> + * If we get here the power button has been held down for a while and
> + * we have about 4 seconds before forced power-off is triggered by SMC.
> + * Try to do an emergency shutdown to make sure the NVMe cache is
> + * flushed. macOS actually does this by panicing (!)...
> + */
> + if (state) {
> + dev_crit(smchid->dev, "Triggering forced shutdown!\n");
> + if (kernel_can_power_off())
> + kernel_power_off();
> + else /* Missing macsmc-reboot driver? */
> + kernel_restart("SMC power button triggered restart");
> + }
> + break;
> + default:
> + dev_warn(smchid->dev, "Unknown SMC button event: %04lx\n", event & 0xffff);
> + }
> +}
> +
> +static void macsmc_hid_event_lid(struct macsmc_hid *smchid, unsigned long event)
> +{
> + u8 lid_state = !!((event >> 8) & 0xff);
> +
> + if (smchid->wakeup_mode && !lid_state)
> + pm_wakeup_hard_event(smchid->dev);
> +
> + input_report_switch(smchid->input, SW_LID, lid_state);
> + input_sync(smchid->input);
> +}
> +
> +static int macsmc_hid_event(struct notifier_block *nb, unsigned long event, void *data)
> +{
> + struct macsmc_hid *smchid = container_of(nb, struct macsmc_hid, nb);
> + u16 type = event >> 16;
> +
> + switch (type) {
> + case SMC_EV_BTN:
> + macsmc_hid_event_button(smchid, event);
> + return NOTIFY_OK;
> + case SMC_EV_LID:
> + macsmc_hid_event_lid(smchid, event);
> + return NOTIFY_OK;
> + default:
> + /* SMC event meant for another driver */
> + return NOTIFY_DONE;
> + }
> +}
> +
> +static int macsmc_hid_probe(struct platform_device *pdev)
> +{
> + struct apple_smc *smc = dev_get_drvdata(pdev->dev.parent);
> + struct macsmc_hid *smchid;
> + bool have_lid, have_power;
> + int ret;
> +
> + /* Bail early if this SMC neither supports power button nor lid events */
> + have_lid = apple_smc_key_exists(smc, SMC_KEY(MSLD));
> + have_power = apple_smc_key_exists(smc, SMC_KEY(bHLD));
> + if (!have_lid && !have_power)
> + return -ENODEV;
> +
> + smchid = devm_kzalloc(&pdev->dev, sizeof(*smchid), GFP_KERNEL);
> + if (!smchid)
> + return -ENOMEM;
> +
> + smchid->dev = &pdev->dev;
> + smchid->smc = smc;
> + platform_set_drvdata(pdev, smchid);
> +
> + smchid->input = devm_input_allocate_device(&pdev->dev);
> + if (!smchid->input)
> + return -ENOMEM;
> +
> + smchid->input->phys = "macsmc-hid (0)";
> + smchid->input->name = "Apple SMC power/lid events";
> +
> + if (have_lid)
> + input_set_capability(smchid->input, EV_SW, SW_LID);
> + if (have_power)
> + input_set_capability(smchid->input, EV_KEY, KEY_POWER);
> +
> + ret = input_register_device(smchid->input);
> + if (ret) {
> + dev_err(&pdev->dev, "Failed to register input device: %d\n", ret);
> + return ret;
> + }
> +
> + if (have_lid) {
> + u8 val;
> +
> + ret = apple_smc_read_u8(smc, SMC_KEY(MSLD), &val);
> + if (ret < 0)
> + dev_warn(&pdev->dev, "Failed to read initial lid state\n");
> + else
> + input_report_switch(smchid->input, SW_LID, val);
> + }
> +
> + if (have_power) {
> + u32 val;
> +
> + ret = apple_smc_read_u32(smc, SMC_KEY(bHLD), &val);
> + if (ret < 0)
> + dev_warn(&pdev->dev, "Failed to read initial power button state\n");
> + else
> + input_report_key(smchid->input, KEY_POWER, val & 1);
> + }
> +
> + input_sync(smchid->input);
> +
> + smchid->nb.notifier_call = macsmc_hid_event;
> + blocking_notifier_chain_register(&smc->event_handlers, &smchid->nb);
> +
> + device_init_wakeup(&pdev->dev, 1);
> +
> + return 0;
> +}
> +
> +static int macsmc_hid_pm_prepare(struct device *dev)
> +{
> + struct macsmc_hid *smchid = dev_get_drvdata(dev);
> +
> + smchid->wakeup_mode = true;
> + return 0;
> +}
> +
> +static void macsmc_hid_pm_complete(struct device *dev)
> +{
> + struct macsmc_hid *smchid = dev_get_drvdata(dev);
> +
> + smchid->wakeup_mode = false;
> +}
> +
> +static const struct dev_pm_ops macsmc_hid_pm_ops = {
> + .prepare = macsmc_hid_pm_prepare,
> + .complete = macsmc_hid_pm_complete,
> +};
> +
> +static struct platform_driver macsmc_hid_driver = {
> + .driver = {
> + .name = "macsmc-hid",
> + .pm = &macsmc_hid_pm_ops,
> + },
> + .probe = macsmc_hid_probe,
> +};
> +module_platform_driver(macsmc_hid_driver);
> +
> +MODULE_AUTHOR("Hector Martin <marcan@marcan.st>");
> +MODULE_LICENSE("Dual MIT/GPL");
> +MODULE_DESCRIPTION("Apple SMC HID driver");
> +MODULE_ALIAS("platform:macsmc-hid");
The module alias should be removed.
Janne
^ permalink raw reply
* Re: [PATCH v2 02/11] dt-bindings: hwmon: Add Apple System Management Controller hwmon schema
From: Rob Herring @ 2025-09-25 21:43 UTC (permalink / raw)
To: Janne Grunau
Cc: James Calligeros, Sven Peter, Alyssa Rosenzweig, Neal Gompa,
Lee Jones, Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, asahi,
linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input
In-Reply-To: <20250925204925.GA637503@robin.jannau.net>
On Thu, Sep 25, 2025 at 3:49 PM Janne Grunau <j@jannau.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@gmail.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
^ permalink raw reply
* Re: [PATCH v2 05/11] hwmon: Add Apple Silicon SMC hwmon driver
From: Janne Grunau @ 2025-09-25 21:33 UTC (permalink / raw)
To: James Calligeros
Cc: Sven Peter, Alyssa Rosenzweig, Neal Gompa, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, asahi,
linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input
In-Reply-To: <20250827-macsmc-subdevs-v2-5-ce5e99d54c28@gmail.com>
On Wed, Aug 27, 2025 at 09:22:39PM +1000, James Calligeros wrote:
> The System Management Controller on Apple Silicon devices is responsible
> for integrating and exposing the data reported by the vast array of
> hardware monitoring sensors present on these devices. It is also
> responsible for fan control, and allows users to manually set fan
> speeds if they so desire. Add a hwmon driver to expose current,
> power, temperature, and voltage monitoring sensors, as well as
> fan speed monitoring and control via the SMC on Apple Silicon devices.
>
> The SMC firmware has no consistency between devices, even when they
> share an SoC. The FourCC keys used to access sensors are almost
> random. An M1 Mac mini will have different FourCCs for its CPU core
> temperature sensors to an M1 MacBook Pro, for example. For this
> reason, the valid sensors for a given device are specified in a
> child of the SMC Devicetree node. The driver uses this information
> to determine which sensors to make available at runtime.
>
> Co-developed-by: Janne Grunau <j@jannau.net>
> Signed-off-by: Janne Grunau <j@jannau.net>
> Signed-off-by: James Calligeros <jcalligeros99@gmail.com>
> ---
> MAINTAINERS | 1 +
> drivers/hwmon/Kconfig | 12 +
> drivers/hwmon/Makefile | 1 +
> drivers/hwmon/macsmc_hwmon.c | 848 +++++++++++++++++++++++++
Please use macsmc-hwmon.c as name. All other macsmc sub device drivers
use '-' and it's more common in 'drivers/hwmon/*.c'
> 4 files changed, 862 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 5d53d243dc9abdf1db5865f8e6bcddbac3eafebe..2eb23522654dd050262eb06e077587030cc335aa 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -2408,6 +2408,7 @@ F: drivers/clk/clk-apple-nco.c
> F: drivers/cpufreq/apple-soc-cpufreq.c
> F: drivers/dma/apple-admac.c
> F: drivers/gpio/gpio-macsmc.c
> +F: drivers/hwmon/macsmc_hwmon.c
> F: drivers/pmdomain/apple/
> F: drivers/i2c/busses/i2c-pasemi-core.c
> F: drivers/i2c/busses/i2c-pasemi-platform.c
> diff --git a/drivers/hwmon/Kconfig b/drivers/hwmon/Kconfig
> index 9d28fcf7cd2a6f9e2f54694a717bd85ff4047b46..1ca6db71e4d9da32717fd14487c10944433ada41 100644
> --- a/drivers/hwmon/Kconfig
> +++ b/drivers/hwmon/Kconfig
> @@ -1164,6 +1164,18 @@ config SENSORS_LTQ_CPUTEMP
> If you say yes here you get support for the temperature
> sensor inside your CPU.
>
> +config SENSORS_MACSMC_HWMON
> + tristate "Apple SMC (Apple Silicon)"
> + depends on MFD_MACSMC && OF
> + help
> + This driver enables hwmon support for current, power, temperature,
> + and voltage sensors, as well as fan speed reporting and control
> + on Apple Silicon devices. Say Y here if you have an Apple Silicon
> + device.
> +
> + This driver can also be built as a module. If so, the module will
> + be called macsmc_hwmon.
macsmc-hwmon
> +
> config SENSORS_MAX1111
> tristate "Maxim MAX1111 Serial 8-bit ADC chip and compatibles"
> depends on SPI_MASTER
> diff --git a/drivers/hwmon/Makefile b/drivers/hwmon/Makefile
> index cd8bc4752b4dbf015c6eb46157626f4e8f87dfae..80fc8447aff15b3b8e8583dc755c8accb3b6a93e 100644
> --- a/drivers/hwmon/Makefile
> +++ b/drivers/hwmon/Makefile
> @@ -147,6 +147,7 @@ obj-$(CONFIG_SENSORS_LTC4260) += ltc4260.o
> obj-$(CONFIG_SENSORS_LTC4261) += ltc4261.o
> obj-$(CONFIG_SENSORS_LTC4282) += ltc4282.o
> obj-$(CONFIG_SENSORS_LTQ_CPUTEMP) += ltq-cputemp.o
> +obj-$(CONFIG_SENSORS_MACSMC_HWMON) += macsmc_hwmon.o
> obj-$(CONFIG_SENSORS_MAX1111) += max1111.o
> obj-$(CONFIG_SENSORS_MAX127) += max127.o
> obj-$(CONFIG_SENSORS_MAX16065) += max16065.o
> diff --git a/drivers/hwmon/macsmc_hwmon.c b/drivers/hwmon/macsmc_hwmon.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..e44ea357870238aa0b38d7b674a6c456271fdf0c
> --- /dev/null
> +++ b/drivers/hwmon/macsmc_hwmon.c
> @@ -0,0 +1,848 @@
> +// SPDX-License-Identifier: GPL-2.0-only OR MIT
> +/*
> + * Apple SMC hwmon driver for Apple Silicon platforms
> + *
> + * The System Management Controller on Apple Silicon devices is responsible for
> + * measuring data from sensors across the SoC and machine. These include power,
> + * temperature, voltage and current sensors. Some "sensors" actually expose
> + * derived values. An example of this is the key PHPC, which is an estimate
> + * of the heat energy being dissipated by the SoC.
> + *
> + * While each SoC only has one SMC variant, each platform exposes a different
> + * set of sensors. For example, M1 MacBooks expose battery telemetry sensors
> + * which are not present on the M1 Mac mini. For this reason, the available
> + * sensors for a given platform are described in the device tree in a child
> + * node of the SMC device. We must walk this list of available sensors and
> + * populate the required hwmon data structures at runtime.
> + *
> + * Originally based on a concept by Jean-Francois Bortolotti <jeff@borto.fr>
> + *
> + * Copyright The Asahi Linux Contributors
> + */
> +
> +#include <linux/hwmon.h>
> +#include <linux/hwmon-sysfs.h>
> +#include <linux/mfd/macsmc.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +
> +#define MAX_LABEL_LENGTH 32
> +#define NUM_SENSOR_TYPES 5 /* temp, volt, current, power, fan */
I would write voltage and temperature out. At least in comments.
Shortening "voltage" to volt seems strange when "current" and "power"
are used otherwise.
> +
> +#define FLT_EXP_BIAS 127
> +#define FLT_EXP_MASK GENMASK(30, 23)
> +#define FLT_MANT_BIAS 23
> +#define FLT_MANT_MASK GENMASK(22, 0)
> +#define FLT_SIGN_MASK BIT(31)
> +
> +static bool fan_control;
> +module_param_unsafe(fan_control, bool, 0644);
> +MODULE_PARM_DESC(fan_control,
> + "Override the SMC to set your own fan speeds on supported machines");
> +
> +struct macsmc_hwmon_sensor {
> + struct apple_smc_key_info info;
> + smc_key macsmc_key;
> + char label[MAX_LABEL_LENGTH];
> +};
> +
> +struct macsmc_hwmon_fan {
> + struct macsmc_hwmon_sensor now;
> + struct macsmc_hwmon_sensor min;
> + struct macsmc_hwmon_sensor max;
> + struct macsmc_hwmon_sensor set;
> + struct macsmc_hwmon_sensor mode;
> + char label[MAX_LABEL_LENGTH];
> + u32 attrs;
> + bool manual;
> +};
> +
> +struct macsmc_hwmon_sensors {
> + struct hwmon_channel_info channel_info;
> + struct macsmc_hwmon_sensor *sensors;
> + u32 count;
> +};
> +
> +struct macsmc_hwmon_fans {
> + struct hwmon_channel_info channel_info;
> + struct macsmc_hwmon_fan *fans;
> + u32 count;
> +};
> +
> +struct macsmc_hwmon {
> + struct device *dev;
> + struct apple_smc *smc;
> + struct device *hwmon_dev;
> + struct hwmon_chip_info chip_info;
> + /* Chip + sensor types + NULL */
> + const struct hwmon_channel_info *channel_infos[1 + NUM_SENSOR_TYPES + 1];
> + struct macsmc_hwmon_sensors temp;
> + struct macsmc_hwmon_sensors volt;
> + struct macsmc_hwmon_sensors curr;
matching the "hwmon_*" names is a convincing argument not sure what to
do about the voltage sensors though
> + struct macsmc_hwmon_sensors power;
> + struct macsmc_hwmon_fans fan;
> +};
> +
> +static int macsmc_hwmon_read_label(struct device *dev,
> + enum hwmon_sensor_types type, u32 attr,
> + int channel, const char **str)
> +{
> + struct macsmc_hwmon *hwmon = dev_get_drvdata(dev);
> +
> + switch (type) {
> + case hwmon_temp:
> + if (channel >= hwmon->temp.count)
> + return -EINVAL;
> + *str = hwmon->temp.sensors[channel].label;
> + break;
> + case hwmon_in:
> + if (channel >= hwmon->volt.count)
> + return -EINVAL;
> + *str = hwmon->volt.sensors[channel].label;
> + break;
> + case hwmon_curr:
> + if (channel >= hwmon->curr.count)
> + return -EINVAL;
> + *str = hwmon->curr.sensors[channel].label;
> + break;
> + case hwmon_power:
> + if (channel >= hwmon->power.count)
> + return -EINVAL;
> + *str = hwmon->power.sensors[channel].label;
> + break;
> + case hwmon_fan:
> + if (channel >= hwmon->fan.count)
> + return -EINVAL;
> + *str = hwmon->fan.fans[channel].label;
> + break;
> + default:
> + return -EOPNOTSUPP;
> + }
> +
> + return 0;
> +}
> +
> +/*
> + * A number of sensors report data in a 48.16 fixed-point decimal format that is
> + * not used by any other function of the SMC.
> + */
> +static int macsmc_hwmon_read_ioft_scaled(struct apple_smc *smc, smc_key key,
> + u64 *p, int scale)
> +{
> + u64 val;
> + int ret;
> +
> + ret = apple_smc_read_u64(smc, key, &val);
> + if (ret < 0)
> + return ret;
> +
> + *p = mult_frac(val, scale, 65536);
> +
> + return 0;
> +}
> +
> +/*
> + * Many sensors report their data as IEEE-754 floats. No other SMC function uses
> + * them.
> + */
> +static int macsmc_hwmon_read_f32_scaled(struct apple_smc *smc, smc_key key,
> + int *p, int scale)
> +{
> + u32 fval;
> + u64 val;
> + int ret, exp;
> +
> + ret = apple_smc_read_u32(smc, key, &fval);
> + if (ret < 0)
> + return ret;
> +
> + val = ((u64)((fval & FLT_MANT_MASK) | BIT(23)));
> + exp = ((fval >> 23) & 0xff) - FLT_EXP_BIAS - FLT_MANT_BIAS;
> + if (scale < 0) {
> + val <<= 32;
> + exp -= 32;
> + val /= -scale;
64-bit division is not universally available. The easiest solution for
Apple silicon would be to depend on CONFIG_64BIT. However so far
macsmc_hwmon_read_key() is only called with positive scale values so it
would make sense to just not support negative scale values.
> + } else {
> + val *= scale;
> + }
> +
> + if (exp > 63)
> + val = U64_MAX;
> + else if (exp < -63)
> + val = 0;
> + else if (exp < 0)
> + val >>= -exp;
> + else if (exp != 0 && (val & ~((1UL << (64 - exp)) - 1))) /* overflow */
> + val = U64_MAX;
> + else
> + val <<= exp;
> +
> + if (fval & FLT_SIGN_MASK) {
> + if (val > (-(s64)INT_MIN))
> + *p = INT_MIN;
> + else
> + *p = -val;
> + } else {
> + if (val > INT_MAX)
> + *p = INT_MAX;
> + else
> + *p = val;
> + }
> +
> + return 0;
> +}
> +
> +/*
> + * The SMC has keys of multiple types, denoted by a FourCC of the same format
> + * as the key ID. We don't know what data type a key encodes until we poke at it.
> + */
> +static int macsmc_hwmon_read_key(struct apple_smc *smc,
> + struct macsmc_hwmon_sensor *sensor, int scale,
> + long *val)
> +{
> + int ret;
> +
> + switch (sensor->info.type_code) {
> + /* 32-bit IEEE 754 float */
> + case _SMC_KEY("flt "): {
This fails here with gcc (GCC) 15.2.1 20250808 (Red Hat 15.2.1-1)"
"error: case label does not reduce to an integer constant"
The same for the other "case _SMC_KEY()" statements
> + u32 flt_ = 0;
> +
> + ret = macsmc_hwmon_read_f32_scaled(smc, sensor->macsmc_key,
> + &flt_, scale);
> + *val = flt_;
> + break;
> + }
> + /* 48.16 fixed point decimal */
> + case _SMC_KEY("ioft"): {
> + u64 ioft = 0;
> +
> + ret = macsmc_hwmon_read_ioft_scaled(smc, sensor->macsmc_key,
> + &ioft, scale);
> + *val = (long)ioft;
> + break;
> + }
> + default:
> + return -EOPNOTSUPP;
> + }
> +
> + if (ret)
> + return -EINVAL;
> +
> + return 0;
> +}
> +
> +static int macsmc_hwmon_write_f32_scaled(struct apple_smc *smc, smc_key key,
> + int value, int scale)
> +{
> + u64 val;
> + u32 fval = 0;
> + int exp, neg;
> +
> + val = abs(value);
> + neg = val != value;
> +
> + if (scale > 1) {
> + val <<= 32;
> + exp = 32;
> + val /= scale;
Similar here. macsmc_hwmon_write_key() is only called with scale == 1
> + } else if (scale < 1) {
> + val *= -scale;
> + }
> +
> + if (val) {
> + int msb = __fls(val) - exp;
> +
> + if (msb > 23) {
> + val >>= msb - 23;
> + exp -= msb - 23;
> + } else if (msb < 23) {
> + val <<= 23 - msb;
> + exp += msb;
> + }
> +
> + fval = FIELD_PREP(FLT_SIGN_MASK, neg) |
> + FIELD_PREP(FLT_EXP_MASK, exp + FLT_EXP_BIAS) |
> + FIELD_PREP(FLT_MANT_MASK, val);
> + }
> +
> + return apple_smc_write_u32(smc, key, fval);
> +}
> +
> +static int macsmc_hwmon_write_key(struct apple_smc *smc,
> + struct macsmc_hwmon_sensor *sensor, long val,
> + int scale)
> +{
> + switch (sensor->info.type_code) {
> + /* 32-bit IEEE 754 float */
> + case _SMC_KEY("flt "):
> + return macsmc_hwmon_write_f32_scaled(smc, sensor->macsmc_key,
> + val, scale);
> + /* unsigned 8-bit integer */
> + case _SMC_KEY("ui8 "):
> + return apple_smc_write_u8(smc, sensor->macsmc_key, val);
> + default:
> + return -EOPNOTSUPP;
> + }
> +}
> +
> +static int macsmc_hwmon_read_fan(struct macsmc_hwmon *hwmon, u32 attr, int chan,
> + long *val)
> +{
> + if (!(hwmon->fan.fans[chan].attrs & BIT(attr)))
> + return -EINVAL;
> +
> + switch (attr) {
> + case hwmon_fan_input:
> + return macsmc_hwmon_read_key(hwmon->smc,
> + &hwmon->fan.fans[chan].now, 1, val);
> + case hwmon_fan_min:
> + return macsmc_hwmon_read_key(hwmon->smc,
> + &hwmon->fan.fans[chan].min, 1, val);
> + case hwmon_fan_max:
> + return macsmc_hwmon_read_key(hwmon->smc,
> + &hwmon->fan.fans[chan].max, 1, val);
> + case hwmon_fan_target:
> + return macsmc_hwmon_read_key(hwmon->smc,
> + &hwmon->fan.fans[chan].set, 1, val);
> + default:
> + return -EINVAL;
> + }
> +}
> +
> +static int macsmc_hwmon_write_fan(struct device *dev, u32 attr, int channel,
> + long val)
> +{
> + struct macsmc_hwmon *hwmon = dev_get_drvdata(dev);
> + long min, max;
> + int ret;
> +
> + if (!fan_control || hwmon->fan.fans[channel].mode.macsmc_key == 0)
> + return -EOPNOTSUPP;
> +
> + if (channel >= hwmon->fan.count ||
> + !(hwmon->fan.fans[channel].attrs & BIT(attr)) ||
> + attr != hwmon_fan_target)
> + return -EINVAL;
> +
> + /*
> + * The SMC does no sanity checks on requested fan speeds, so we need to.
> + */
> + ret = macsmc_hwmon_read_key(hwmon->smc, &hwmon->fan.fans[channel].min,
> + 1, &min);
> + if (ret)
> + return ret;
> +
> + ret = macsmc_hwmon_read_key(hwmon->smc, &hwmon->fan.fans[channel].max,
> + 1, &max);
> + if (ret)
> + return ret;
> +
> + if (val >= min && val <= max) {
> + if (!hwmon->fan.fans[channel].manual) {
> + /* Write 1 to mode key for manual control */
> + ret = macsmc_hwmon_write_key(hwmon->smc,
> + &hwmon->fan.fans[channel].mode, 1,
> + 1);
> + if (ret < 0)
> + return ret;
> +
> + hwmon->fan.fans[channel].manual = true;
> + }
> + return macsmc_hwmon_write_key(hwmon->smc,
> + &hwmon->fan.fans[channel].set, val, 1);
> + } else if (!val) {
> + if (hwmon->fan.fans[channel].manual) {
> + ret = macsmc_hwmon_write_key(hwmon->smc,
> + &hwmon->fan.fans[channel].mode, 0, 1);
> + if (ret < 0)
> + return ret;
> +
> + hwmon->fan.fans[channel].manual = false;
> + }
> + } else {
> + return -EINVAL;
> + }
> +
> + return 0;
> +}
> +
> +static int macsmc_hwmon_read(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long *val)
> +{
> + struct macsmc_hwmon *hwmon = dev_get_drvdata(dev);
> + int ret = 0;
> +
> + switch (type) {
> + case hwmon_temp:
> + ret = macsmc_hwmon_read_key(hwmon->smc,
> + &hwmon->temp.sensors[channel], 1000, val);
> + break;
> + case hwmon_in:
> + ret = macsmc_hwmon_read_key(hwmon->smc,
> + &hwmon->volt.sensors[channel], 1000, val);
> + break;
> + case hwmon_curr:
> + ret = macsmc_hwmon_read_key(hwmon->smc,
> + &hwmon->curr.sensors[channel], 1000, val);
> + break;
> + case hwmon_power:
> + /* SMC returns power in Watts with acceptable precision to scale to uW */
> + ret = macsmc_hwmon_read_key(hwmon->smc,
> + &hwmon->power.sensors[channel],
> + 1000000, val);
> + break;
> + case hwmon_fan:
> + ret = macsmc_hwmon_read_fan(hwmon, attr, channel, val);
> + break;
> + default:
> + return -EOPNOTSUPP;
> + }
> +
> + return ret;
> +}
> +
> +static int macsmc_hwmon_write(struct device *dev, enum hwmon_sensor_types type,
> + u32 attr, int channel, long val)
> +{
> + switch (type) {
> + case hwmon_fan:
> + return macsmc_hwmon_write_fan(dev, attr, channel, val);
> + default:
> + return -EOPNOTSUPP;
> + }
> +}
> +
> +static umode_t macsmc_hwmon_fan_is_visible(const void *data, u32 attr,
> + int channel)
> +{
> + const struct macsmc_hwmon *hwmon = data;
> +
> + if (fan_control && attr == hwmon_fan_target &&
> + hwmon->fan.fans[channel].mode.macsmc_key != 0)
> + return 0644;
> +
> + return 0444;
> +}
> +
> +static umode_t macsmc_hwmon_is_visible(const void *data,
> + enum hwmon_sensor_types type, u32 attr,
> + int channel)
> +{
> + switch (type) {
> + case hwmon_fan:
> + return macsmc_hwmon_fan_is_visible(data, attr, channel);
> + default:
> + break;
> + }
> +
> + return 0444;
> +}
> +
> +static const struct hwmon_ops macsmc_hwmon_ops = {
> + .is_visible = macsmc_hwmon_is_visible,
> + .read = macsmc_hwmon_read,
> + .read_string = macsmc_hwmon_read_label,
> + .write = macsmc_hwmon_write,
> +};
> +
> +/*
> + * Get the key metadata, including key data type, from the SMC.
> + */
> +static int macsmc_hwmon_parse_key(struct device *dev, struct apple_smc *smc,
> + struct macsmc_hwmon_sensor *sensor,
> + const char *key)
> +{
> + int ret;
> +
> + ret = apple_smc_get_key_info(smc, _SMC_KEY(key), &sensor->info);
> + if (ret) {
> + dev_err(dev, "Failed to retrieve key info for %s\n", key);
> + return ret;
> + }
> +
> + sensor->macsmc_key = _SMC_KEY(key);
> +
> + return 0;
> +}
> +
> +/*
> + * A sensor is a single key-value pair as made available by the SMC.
> + * The devicetree gives us the SMC key ID and a friendly name where the
> + * purpose of the sensor is known.
> + */
> +static int macsmc_hwmon_create_sensor(struct device *dev, struct apple_smc *smc,
> + struct device_node *sensor_node,
> + struct macsmc_hwmon_sensor *sensor)
> +{
> + const char *key, *label;
> + int ret;
> +
> + ret = of_property_read_string(sensor_node, "apple,key-id", &key);
> + if (ret) {
> + dev_err(dev, "Could not find apple,key-id in sensor node\n");
> + return ret;
> + }
> +
> + ret = macsmc_hwmon_parse_key(dev, smc, sensor, key);
> + if (ret)
> + return ret;
> +
> + ret = of_property_read_string(sensor_node, "label", &label);
> + if (ret) {
> + dev_err(dev, "No label found for sensor %s\n", key);
see discussion in the dt-bindings patch, if the label is just for human
convenience this should not fail but use the key-id as fallback.
> + return ret;
> + }
> +
> + strscpy_pad(sensor->label, label, sizeof(sensor->label));
> +
> + return 0;
> +}
> +
> +/*
> + * Fan data is exposed by the SMC as multiple sensors.
> + *
> + * The devicetree schema reuses apple,key-id for the actual fan speed sensor.
> + * Min, max and target keys do not need labels, so we can reuse label
> + * for naming the entire fan.
> + */
> +static int macsmc_hwmon_create_fan(struct device *dev, struct apple_smc *smc,
> + struct device_node *fan_node,
> + struct macsmc_hwmon_fan *fan)
> +{
> + const char *label, *now, *min, *max, *set, *mode;
> + int ret;
> +
> + ret = of_property_read_string(fan_node, "apple,key-id", &now);
> + if (ret) {
> + dev_err(dev, "apple,key-id not found in fan node!\n");
> + return -EINVAL;
> + }
> +
> + ret = macsmc_hwmon_parse_key(dev, smc, &fan->now, now);
> + if (ret)
> + return ret;
> +
> + ret = of_property_read_string(fan_node, "label", &label);
> + if (ret) {
> + dev_err(dev, "No label found for fan %s\n", now);
> + return ret;
> + }
> +
> + strscpy_pad(fan->label, label, sizeof(fan->label));
> +
> + fan->attrs = HWMON_F_LABEL | HWMON_F_INPUT;
> +
> + /* The following keys are not required to simply monitor fan speed */
> + if (!of_property_read_string(fan_node, "apple,fan-minimum", &min)) {
> + ret = macsmc_hwmon_parse_key(dev, smc, &fan->min, min);
> + if (ret)
> + return ret;
> +
> + fan->attrs |= HWMON_F_MIN;
> + }
> +
> + if (!of_property_read_string(fan_node, "apple,fan-maximum", &max)) {
> + ret = macsmc_hwmon_parse_key(dev, smc, &fan->max, max);
> + if (ret)
> + return ret;
> +
> + fan->attrs |= HWMON_F_MAX;
> + }
> +
> + if (!of_property_read_string(fan_node, "apple,fan-target", &set)) {
> + ret = macsmc_hwmon_parse_key(dev, smc, &fan->set, set);
> + if (ret)
> + return ret;
> +
> + fan->attrs |= HWMON_F_TARGET;
> + }
> +
> + if (!of_property_read_string(fan_node, "apple,fan-mode", &mode)) {
> + ret = macsmc_hwmon_parse_key(dev, smc, &fan->mode, mode);
> + if (ret)
> + return ret;
> + }
> +
> + /* Initialise fan control mode to automatic */
> + fan->manual = false;
> +
> + return 0;
> +}
> +
> +static int macsmc_hwmon_populate_sensors(struct macsmc_hwmon *hwmon,
> + struct device_node *hwmon_node)
> +{
> + struct device_node *key_node __maybe_unused;
> + u32 n_current = 0, n_fan = 0, n_power = 0, n_temperature = 0, n_voltage = 0;
> +
> + for_each_child_of_node_with_prefix(hwmon_node, key_node, "current-") {
> + n_current++;
> + }
> +
> + if (n_current) {
> + hwmon->curr.sensors = devm_kcalloc(hwmon->dev, n_current,
> + sizeof(struct macsmc_hwmon_sensor), GFP_KERNEL);
> + if (!hwmon->curr.sensors)
> + return -ENOMEM;
> +
> + for_each_child_of_node_with_prefix(hwmon_node, key_node, "current-") {
> + if (!macsmc_hwmon_create_sensor(hwmon->dev, hwmon->smc, key_node,
> + &hwmon->curr.sensors[hwmon->curr.count]))
> + hwmon->curr.count++;
> + }
> + }
> +
> + for_each_child_of_node_with_prefix(hwmon_node, key_node, "fan-") {
> + n_fan++;
> + }
> +
> + if (n_fan) {
> + hwmon->fan.fans = devm_kcalloc(hwmon->dev, n_fan,
> + sizeof(struct macsmc_hwmon_fan), GFP_KERNEL);
> + if (!hwmon->fan.fans)
> + return -ENOMEM;
> +
> + for_each_child_of_node_with_prefix(hwmon_node, key_node, "fan-") {
> + if (!macsmc_hwmon_create_fan(hwmon->dev, hwmon->smc, key_node,
> + &hwmon->fan.fans[hwmon->fan.count]))
> + hwmon->fan.count++;
> + }
> + }
> +
> + for_each_child_of_node_with_prefix(hwmon_node, key_node, "power-") {
> + n_power++;
> + }
> +
> + if (n_power) {
> + hwmon->power.sensors = devm_kcalloc(hwmon->dev, n_power,
> + sizeof(struct macsmc_hwmon_sensor), GFP_KERNEL);
> + if (!hwmon->power.sensors)
> + return -ENOMEM;
> +
> + for_each_child_of_node_with_prefix(hwmon_node, key_node, "power-") {
> + if (!macsmc_hwmon_create_sensor(hwmon->dev, hwmon->smc, key_node,
> + &hwmon->power.sensors[hwmon->power.count]))
> + hwmon->power.count++;
> + }
> + }
> +
> + for_each_child_of_node_with_prefix(hwmon_node, key_node, "temperature-") {
> + n_temperature++;
> + }
> +
> + if (n_temperature) {
> + hwmon->temp.sensors = devm_kcalloc(hwmon->dev, n_temperature,
> + sizeof(struct macsmc_hwmon_sensor), GFP_KERNEL);
> + if (!hwmon->temp.sensors)
> + return -ENOMEM;
> +
> + for_each_child_of_node_with_prefix(hwmon_node, key_node, "temperature-") {
> + if (!macsmc_hwmon_create_sensor(hwmon->dev, hwmon->smc, key_node,
> + &hwmon->temp.sensors[hwmon->temp.count]))
> + hwmon->temp.count++;
> + }
> + }
> +
> + for_each_child_of_node_with_prefix(hwmon_node, key_node, "voltage-") {
> + n_voltage++;
> + }
> +
> + if (n_voltage) {
> + hwmon->volt.sensors = devm_kcalloc(hwmon->dev, n_voltage,
> + sizeof(struct macsmc_hwmon_sensor), GFP_KERNEL);
> + if (!hwmon->volt.sensors)
> + return -ENOMEM;
> +
> + for_each_child_of_node_with_prefix(hwmon_node, key_node, "volt-") {
> + if (!macsmc_hwmon_create_sensor(hwmon->dev, hwmon->smc, key_node,
> + &hwmon->volt.sensors[hwmon->volt.count]))
> + hwmon->volt.count++;
> + }
> + }
> +
> + return 0;
> +}
> +
> +/* Create NULL-terminated config arrays */
> +static void macsmc_hwmon_populate_configs(u32 *configs, u32 num_keys, u32 flags)
> +{
> + int idx;
> +
> + for (idx = 0; idx < num_keys; idx++)
> + configs[idx] = flags;
> +}
> +
> +static void macsmc_hwmon_populate_fan_configs(u32 *configs, u32 num_keys,
> + struct macsmc_hwmon_fans *fans)
> +{
> + int idx;
> +
> + for (idx = 0; idx < num_keys; idx++)
> + configs[idx] = fans->fans[idx].attrs;
> +}
> +
> +static const struct hwmon_channel_info *const macsmc_chip_channel_info =
> + HWMON_CHANNEL_INFO(chip, HWMON_C_REGISTER_TZ);
> +
> +static int macsmc_hwmon_create_infos(struct macsmc_hwmon *hwmon)
> +{
> + struct hwmon_channel_info *channel_info;
> + int i = 0;
> +
> + /* chip */
> + hwmon->channel_infos[i++] = macsmc_chip_channel_info;
> +
> + if (hwmon->curr.count) {
> + channel_info = &hwmon->curr.channel_info;
> + channel_info->type = hwmon_curr;
> + channel_info->config = devm_kcalloc(hwmon->dev, hwmon->curr.count + 1,
> + sizeof(u32), GFP_KERNEL);
> + if (!channel_info->config)
> + return -ENOMEM;
> +
> + macsmc_hwmon_populate_configs((u32 *)channel_info->config,
> + hwmon->curr.count,
> + (HWMON_C_INPUT | HWMON_C_LABEL));
> + hwmon->channel_infos[i++] = channel_info;
> + }
> +
> + if (hwmon->fan.count) {
> + channel_info = &hwmon->fan.channel_info;
> + channel_info->type = hwmon_fan;
> + channel_info->config = devm_kcalloc(hwmon->dev, hwmon->fan.count + 1,
> + sizeof(u32), GFP_KERNEL);
> + if (!channel_info->config)
> + return -ENOMEM;
> +
> + macsmc_hwmon_populate_fan_configs((u32 *)channel_info->config,
> + hwmon->fan.count,
> + &hwmon->fan);
> + hwmon->channel_infos[i++] = channel_info;
> + }
> +
> + if (hwmon->power.count) {
> + channel_info = &hwmon->power.channel_info;
> + channel_info->type = hwmon_power;
> + channel_info->config = devm_kcalloc(hwmon->dev, hwmon->power.count + 1,
> + sizeof(u32), GFP_KERNEL);
> + if (!channel_info->config)
> + return -ENOMEM;
> +
> + macsmc_hwmon_populate_configs((u32 *)channel_info->config,
> + hwmon->power.count,
> + (HWMON_P_INPUT | HWMON_P_LABEL));
> + hwmon->channel_infos[i++] = channel_info;
> + }
> +
> + if (hwmon->temp.count) {
> + channel_info = &hwmon->temp.channel_info;
> + channel_info->type = hwmon_temp;
> + channel_info->config = devm_kcalloc(hwmon->dev, hwmon->temp.count + 1,
> + sizeof(u32), GFP_KERNEL);
> + if (!channel_info->config)
> + return -ENOMEM;
> +
> + macsmc_hwmon_populate_configs((u32 *)channel_info->config,
> + hwmon->temp.count,
> + (HWMON_T_INPUT | HWMON_T_LABEL));
> + hwmon->channel_infos[i++] = channel_info;
> + }
> +
> + if (hwmon->volt.count) {
> + channel_info = &hwmon->volt.channel_info;
> + channel_info->type = hwmon_in;
> + channel_info->config = devm_kcalloc(hwmon->dev, hwmon->volt.count + 1,
> + sizeof(u32), GFP_KERNEL);
> + if (!channel_info->config)
> + return -ENOMEM;
> +
> + macsmc_hwmon_populate_configs((u32 *)channel_info->config,
> + hwmon->volt.count,
> + (HWMON_I_INPUT | HWMON_I_LABEL));
> + hwmon->channel_infos[i++] = channel_info;
> + }
> +
> + return 0;
> +}
> +
> +static int macsmc_hwmon_probe(struct platform_device *pdev)
> +{
> + struct apple_smc *smc = dev_get_drvdata(pdev->dev.parent);
> + struct macsmc_hwmon *hwmon;
> + int ret;
> +
> + /*
> + * The MFD driver will try to probe us unconditionally. Some devices
> + * with the SMC do not have hwmon capabilities. Only probe if we have
> + * a hwmon node.
> + */
> + if (!pdev->dev.of_node)
> + return -ENODEV;
> +
> + hwmon = devm_kzalloc(&pdev->dev, sizeof(*hwmon),
> + GFP_KERNEL);
> + if (!hwmon)
> + return -ENOMEM;
> +
> + hwmon->dev = &pdev->dev;
> + hwmon->smc = smc;
> +
> + ret = macsmc_hwmon_populate_sensors(hwmon, hwmon->dev->of_node);
> + if (ret) {
> + dev_err(hwmon->dev, "Could not populate keys!\n");
> + return ret;
> + }
> +
> + if (!hwmon->curr.count && !hwmon->fan.count &&
> + !hwmon->power.count && !hwmon->temp.count &&
> + !hwmon->volt.count) {
> + dev_err(hwmon->dev,
> + "No valid keys found of any supported type");
> + return -ENODEV;
> + }
> +
> + ret = macsmc_hwmon_create_infos(hwmon);
> + if (ret)
> + return ret;
> +
> + hwmon->chip_info.ops = &macsmc_hwmon_ops;
> + hwmon->chip_info.info =
> + (const struct hwmon_channel_info *const *)&hwmon->channel_infos;
> +
> + hwmon->hwmon_dev = devm_hwmon_device_register_with_info(&pdev->dev,
> + "macsmc_hwmon", hwmon,
> + &hwmon->chip_info, NULL);
> + if (IS_ERR(hwmon->hwmon_dev))
> + return dev_err_probe(hwmon->dev, PTR_ERR(hwmon->hwmon_dev),
> + "Probing SMC hwmon device failed\n");
> +
> + dev_info(hwmon->dev, "Registered SMC hwmon device. Sensors:");
> + dev_info(hwmon->dev,
> + "Current: %d, Fans: %d, Power: %d, Temperature: %d, Voltage: %d",
> + hwmon->curr.count, hwmon->fan.count,
> + hwmon->power.count, hwmon->temp.count,
> + hwmon->volt.count);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id macsmc_hwmon_of_table[] = {
> + { .compatible = "apple,smc-hwmon" },
> + {}
> +};
> +MODULE_DEVICE_TABLE(of, macsmc_hwmon_of_table);
> +
> +static struct platform_driver macsmc_hwmon_driver = {
> + .probe = macsmc_hwmon_probe,
> + .driver = {
> + .name = "macsmc_hwmon",
macsmc-hwmon
> + .of_match_table = macsmc_hwmon_of_table,
> + },
> +};
> +module_platform_driver(macsmc_hwmon_driver);
> +
> +MODULE_DESCRIPTION("Apple Silicon SMC hwmon driver");
> +MODULE_AUTHOR("James Calligeros <jcalligeros99@gmail.com>");
> +MODULE_LICENSE("Dual MIT/GPL");
> +MODULE_ALIAS("platform:macsmc_hwmon");
The module alias should be removed when using MFD_CELL_OF in macsmc.c
Janne
^ permalink raw reply
* Re: [PATCH v2 02/11] dt-bindings: hwmon: Add Apple System Management Controller hwmon schema
From: Janne Grunau @ 2025-09-25 20:49 UTC (permalink / raw)
To: Rob Herring
Cc: James Calligeros, Sven Peter, Alyssa Rosenzweig, Neal Gompa,
Lee Jones, Krzysztof Kozlowski, Conor Dooley, Alexandre Belloni,
Jean Delvare, Guenter Roeck, Dmitry Torokhov, asahi,
linux-arm-kernel, devicetree, linux-kernel, linux-rtc,
linux-hwmon, linux-input
In-Reply-To: <20250829164057.GA976361-robh@kernel.org>
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@gmail.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
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox