* Re: [PATCH 07/12] rtc: rzn1: fix alarm range check truncation on 32-bit systems
From: Lad, Prabhakar @ 2026-06-24 9:53 UTC (permalink / raw)
To: Wolfram Sang
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <ajr1wXCI2U23d1sY@shikoro>
Hi Wolfram,
On Tue, Jun 23, 2026 at 10:08 PM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
>
>
> > Can you please share the commands you tried, I'll try and replicate it
> > on my side.
>
> Sorry, can't give you the commands, just from my head: I tried to set an
> alarm more than a week in the future, and the alarm was set to the next
> day. But I was in a hurry, maybe I overlooked something, because that
> handling used to work in the past IIRC. I can return to this topic on
> Friday earliest, sadly. Maybe next week only...
>
I ran some tests for cases #1 and #2, and we see an out-of-range
error. By adding a 1-sec leeway when checking the ranges I don't get
the out-of-range error. Let me know what you think (I'll create a
seprate patch for it).
Case #1 reverting this patch:
root@rzn2h-evk:~# date -s "2026-06-24 10:34:00"; hwclock -w;
Wed Jun 24 10:34:00 UTC 2026
root@rzn2h-evk:~#
root@rzn2h-evk:~#
root@rzn2h-evk:~# rtcwake -m no -s 604800;cat /proc/driver/rtc
rtcwake: set rtc wake alarm failed: Numerical result out of range
rtc_time : 10:34:32
rtc_date : 2026-06-24
alrm_time : 10:34:33
alrm_date : 2026-07-01
alarm_IRQ : no
alrm_pending : no
update IRQ enabled : no
periodic IRQ enabled : no
periodic IRQ frequency : 1
max user IRQ frequency : 64
24hr : yes
root@rzn2h-evk:~#
Case #2 with this patch:
root@rzn2h-evk:~# date -s "2026-06-24 10:46:00"; hwclock -w;
Wed Jun 24 10:46:00 UTC 2026
root@rzn2h-evk:~# rtcwake -m no -s 604800;cat /proc/driver/rtc
rtcwake: set rtc wake alarm failed: Numerical result out of range
rtc_time : 10:46:30
rtc_date : 2026-06-24
alrm_time : 10:46:31
alrm_date : 2026-07-01
alarm_IRQ : no
alrm_pending : no
update IRQ enabled : no
periodic IRQ enabled : no
periodic IRQ frequency : 1
max user IRQ frequency : 64
24hr : yes
root@rzn2h-evk:~#
Case #3: Add 1-sec leeway:
root@rzn2h-evk:~# date -s "2026-06-24 10:48:00"; hwclock -w;
Wed Jun 24 10:48:00 UTC 2026
root@rzn2h-evk:~# rtcwake -m no -s 604800;cat /proc/driver/rtc
rtcwake: wakeup using /dev/rtc0 at Wed Jul 1 10:48:50 2026
rtc_time : 10:48:49
rtc_date : 2026-06-24
alrm_time : 10:48:50
alrm_date : 2026-07-01
alarm_IRQ : yes
alrm_pending : no
update IRQ enabled : no
periodic IRQ enabled : no
periodic IRQ frequency : 1
max user IRQ frequency : 64
24hr : yes
root@rzn2h-evk:~#
Changes for case #3:
diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
index 173526d50d41..8fdb5114a6d8 100644
--- a/drivers/rtc/rtc-rzn1.c
+++ b/drivers/rtc/rtc-rzn1.c
@@ -279,7 +279,9 @@ static int rzn1_rtc_set_alarm(struct device *dev,
struct rtc_wkalrm *alrm)
/* We cannot set alarms more than one week ahead */
farest = rtc_tm_to_time64(&tm_now) + rtc->rtcdev->alarm_offset_max;
alarm = rtc_tm_to_time64(tm);
- if (alarm > farest)
+
+ /* Add a 1-second leeway for processing delay */
+ if (alarm > (farest + 1))
return -ERANGE;
/* Convert alarm day into week day */
Cheers,
Prabhakar
^ permalink raw reply related
* [PATCH] rtc: amlogic-a4: clear unsupported update interrupt feature
From: Xianwei Zhao via B4 Relay @ 2026-06-24 7:24 UTC (permalink / raw)
To: Yiting Deng, Alexandre Belloni
Cc: linux-amlogic, linux-rtc, linux-kernel, Xianwei Zhao
From: Xianwei Zhao <xianwei.zhao@amlogic.com>
The Amlogic A4 RTC does not support update interrupt. Clear
RTC_FEATURE_UPDATE_INTERRUPT before registering the RTC device to
prevent userspace from enabling an unsupported RTC UIE function.
Signed-off-by: Xianwei Zhao <xianwei.zhao@amlogic.com>
---
Clear RTC_FEATURE_UPDATE_INTERRUPT before registering the RTC device.
---
drivers/rtc/rtc-amlogic-a4.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/rtc/rtc-amlogic-a4.c b/drivers/rtc/rtc-amlogic-a4.c
index 50938c35af36..116cf095a9e9 100644
--- a/drivers/rtc/rtc-amlogic-a4.c
+++ b/drivers/rtc/rtc-amlogic-a4.c
@@ -379,6 +379,7 @@ static int aml_rtc_probe(struct platform_device *pdev)
rtc->rtc_dev->ops = &aml_rtc_ops;
rtc->rtc_dev->range_min = 0;
rtc->rtc_dev->range_max = U32_MAX;
+ clear_bit(RTC_FEATURE_UPDATE_INTERRUPT, rtc->rtc_dev->features);
return devm_rtc_register_device(rtc->rtc_dev);
}
---
base-commit: 851d961ff248218f681c53cf0f7f08cf8201a117
change-id: 20260624-rtc-feature-03ce3f3843a9
Best regards,
--
Xianwei Zhao <xianwei.zhao@amlogic.com>
^ permalink raw reply related
* [PATCH] spi: dt-bindings: microchip,pic32mzda-sqi: Convert to DT schema
From: Udaya Kiran Challa @ 2026-06-24 6:13 UTC (permalink / raw)
To: tsbogend, robh, krzk+dt, conor+dt
Cc: skhan, me, linux-rtc, devicetree, linux-kernel,
Udaya Kiran Challa
Convert Microchip PIC32 Quad SPI controller devicetree binding
from legacy text format to DT schema.
Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
---
.../bindings/spi/microchip,pic32mzda-sqi.yaml | 53 +++++++++++++++++++
.../devicetree/bindings/spi/sqi-pic32.txt | 18 -------
2 files changed, 53 insertions(+), 18 deletions(-)
create mode 100644 Documentation/devicetree/bindings/spi/microchip,pic32mzda-sqi.yaml
delete mode 100644 Documentation/devicetree/bindings/spi/sqi-pic32.txt
diff --git a/Documentation/devicetree/bindings/spi/microchip,pic32mzda-sqi.yaml b/Documentation/devicetree/bindings/spi/microchip,pic32mzda-sqi.yaml
new file mode 100644
index 000000000000..39f06b61e894
--- /dev/null
+++ b/Documentation/devicetree/bindings/spi/microchip,pic32mzda-sqi.yaml
@@ -0,0 +1,53 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/spi/microchip,pic32mzda-sqi.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC32MZDA Quad SPI controller
+
+maintainers:
+ - Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+
+allOf:
+ - $ref: spi-controller.yaml#
+
+properties:
+ compatible:
+ const: microchip,pic32mzda-sqi
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 2
+
+ clock-names:
+ items:
+ - const: spi_ck
+ - const: reg_ck
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+ - clock-names
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/microchip,pic32-clock.h>
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ sqi1: spi@1f8e2000 {
+ compatible = "microchip,pic32mzda-sqi";
+ reg = <0x1f8e2000 0x200>;
+ interrupts = <169 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&rootclk REF2CLK>, <&rootclk PB5CLK>;
+ clock-names = "spi_ck", "reg_ck";
+ };
diff --git a/Documentation/devicetree/bindings/spi/sqi-pic32.txt b/Documentation/devicetree/bindings/spi/sqi-pic32.txt
deleted file mode 100644
index c82d021bce50..000000000000
--- a/Documentation/devicetree/bindings/spi/sqi-pic32.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-Microchip PIC32 Quad SPI controller
------------------------------------
-Required properties:
-- compatible: Should be "microchip,pic32mzda-sqi".
-- reg: Address and length of SQI controller register space.
-- interrupts: Should contain SQI interrupt.
-- clocks: Should contain phandle of two clocks in sequence, one that drives
- clock on SPI bus and other that drives SQI controller.
-- clock-names: Should be "spi_ck" and "reg_ck" in order.
-
-Example:
- sqi1: spi@1f8e2000 {
- compatible = "microchip,pic32mzda-sqi";
- reg = <0x1f8e2000 0x200>;
- clocks = <&rootclk REF2CLK>, <&rootclk PB5CLK>;
- clock-names = "spi_ck", "reg_ck";
- interrupts = <169 IRQ_TYPE_LEVEL_HIGH>;
- };
--
2.34.1
^ permalink raw reply related
* [PATCH v2] dt-bindings: watchdog: microchip,pic32mzda-wdt: Convert to DT schema
From: Udaya Kiran Challa @ 2026-06-24 5:56 UTC (permalink / raw)
To: tsbogend, robh, krzk+dt, conor+dt
Cc: skhan, me, linux-rtc, devicetree, linux-kernel,
Udaya Kiran Challa, Krzysztof Kozlowski
Convert Microchip PIC32 Watchdog Timer devicetree binding
from legacy text format to DT schema.
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
---
Changelog:
Changes since v1:
- Fix example indentation
- Correct example clock specifier from REF2CLK to LPRCCLK
Link to v1:https://lore.kernel.org/all/20260620172354.155565-1-challauday369@gmail.com/
---
.../bindings/watchdog/microchip,pic32-wdt.txt | 18 --------
.../watchdog/microchip,pic32mzda-wdt.yaml | 44 +++++++++++++++++++
2 files changed, 44 insertions(+), 18 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/watchdog/microchip,pic32-wdt.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/microchip,pic32mzda-wdt.yaml
diff --git a/Documentation/devicetree/bindings/watchdog/microchip,pic32-wdt.txt b/Documentation/devicetree/bindings/watchdog/microchip,pic32-wdt.txt
deleted file mode 100644
index f03a29a1b323..000000000000
--- a/Documentation/devicetree/bindings/watchdog/microchip,pic32-wdt.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-* Microchip PIC32 Watchdog Timer
-
-When enabled, the watchdog peripheral can be used to reset the device if the
-WDT is not cleared periodically in software.
-
-Required properties:
-- compatible: must be "microchip,pic32mzda-wdt".
-- reg: physical base address of the controller and length of memory mapped
- region.
-- clocks: phandle of source clk. Should be <&rootclk LPRCCLK>.
-
-Example:
-
- watchdog@1f800800 {
- compatible = "microchip,pic32mzda-wdt";
- reg = <0x1f800800 0x200>;
- clocks = <&rootclk LPRCCLK>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/microchip,pic32mzda-wdt.yaml b/Documentation/devicetree/bindings/watchdog/microchip,pic32mzda-wdt.yaml
new file mode 100644
index 000000000000..a5dd633c3e78
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/microchip,pic32mzda-wdt.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/microchip,pic32mzda-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC32MZDA Watchdog Timer
+
+maintainers:
+ - Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+
+description:
+ The PIC32 watchdog timer can be used to reset the device if software fails
+ to periodically service the watchdog.
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ const: microchip,pic32mzda-wdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/microchip,pic32-clock.h>
+
+ watchdog@1f800800 {
+ compatible = "microchip,pic32mzda-wdt";
+ reg = <0x1f800800 0x200>;
+ clocks = <&rootclk LPRCCLK>;
+ };
--
2.34.1
^ permalink raw reply related
* [PATCH] rtc: zynqmp: Return optional clock lookup errors
From: Pengpeng Hou @ 2026-06-24 5:55 UTC (permalink / raw)
To: Alexandre Belloni, Michal Simek
Cc: linux-rtc, linux-arm-kernel, linux-kernel, Pengpeng Hou
devm_clk_get_optional() returns NULL when the optional clock is absent,
but returns an ERR_PTR when the clock provider lookup fails. Probe
currently keeps the ERR_PTR and then passes it to clk_get_rate().
Return the lookup error instead. A truly absent optional clock still
reaches the existing calibration fallback through clk_get_rate(NULL).
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/rtc/rtc-zynqmp.c | 7 +++----
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c
index 2ae54804b87a..5bcb7536e973 100644
--- a/drivers/rtc/rtc-zynqmp.c
+++ b/drivers/rtc/rtc-zynqmp.c
@@ -334,10 +334,9 @@ static int xlnx_rtc_probe(struct platform_device *pdev)
/* Getting the rtc info */
xrtcdev->rtc_clk = devm_clk_get_optional(&pdev->dev, "rtc");
- if (IS_ERR(xrtcdev->rtc_clk)) {
- if (PTR_ERR(xrtcdev->rtc_clk) != -EPROBE_DEFER)
- dev_warn(&pdev->dev, "Device clock not found.\n");
- }
+ if (IS_ERR(xrtcdev->rtc_clk))
+ return dev_err_probe(&pdev->dev, PTR_ERR(xrtcdev->rtc_clk),
+ "Failed to get rtc clock\n");
xrtcdev->freq = clk_get_rate(xrtcdev->rtc_clk);
if (!xrtcdev->freq) {
ret = of_property_read_u32(pdev->dev.of_node, "calibration",
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH 07/12] rtc: rzn1: fix alarm range check truncation on 32-bit systems
From: Wolfram Sang @ 2026-06-23 21:08 UTC (permalink / raw)
To: Lad, Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <CA+V-a8u2wt6623mYjhipOvJPo4va+bXs3qirQewocFr2QmUFhA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 423 bytes --]
> Can you please share the commands you tried, I'll try and replicate it
> on my side.
Sorry, can't give you the commands, just from my head: I tried to set an
alarm more than a week in the future, and the alarm was set to the next
day. But I was in a hurry, maybe I overlooked something, because that
handling used to work in the past IIRC. I can return to this topic on
Friday earliest, sadly. Maybe next week only...
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: rtc: sun6i: Add Allwinner A733 support
From: Chen-Yu Tsai @ 2026-06-23 15:42 UTC (permalink / raw)
To: Jerome Brunet, Junhui Liu
Cc: Michael Turquette, Stephen Boyd, Jernej Skrabec, Samuel Holland,
Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard, linux-clk, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-rtc, devicetree
In-Reply-To: <1j1pe7elxm.fsf@starbuckisacylon.baylibre.com>
On Tue, Jun 16, 2026 at 1:46 AM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> On sam. 28 mars 2026 at 20:37, Chen-Yu Tsai <wens@kernel.org> wrote:
>
> > On Wed, Jan 21, 2026 at 7:03 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
> >>
> >> The RTC module in the Allwinner A733 SoC is functionally compatible with
> >> the sun6i RTC, but its internal Clock Control Unit (CCU) has significant
> >> changes.
> >>
> >> The A733 supports selecting the oscillator between three frequencies:
> >> 19.2MHz, 24MHz, and 26MHz. The RTC CCU relies on hardware to detect
> >> which frequency is actually used on the board. By defining all three
> >> frequencies as fixed-clocks in the device tree, the driver can identify
> >> the hardware-detected frequency and expose it to the rest of the system.
> >
> > No. The board device tree shall have the exact and correct frequency
> > defined in the external crystal device node. The operating system can
> > use the hardware-detected frequency to "fix" the in-system representation
> > if it is off.
> >
> >> Additionally, the A733 RTC CCU provides several new DCXO gate clocks for
> >> specific modules, including SerDes, HDMI, and UFS.
> >>
> >> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
> >> ---
> >> .../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 38 ++++++++++++++++++++--
> >> include/dt-bindings/clock/sun60i-a733-rtc.h | 16 +++++++++
> >> 2 files changed, 52 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >> index 9df5cdb6f63f..b18431955783 100644
> >> --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >> +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
> >> @@ -26,6 +26,7 @@ properties:
> >> - allwinner,sun50i-h6-rtc
> >> - allwinner,sun50i-h616-rtc
> >> - allwinner,sun50i-r329-rtc
> >> + - allwinner,sun60i-a733-rtc
> >> - items:
> >> - const: allwinner,sun50i-a64-rtc
> >> - const: allwinner,sun8i-h3-rtc
> >> @@ -46,11 +47,11 @@ properties:
> >>
> >> clocks:
> >> minItems: 1
> >> - maxItems: 4
> >> + maxItems: 6
> >>
> >> clock-names:
> >> minItems: 1
> >> - maxItems: 4
> >> + maxItems: 6
> >>
> >> clock-output-names:
> >> minItems: 1
> >> @@ -156,6 +157,38 @@ allOf:
> >> - clocks
> >> - clock-names
> >>
> >> + - if:
> >> + properties:
> >> + compatible:
> >> + contains:
> >> + const: allwinner,sun60i-a733-rtc
> >> +
> >> + then:
> >> + properties:
> >> + clocks:
> >> + minItems: 5
> >> + items:
> >> + - description: Bus clock for register access
> >
> >> + - description: 19.2 MHz oscillator
> >> + - description: 24 MHz oscillator
> >> + - description: 26 MHz oscillator
> >
> > No. There is only one input. As in there is only one set of pins for the
> > DCXO. The inputs are the same as on R329 / A523. Just use that list.
> >
> >> + - description: AHB parent for internal SPI clock
> >> + - description: External 32768 Hz oscillator
> >> +
> >> + clock-names:
> >> + minItems: 5
> >> + items:
> >> + - const: bus
> >> + - const: osc19M
> >> + - const: osc24M
> >> + - const: osc26M
> >> + - const: ahb
> >> + - const: ext-osc32k
> >> +
> >> + required:
> >> + - clocks
> >> + - clock-names
> >> +
> >> - if:
> >> properties:
> >> compatible:
> >> @@ -164,6 +197,7 @@ allOf:
> >> - allwinner,sun8i-r40-rtc
> >> - allwinner,sun50i-h616-rtc
> >> - allwinner,sun50i-r329-rtc
> >> + - allwinner,sun60i-a733-rtc
> >>
> >> then:
> >> properties:
> >> diff --git a/include/dt-bindings/clock/sun60i-a733-rtc.h b/include/dt-bindings/clock/sun60i-a733-rtc.h
> >> new file mode 100644
> >> index 000000000000..8a2b5facad73
> >> --- /dev/null
> >> +++ b/include/dt-bindings/clock/sun60i-a733-rtc.h
> >> @@ -0,0 +1,16 @@
> >> +/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
> >> +
> >> +#ifndef _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_
> >> +#define _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_
> >> +
> >> +#define CLK_IOSC 0
> >> +#define CLK_OSC32K 1
> >> +#define CLK_HOSC 2
> >
> > The DCXO enable control has been present since at least the H6. We just
> > never added it, as we would never disable it anyway.
> >
> > If you compare the RTC clock trees of the A733 and A523, the only addition
> > besides the new gates seems to be the LOSC auto selection. But even that
> > is just an illusion, as the A523 has the same registers for that.
> >
> > One could say the A733 RTC is almost backward compatible to the A523, if
> > not for the two fastboot registers the A523 has at 0x120 and 0x124.
> >
> > So I ask that you try to integrate the differences into the existing
> > driver and bindings. You can tweak and export internal clks if you
> > need.
>
> I'd like to help with that. I think it is doable but I have a question
> regarding the binding of the existing driver, more precisely their usage
> here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c?h=v7.1#n370
>
> Clock indexes are supposed to be stable in DT (AFAIK) but with the code
> linked the external 32k is at:
>
> * "ext-32k" - so index 3 - if "clock-names" is present
> * index 0 if clock names is not present
>
> ... but index 0 is supposed to be the bus clock according the binding
> doc, whether "clock-names" is there or not :/
>
> So what are those old r329 bindings ? is there a documentation defining
> them somewhere ?
You can look at
8487614a8a8a dt-bindings: rtc: sun6i: Add H616, R329, and D1 support
In hindsight maybe the two bindings should be separate. The old SoCs
did not have all these clock inputs from the main clock controller.
The only input it could possibly take was the external 32k crystal.
> Cleaning that part would help with A733 addition in the existing driver
> I think
Yeah. Also, we can treat the bindings and drivers separately. We could
have two bindings but one common driver, or vice versa. As you pointed
out, the bindings are a bit messed up, so we could consider separating
them.
If we end up with separate binding header files, maybe we could use
a different prefix for the new ones so they don't collide? That way
the driver could maybe still be shared?
As for whether to share the headers, I think they should be treated
as part of the binding, so if the bindings are shared, then they can
be shared as well; if the bindings are separate, then they should be
completely separate files as well.
And sorry for the late reply.
Thanks
ChenYu
> >
> >> +#define CLK_RTC_32K 3
> >
> > AFAICT besides being an internal clock, this is also fed to GPIO for
> > debounce? We probably need to expose this on the A523 as well.
> >
> >
> > Thanks
> > ChenYu
> >
> >
> >> +#define CLK_OSC32K_FANOUT 4
> >> +#define CLK_HOSC_SERDES1 5
> >> +#define CLK_HOSC_SERDES0 6
> >> +#define CLK_HOSC_HDMI 7
> >> +#define CLK_HOSC_UFS 8
> >> +
> >> +#endif /* _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_ */
> >>
> >> --
> >> 2.52.0
> >>
> >>
>
> --
> Jerome
>
^ permalink raw reply
* Re: [PATCH 7/7] clk: sunxi-ng: Add Allwinner A733 RTC CCU support
From: Chen-Yu Tsai @ 2026-06-23 15:23 UTC (permalink / raw)
To: Jerome Brunet
Cc: Junhui Liu, Michael Turquette, Stephen Boyd, Jernej Skrabec,
Samuel Holland, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Ripard, linux-clk,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-rtc,
devicetree, André Przywara
In-Reply-To: <1jv7bjd6wi.fsf@starbuckisacylon.baylibre.com>
On Tue, Jun 16, 2026 at 1:56 AM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> On sam. 28 mars 2026 at 22:41, Chen-Yu Tsai <wens@kernel.org> wrote:
>
> > On Wed, Jan 21, 2026 at 7:04 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
> >>
> >> Add support for the internal CCU found in the RTC module of the Allwinner
> >> A733 SoC. While the basic 16MHz (IOSC) and 32kHz logic remains compatible
> >> with older SoCs like the sun6i, the A733 introduces several new features.
> >>
> >> The A733 RTC CCU supports choosing one of three external crystal
> >> frequencies: 19.2MHz, 24MHz, and 26MHz. It features hardware detection
> >> logic to automatically identify the frequency used on the board and
> >> exports this DCXO signal as the "hosc" clock.
> >>
> >> Furthermore, the driver implements logic to derive a 32kHz reference
> >> from the HOSC. This is achieved through a muxed clock path using fixed
> >> pre-dividers to normalize the different crystal frequencies to ~32kHz.
> >
> > Have you tested whether the actually normalizes the frequency, i.e.
> > selects a different divider based on the DCXO frequency? Otherwise
> > we're just lying about the frequency.
> >
> >> This path reuses the same hardware mux registers as the HOSC clock.
> >>
> >> Additionally, this CCU provides several gate clocks for specific
> >> peripherals, including SerDes, HDMI, and UFS. The driver is implemented
> >> as an auxiliary driver to be bound to the sun6i-rtc driver.
> >>
> >> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
> >> ---
>
> [...]
>
> >> +};
> >> +
> >> +static const struct clk_parent_data hosc_parents[] = {
> >> + { .fw_name = "osc24M" },
> >> + { .fw_name = "osc19M" },
> >> + { .fw_name = "osc26M" },
> >> + { .fw_name = "osc24M" },
> >> +};
> >
> > As mentioned in my reply to the binding, this is wrong. There is only
> > one input.
> >
> > The most you can do is check the rate of the parent clock against the
> > detected one, and _scream_ that the DT is wrong. And maybe override
> > the reported frequency.
> >
> > If you want to do the latter, you could add a new fixed rate gated
> > clock type to our library. You would fill in the rate before the
> > clocks get registered. I probably wouldn't go that far. We want people
> > to have correct hardware descriptions.
> >
> > Funnily enough Allwinner's BSP actually implements a fixed rate gate
> > for the next 24M-to-32k divider clock.
>
> What about implementing the register bellow as a read-only (and
> non-cached) divider using the factors provided by Junhui ? That would be
> an accurate description of the HW I think.
>
> The oscillator gets set in DT and if the output reported past the
> divider is not 32728Hz, you know you've got a problem (bad DT or HW gone
> bad)
>
> With a fixed-rate gate, you may actually end up lying about what
> actually happen, if the HW does not behave as expected.
>
> Do you prefer a fixed-rate gate still or should I try the RO divider
> approach ?
I think either one would work. The RO divider is probably more accurate.
Sorry for the late reply.
ChenYu
^ permalink raw reply
* [PATCH] rtc: cmos: unregister HPET IRQ handler on probe failure
From: Haoxiang Li @ 2026-06-23 10:08 UTC (permalink / raw)
To: alexandre.belloni, bwalle, akpm; +Cc: linux-rtc, linux-kernel, Haoxiang Li
cmos_do_probe() registers cmos_interrupt() as the HPET RTC IRQ
handler before requesting the RTC IRQ and registering the RTC
device. If either request_irq() or devm_rtc_register_device()
fails afterwards, the error path leaves the HPET RTC IRQ handler
installed. This leaves a stale handler behind and make a later
hpet_register_irq_handler() fail with -EBUSY.
Track whether the HPET handler was registered successfully and
undo the registration on the probe error path. Also mask the HPET
RTC IRQ bits to match the normal shutdown cleanup.
Fixes: 9d8af78b0797 ("rtc: add HPET RTC emulation to RTC_DRV_CMOS")
Signed-off-by: Haoxiang Li <haoxiang_li2024@163.com>
---
drivers/rtc/rtc-cmos.c | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index f89ab58f5048..fa04ece151b8 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -934,6 +934,7 @@ cmos_do_probe(struct device *dev, struct resource *ports, int rtc_irq)
unsigned char rtc_control;
unsigned address_space;
u32 flags = 0;
+ bool hpet_registered = false;
struct nvmem_config nvmem_cfg = {
.name = "cmos_nvram",
.word_size = 1,
@@ -1091,6 +1092,7 @@ cmos_do_probe(struct device *dev, struct resource *ports, int rtc_irq)
" failed in rtc_init().");
goto cleanup1;
}
+ hpet_registered = true;
} else
rtc_cmos_int_handler = cmos_interrupt;
@@ -1140,6 +1142,10 @@ cmos_do_probe(struct device *dev, struct resource *ports, int rtc_irq)
if (is_valid_irq(rtc_irq))
free_irq(rtc_irq, cmos_rtc.rtc);
cleanup1:
+ if (hpet_registered) {
+ hpet_mask_rtc_irq_bit(RTC_IRQMASK);
+ hpet_unregister_irq_handler(cmos_interrupt);
+ }
cmos_rtc.dev = NULL;
cleanup0:
if (RTC_IOMAPPED)
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] dt-bindings: watchdog: microchip,pic32mzda-wdt: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-06-23 8:51 UTC (permalink / raw)
To: Udaya Kiran Challa
Cc: tsbogend, robh, krzk+dt, conor+dt, skhan, me, linux-rtc,
devicetree, linux-kernel
In-Reply-To: <20260620172354.155565-1-challauday369@gmail.com>
On Sat, Jun 20, 2026 at 10:53:54PM +0530, Udaya Kiran Challa wrote:
> + watchdog@1f800800 {
> + compatible = "microchip,pic32mzda-wdt";
> + reg = <0x1f800800 0x200>;
> + clocks = <&rootclk REF2CLK>;
> + };
Indentaion needs fixing.
With that:
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3] spi: dt-bindings: microchip,pic32mzda-spi: Convert to DT schema
From: Krzysztof Kozlowski @ 2026-06-22 9:22 UTC (permalink / raw)
To: Udaya Kiran Challa
Cc: tsbogend, robh, krzk+dt, conor+dt, skhan, me, linux-rtc,
devicetree, linux-kernel
In-Reply-To: <20260617101009.148851-1-challauday369@gmail.com>
On Wed, Jun 17, 2026 at 03:40:09PM +0530, Udaya Kiran Challa wrote:
> Convert Microchip PIC32 SPI controller devicetree binding
> from legacy text format to DT schema.
>
> Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
> ---
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] dt-bindings: watchdog: microchip,pic32mzda-wdt: Convert to DT schema
From: Udaya Kiran Challa @ 2026-06-20 17:23 UTC (permalink / raw)
To: tsbogend, robh, krzk+dt, conor+dt
Cc: skhan, me, linux-rtc, devicetree, linux-kernel,
Udaya Kiran Challa
Convert Microchip PIC32 Watchdog Timer devicetree binding
from legacy text format to DT schema.
Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
---
.../bindings/watchdog/microchip,pic32-wdt.txt | 18 --------
.../watchdog/microchip,pic32mzda-wdt.yaml | 44 +++++++++++++++++++
2 files changed, 44 insertions(+), 18 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/watchdog/microchip,pic32-wdt.txt
create mode 100644 Documentation/devicetree/bindings/watchdog/microchip,pic32mzda-wdt.yaml
diff --git a/Documentation/devicetree/bindings/watchdog/microchip,pic32-wdt.txt b/Documentation/devicetree/bindings/watchdog/microchip,pic32-wdt.txt
deleted file mode 100644
index f03a29a1b323..000000000000
--- a/Documentation/devicetree/bindings/watchdog/microchip,pic32-wdt.txt
+++ /dev/null
@@ -1,18 +0,0 @@
-* Microchip PIC32 Watchdog Timer
-
-When enabled, the watchdog peripheral can be used to reset the device if the
-WDT is not cleared periodically in software.
-
-Required properties:
-- compatible: must be "microchip,pic32mzda-wdt".
-- reg: physical base address of the controller and length of memory mapped
- region.
-- clocks: phandle of source clk. Should be <&rootclk LPRCCLK>.
-
-Example:
-
- watchdog@1f800800 {
- compatible = "microchip,pic32mzda-wdt";
- reg = <0x1f800800 0x200>;
- clocks = <&rootclk LPRCCLK>;
- };
diff --git a/Documentation/devicetree/bindings/watchdog/microchip,pic32mzda-wdt.yaml b/Documentation/devicetree/bindings/watchdog/microchip,pic32mzda-wdt.yaml
new file mode 100644
index 000000000000..5d91a7e22f17
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/microchip,pic32mzda-wdt.yaml
@@ -0,0 +1,44 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/microchip,pic32mzda-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC32MZDA Watchdog Timer
+
+maintainers:
+ - Thomas Bogendoerfer <tsbogend@alpha.franken.de>
+
+description:
+ The PIC32 watchdog timer can be used to reset the device if software fails
+ to periodically service the watchdog.
+
+allOf:
+ - $ref: watchdog.yaml#
+
+properties:
+ compatible:
+ const: microchip,pic32mzda-wdt
+
+ reg:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - clocks
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/clock/microchip,pic32-clock.h>
+
+ watchdog@1f800800 {
+ compatible = "microchip,pic32mzda-wdt";
+ reg = <0x1f800800 0x200>;
+ clocks = <&rootclk REF2CLK>;
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 09/12] rtc: rzn1: Use temporary variable for struct device
From: Wolfram Sang @ 2026-06-19 20:48 UTC (permalink / raw)
To: Lad, Prabhakar
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <CA+V-a8t-phAuaH5g_3Nt=2d=KPw2QqA6r1dqOZv9k-Xhp5q2Zw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1657 bytes --]
Hi Prabhakar,
> > > Could userspace still interact with the RTC during this window via ioctls
> > > or sysfs, potentially causing synchronous bus faults since the hardware is
> > > already suspended? Should teardown be bound using
> > > devm_add_action_or_reset() to guarantee correct reverse execution order?
> >
> > [wsa] Or maybe not use devm then?
> >
> Maybe just add two `devm_add_action_or_reset()` calls: one to clear
> interrupts and another to call pm_runtime_put()?
Why two? I wouldn't think it matters much if the two are separated. Main
problem seems to me the disabled clocks because of pm_runtime_put()? But
maybe I am overlooking sth?
> > > [Severity: High]
> > > This is a pre-existing issue, but does using pm_runtime_put() here (and in
> > > rzn1_rtc_remove) leave the device powered on indefinitely?
> > >
> > > Since devm_pm_runtime_enable(dev) schedules pm_runtime_disable() to
> > > execute during devres cleanup, calling pm_runtime_put() only queues an
> > > asynchronous idle check. The immediate return triggers devres cleanup,
> > > which executes a barrier that explicitly cancels pending async operations.
> > >
> > > Should this use pm_runtime_put_sync() instead to ensure the device is
> > > synchronously suspended before teardown?
> > >
> Although there were some patches accepted for similar kind of issue
> reported by Sashiko, do you think I should switch to
> pm_runtime_put_sync() (Ive not seen any issues)
I am not a PM expert, so I can't guide you. The report from Sashiko
sounds reasonable to me. But you'd have to look up the code path to
verify the reasoning. Or ask an PM expert.
Happy hacking,
Wolfram
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v1] rtc: m41t80: clean up watchdog on probe failure
From: 최유호 @ 2026-06-19 18:39 UTC (permalink / raw)
To: Alexandre Belloni; +Cc: linux-rtc, linux-kernel
In-Reply-To: <20260601194615.1979101-1-dbgh9129@gmail.com>
Hi,
Just a gentle ping on this patch.
I would appreciate any feedback when you have a chance to review this.
Thanks
On Mon, 1 Jun 2026 at 15:46, Yuho Choi <dbgh9129@gmail.com> wrote:
>
> m41t80_probe() registers the watchdog misc device and reboot notifier
> before registering the RTC device. If RTC device registration fails,
> probe returns without calling m41t80_remove(), leaving the watchdog misc
> device and reboot notifier registered.
>
> Both watchdog paths use the global save_client pointer, which can
> outlive the failed probe and point at driver state that has been
> released by devres.
>
> Unregister the watchdog misc device and reboot notifier before returning
> from the RTC registration failure path.
>
> Fixes: 10d0c768cc6d ("rtc: m41t80: fix race conditions")
> Signed-off-by: Yuho Choi <dbgh9129@gmail.com>
> ---
> drivers/rtc/rtc-m41t80.c | 10 +++++++++-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/rtc/rtc-m41t80.c b/drivers/rtc/rtc-m41t80.c
> index b26afef37d9c..f4a30320c6ed 100644
> --- a/drivers/rtc/rtc-m41t80.c
> +++ b/drivers/rtc/rtc-m41t80.c
> @@ -1009,9 +1009,17 @@ static int m41t80_probe(struct i2c_client *client)
>
> rc = devm_rtc_register_device(m41t80_data->rtc);
> if (rc)
> - return rc;
> + goto err_wdt;
>
> return 0;
> +err_wdt:
> +#ifdef CONFIG_RTC_DRV_M41T80_WDT
> + if (m41t80_data->features & M41T80_FEATURE_HT) {
> + misc_deregister(&wdt_dev);
> + unregister_reboot_notifier(&wdt_notifier);
> + }
> +#endif
> + return rc;
> }
>
> static void m41t80_remove(struct i2c_client *client)
> --
> 2.43.0
>
^ permalink raw reply
* Re: [PATCH v2 0/2] firmware: arm_scmi: Ensure automatic module loading
From: Hans de Goede @ 2026-06-18 20:31 UTC (permalink / raw)
To: Bjorn Andersson, Sudeep Holla, Cristian Marussi,
Nathan Chancellor, Nicolas Schier, Michael Turquette
Cc: arm-scmi, linux-arm-kernel, linux-kernel, linux-kbuild,
Stephen Boyd, Brian Masney, Rafael J. Wysocki, Viresh Kumar,
Frank Li, Sascha Hauer, Pengutronix Kernel Team, Fabio Estevam,
Guenter Roeck, Jyoti Bhayana, Jonathan Cameron, David Lechner,
Nuno Sá, Andy Shevchenko, Dmitry Torokhov, Ulf Hansson,
Liam Girdwood, Mark Brown, Philipp Zabel, Alexandre Belloni,
linux-clk, linux-pm, imx, linux-hwmon, linux-iio, linux-input,
linux-rtc
In-Reply-To: <20260618-scmi-modalias-v2-0-8c7547c1be21@oss.qualcomm.com>
Hi,
On 18-Jun-26 17:56, Bjorn Andersson wrote:
> SCMI drivers such as the Arm SCMI CPUfreq driver are allowed to built as
> modules, but they are then not automatically loaded. Rework the SCMI
> device table alias support to make modpost consume the information from
> MODULE_DEVICE_TABLE(scmi, ...) and allow drivers to be loaded based on
> this information, if known. Also add a protocol-based alias to also
> trigger driver loading when only the SCMI protocol id is known.
>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
So I just gave this a test spin and unfortunately it does not work.
The problem with Fedora's kernel-config / setup is that the
request_module() from patch 2/2 runs from the initramfs, but
the scmi_cpufreq module is only available in the rootfs.
It does work if I explictly add the scmi_cpufreq module to
the initramfs, then it does get autoloaded.
We really need some place to put a uevent sysfs attr which then
gets replayed when udev is restarted from the rootfs and then
re-reads all the uevent files as part of its coldplug
enumeration.
I wonder if it is ok for a single uevent file to have
multiple MODALIAS= lines in there.
Regards,
Hans
> ---
> Changes in v2:
> - Use request_module_nowait()
> - Drop #include <linux/mod_devicetable.h> from scmi_protocol.h
> - Link to v1: https://patch.msgid.link/20260616-scmi-modalias-v1-0-662b8dd52ab2@oss.qualcomm.com
>
> To: Sudeep Holla <sudeep.holla@kernel.org>
> To: Cristian Marussi <cristian.marussi@arm.com>
> To: Michael Turquette <mturquette@baylibre.com>
> To: Nicolas Schier <nsc@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: Brian Masney <bmasney@redhat.com>
> Cc: "Rafael J. Wysocki" <rafael@kernel.org>
> Cc: Viresh Kumar <viresh.kumar@linaro.org>
> Cc: Frank Li <Frank.Li@nxp.com>
> Cc: Sascha Hauer <s.hauer@pengutronix.de>
> Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
> Cc: Fabio Estevam <festevam@gmail.com>
> Cc: Guenter Roeck <linux@roeck-us.net>
> Cc: Jyoti Bhayana <jbhayana@google.com>
> Cc: Jonathan Cameron <jic23@kernel.org>
> Cc: David Lechner <dlechner@baylibre.com>
> Cc: Nuno Sá <nuno.sa@analog.com>
> Cc: Andy Shevchenko <andy@kernel.org>
> Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
> Cc: Ulf Hansson <ulfh@kernel.org>
> Cc: Liam Girdwood <lgirdwood@gmail.com>
> Cc: Mark Brown <broonie@kernel.org>
> Cc: Philipp Zabel <p.zabel@pengutronix.de>
> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Cc: Nathan Chancellor <nathan@kernel.org>
> Cc: arm-scmi@vger.kernel.org
> Cc: linux-arm-kernel@lists.infradead.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Cc: linux-pm@vger.kernel.org
> Cc: imx@lists.linux.dev
> Cc: linux-hwmon@vger.kernel.org
> Cc: linux-iio@vger.kernel.org
> Cc: linux-input@vger.kernel.org
> Cc: linux-rtc@vger.kernel.org
> Cc: linux-kbuild@vger.kernel.org
>
> ---
> Bjorn Andersson (2):
> module: add SCMI device table alias support
> firmware: arm_scmi: request modules for discovered protocols
>
> drivers/clk/clk-scmi.c | 1 +
> drivers/cpufreq/scmi-cpufreq.c | 1 +
> drivers/firmware/arm_scmi/bus.c | 20 ++++++++++----------
> drivers/firmware/arm_scmi/driver.c | 3 +++
> drivers/firmware/arm_scmi/scmi_power_control.c | 1 +
> drivers/firmware/imx/sm-cpu.c | 1 +
> drivers/firmware/imx/sm-lmm.c | 1 +
> drivers/firmware/imx/sm-misc.c | 1 +
> drivers/hwmon/scmi-hwmon.c | 1 +
> drivers/iio/common/scmi_sensors/scmi_iio.c | 1 +
> drivers/input/keyboard/imx-sm-bbm-key.c | 1 +
> drivers/pmdomain/arm/scmi_perf_domain.c | 1 +
> drivers/pmdomain/arm/scmi_pm_domain.c | 1 +
> drivers/powercap/arm_scmi_powercap.c | 1 +
> drivers/regulator/scmi-regulator.c | 1 +
> drivers/reset/reset-scmi.c | 1 +
> drivers/rtc/rtc-imx-sm-bbm.c | 1 +
> include/linux/mod_devicetable.h | 12 ++++++++++++
> include/linux/scmi_protocol.h | 5 +----
> scripts/mod/devicetable-offsets.c | 4 ++++
> scripts/mod/file2alias.c | 13 +++++++++++++
> 21 files changed, 58 insertions(+), 14 deletions(-)
> ---
> base-commit: 8d6dbbbe3ba62de0a63e962ee004afb848c8e3ac
> change-id: 20260616-scmi-modalias-0f32421bd452
>
> Best regards,
> --
> Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
>
>
^ permalink raw reply
* Re: [PATCH v2 1/2] module: add SCMI device table alias support
From: Frank Li @ 2026-06-18 18:16 UTC (permalink / raw)
To: Bjorn Andersson
Cc: Sudeep Holla, Cristian Marussi, Nathan Chancellor, Nicolas Schier,
Michael Turquette, arm-scmi, linux-arm-kernel, linux-kernel,
linux-kbuild, Hans de Goede, Stephen Boyd, Brian Masney,
Rafael J. Wysocki, Viresh Kumar, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Guenter Roeck,
Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, Liam Girdwood,
Mark Brown, Philipp Zabel, Alexandre Belloni, linux-clk, linux-pm,
imx, linux-hwmon, linux-iio, linux-input, linux-rtc
In-Reply-To: <20260618-scmi-modalias-v2-1-8c7547c1be21@oss.qualcomm.com>
On Thu, Jun 18, 2026 at 03:56:34PM +0000, Bjorn Andersson wrote:
>
> SCMI client drivers already describe their bus match data with
> MODULE_DEVICE_TABLE(scmi, ...), but modpost does not know how to consume
> SCMI device tables. As a result, SCMI modules do not get generated module
> aliases from their id tables.
>
> Move struct scmi_device_id to mod_devicetable.h so it has a fixed layout
> visible to modpost, add the corresponding generated offsets and teach
> file2alias to emit scmi:<protocol>:<name> aliases.
>
> Use the same stable alias format for SCMI device uevents and sysfs
> modaliases. The previous string included the instance-specific device
> name, which is not useful for matching modules.
>
> Assisted-by: Codex:GPT-5.5
> Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
> Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
> ---
Reviewed-by: Frank Li <Frank.Li@nxp.com>
^ permalink raw reply
* [PATCH v2 2/2] firmware: arm_scmi: request modules for discovered protocols
From: Bjorn Andersson @ 2026-06-18 15:56 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Nathan Chancellor, Nicolas Schier,
Michael Turquette
Cc: arm-scmi, linux-arm-kernel, linux-kernel, linux-kbuild,
Hans de Goede, Bjorn Andersson, Stephen Boyd, Brian Masney,
Rafael J. Wysocki, Viresh Kumar, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Guenter Roeck,
Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, Liam Girdwood,
Mark Brown, Philipp Zabel, Alexandre Belloni, linux-clk, linux-pm,
imx, linux-hwmon, linux-iio, linux-input, linux-rtc
In-Reply-To: <20260618-scmi-modalias-v2-0-8c7547c1be21@oss.qualcomm.com>
SCMI client devices are created from SCMI driver id tables. If such a
driver is modular, the core does not know the driver's client name until
the module has already loaded, so normal device uevent based autoloading
cannot break the dependency cycle.
Emit a protocol-level alias for each SCMI device id table entry and
request that alias when the SCMI core discovers an implemented protocol.
This loads modules that have registered interest in the protocol; their
normal SCMI driver registration then requests the concrete client device
and the SCMI bus matches it by protocol and name.
This allows e.g. ARM_SCMI_CPUFREQ=m to autoload on systems that expose
only the SCMI Performance protocol node, where the cpufreq client name
is Linux-internal and not available from firmware before loading the
module.
Assisted-by: Codex:GPT-5.5
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
---
drivers/firmware/arm_scmi/driver.c | 2 ++
include/linux/mod_devicetable.h | 1 +
scripts/mod/file2alias.c | 4 +++-
3 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 0fd6a947499e..7d33fab94e28 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -48,6 +48,7 @@
#include <trace/events/scmi.h>
#define SCMI_VENDOR_MODULE_ALIAS_FMT "scmi-protocol-0x%02x-%s"
+#define SCMI_MODULE_ALIAS_FMT SCMI_PROTOCOL_MODULE_PREFIX "0x%02x"
static DEFINE_IDA(scmi_id);
@@ -3363,6 +3364,7 @@ static int scmi_probe(struct platform_device *pdev)
}
of_node_get(child);
+ request_module_nowait(SCMI_MODULE_ALIAS_FMT, prot_id);
scmi_create_protocol_devices(child, info, prot_id, NULL);
}
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 769382f2eadd..2cc7e78e35a3 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -477,6 +477,7 @@ struct rpmsg_device_id {
#define SCMI_NAME_SIZE 32
#define SCMI_MODULE_PREFIX "scmi:"
+#define SCMI_PROTOCOL_MODULE_PREFIX "scmi-protocol-"
struct scmi_device_id {
__u8 protocol_id;
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index a5283f4c8e6f..40a37b6bf1ad 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -852,7 +852,7 @@ static void do_rpmsg_entry(struct module *mod, void *symval)
module_alias_printf(mod, false, RPMSG_DEVICE_MODALIAS_FMT, *name);
}
-/* Looks like: scmi:NN:S */
+/* Looks like: scmi:NN:S and scmi-protocol-0xNN */
static void do_scmi_entry(struct module *mod, void *symval)
{
DEF_FIELD(symval, scmi_device_id, protocol_id);
@@ -860,6 +860,8 @@ static void do_scmi_entry(struct module *mod, void *symval)
module_alias_printf(mod, false, SCMI_MODULE_PREFIX "%02x:%s",
protocol_id, *name);
+ module_alias_printf(mod, false, SCMI_PROTOCOL_MODULE_PREFIX "0x%02x",
+ protocol_id);
}
/* Looks like: i2c:S */
--
2.53.0
^ permalink raw reply related
* [PATCH v2 1/2] module: add SCMI device table alias support
From: Bjorn Andersson @ 2026-06-18 15:56 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Nathan Chancellor, Nicolas Schier,
Michael Turquette
Cc: arm-scmi, linux-arm-kernel, linux-kernel, linux-kbuild,
Hans de Goede, Bjorn Andersson, Stephen Boyd, Brian Masney,
Rafael J. Wysocki, Viresh Kumar, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Guenter Roeck,
Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, Liam Girdwood,
Mark Brown, Philipp Zabel, Alexandre Belloni, linux-clk, linux-pm,
imx, linux-hwmon, linux-iio, linux-input, linux-rtc
In-Reply-To: <20260618-scmi-modalias-v2-0-8c7547c1be21@oss.qualcomm.com>
SCMI client drivers already describe their bus match data with
MODULE_DEVICE_TABLE(scmi, ...), but modpost does not know how to consume
SCMI device tables. As a result, SCMI modules do not get generated module
aliases from their id tables.
Move struct scmi_device_id to mod_devicetable.h so it has a fixed layout
visible to modpost, add the corresponding generated offsets and teach
file2alias to emit scmi:<protocol>:<name> aliases.
Use the same stable alias format for SCMI device uevents and sysfs
modaliases. The previous string included the instance-specific device
name, which is not useful for matching modules.
Assisted-by: Codex:GPT-5.5
Reviewed-by: Hans de Goede <johannes.goede@oss.qualcomm.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
---
drivers/clk/clk-scmi.c | 1 +
drivers/cpufreq/scmi-cpufreq.c | 1 +
drivers/firmware/arm_scmi/bus.c | 20 ++++++++++----------
drivers/firmware/arm_scmi/driver.c | 1 +
drivers/firmware/arm_scmi/scmi_power_control.c | 1 +
drivers/firmware/imx/sm-cpu.c | 1 +
drivers/firmware/imx/sm-lmm.c | 1 +
drivers/firmware/imx/sm-misc.c | 1 +
drivers/hwmon/scmi-hwmon.c | 1 +
drivers/iio/common/scmi_sensors/scmi_iio.c | 1 +
drivers/input/keyboard/imx-sm-bbm-key.c | 1 +
drivers/pmdomain/arm/scmi_perf_domain.c | 1 +
drivers/pmdomain/arm/scmi_pm_domain.c | 1 +
drivers/powercap/arm_scmi_powercap.c | 1 +
drivers/regulator/scmi-regulator.c | 1 +
drivers/reset/reset-scmi.c | 1 +
drivers/rtc/rtc-imx-sm-bbm.c | 1 +
include/linux/mod_devicetable.h | 11 +++++++++++
include/linux/scmi_protocol.h | 5 +----
scripts/mod/devicetable-offsets.c | 4 ++++
scripts/mod/file2alias.c | 11 +++++++++++
21 files changed, 53 insertions(+), 14 deletions(-)
diff --git a/drivers/clk/clk-scmi.c b/drivers/clk/clk-scmi.c
index 7c562559ad8b..b9e29e124302 100644
--- a/drivers/clk/clk-scmi.c
+++ b/drivers/clk/clk-scmi.c
@@ -11,6 +11,7 @@
#include <linux/err.h>
#include <linux/of.h>
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/scmi_protocol.h>
#define NOT_ATOMIC false
diff --git a/drivers/cpufreq/scmi-cpufreq.c b/drivers/cpufreq/scmi-cpufreq.c
index 4edb4f7a8aa9..affa005bf8b1 100644
--- a/drivers/cpufreq/scmi-cpufreq.c
+++ b/drivers/cpufreq/scmi-cpufreq.c
@@ -15,6 +15,7 @@
#include <linux/energy_model.h>
#include <linux/export.h>
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/of.h>
#include <linux/pm_opp.h>
#include <linux/pm_qos.h>
diff --git a/drivers/firmware/arm_scmi/bus.c b/drivers/firmware/arm_scmi/bus.c
index 793be9eabaed..70781146fa61 100644
--- a/drivers/firmware/arm_scmi/bus.c
+++ b/drivers/firmware/arm_scmi/bus.c
@@ -10,14 +10,16 @@
#include <linux/atomic.h>
#include <linux/types.h>
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/of.h>
#include <linux/kernel.h>
#include <linux/slab.h>
+#include <linux/string.h>
#include <linux/device.h>
#include "common.h"
-#define SCMI_UEVENT_MODALIAS_FMT "%s:%02x:%s"
+#define SCMI_UEVENT_MODALIAS_FMT SCMI_MODULE_PREFIX "%02x:%s"
BLOCKING_NOTIFIER_HEAD(scmi_requested_devices_nh);
EXPORT_SYMBOL_GPL(scmi_requested_devices_nh);
@@ -141,7 +143,7 @@ static int scmi_protocol_table_register(const struct scmi_device_id *id_table)
int ret = 0;
const struct scmi_device_id *entry;
- for (entry = id_table; entry->name && ret == 0; entry++)
+ for (entry = id_table; entry->name[0] && ret == 0; entry++)
ret = scmi_protocol_device_request(entry);
return ret;
@@ -197,18 +199,18 @@ scmi_protocol_table_unregister(const struct scmi_device_id *id_table)
{
const struct scmi_device_id *entry;
- for (entry = id_table; entry->name; entry++)
+ for (entry = id_table; entry->name[0]; entry++)
scmi_protocol_device_unrequest(entry);
}
static int scmi_dev_match_by_id_table(struct scmi_device *scmi_dev,
const struct scmi_device_id *id_table)
{
- if (!id_table || !id_table->name)
+ if (!id_table || !id_table->name[0])
return 0;
/* Always skip transport devices from matching */
- for (; id_table->protocol_id && id_table->name; id_table++)
+ for (; id_table->protocol_id && id_table->name[0]; id_table++)
if (id_table->protocol_id == scmi_dev->protocol_id &&
strncmp(scmi_dev->name, "__scmi_transport_device", 23) &&
!strcmp(id_table->name, scmi_dev->name))
@@ -245,7 +247,7 @@ static struct scmi_device *scmi_child_dev_find(struct device *parent,
struct device *dev;
id_table[0].protocol_id = prot_id;
- id_table[0].name = name;
+ strscpy(id_table[0].name, name, sizeof(id_table[0].name));
dev = device_find_child(parent, &id_table, scmi_match_by_id_table);
if (!dev)
@@ -282,8 +284,7 @@ static int scmi_device_uevent(const struct device *dev, struct kobj_uevent_env *
const struct scmi_device *scmi_dev = to_scmi_dev(dev);
return add_uevent_var(env, "MODALIAS=" SCMI_UEVENT_MODALIAS_FMT,
- dev_name(&scmi_dev->dev), scmi_dev->protocol_id,
- scmi_dev->name);
+ scmi_dev->protocol_id, scmi_dev->name);
}
static ssize_t modalias_show(struct device *dev,
@@ -292,8 +293,7 @@ static ssize_t modalias_show(struct device *dev,
struct scmi_device *scmi_dev = to_scmi_dev(dev);
return sysfs_emit(buf, SCMI_UEVENT_MODALIAS_FMT,
- dev_name(&scmi_dev->dev), scmi_dev->protocol_id,
- scmi_dev->name);
+ scmi_dev->protocol_id, scmi_dev->name);
}
static DEVICE_ATTR_RO(modalias);
diff --git a/drivers/firmware/arm_scmi/driver.c b/drivers/firmware/arm_scmi/driver.c
index 3e0d975ec94c..0fd6a947499e 100644
--- a/drivers/firmware/arm_scmi/driver.c
+++ b/drivers/firmware/arm_scmi/driver.c
@@ -30,6 +30,7 @@
#include <linux/hashtable.h>
#include <linux/list.h>
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/processor.h>
diff --git a/drivers/firmware/arm_scmi/scmi_power_control.c b/drivers/firmware/arm_scmi/scmi_power_control.c
index 955736336061..1900bb77383e 100644
--- a/drivers/firmware/arm_scmi/scmi_power_control.c
+++ b/drivers/firmware/arm_scmi/scmi_power_control.c
@@ -45,6 +45,7 @@
#include <linux/math.h>
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/mutex.h>
#include <linux/pm.h>
#include <linux/printk.h>
diff --git a/drivers/firmware/imx/sm-cpu.c b/drivers/firmware/imx/sm-cpu.c
index 091b014f739f..53a8d1cee5ea 100644
--- a/drivers/firmware/imx/sm-cpu.c
+++ b/drivers/firmware/imx/sm-cpu.c
@@ -5,6 +5,7 @@
#include <linux/firmware/imx/sm.h>
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/scmi_protocol.h>
diff --git a/drivers/firmware/imx/sm-lmm.c b/drivers/firmware/imx/sm-lmm.c
index 6807bf563c03..f4dc198187a8 100644
--- a/drivers/firmware/imx/sm-lmm.c
+++ b/drivers/firmware/imx/sm-lmm.c
@@ -5,6 +5,7 @@
#include <linux/firmware/imx/sm.h>
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/scmi_protocol.h>
diff --git a/drivers/firmware/imx/sm-misc.c b/drivers/firmware/imx/sm-misc.c
index ac9af824c2d4..5e39e79a9d8a 100644
--- a/drivers/firmware/imx/sm-misc.c
+++ b/drivers/firmware/imx/sm-misc.c
@@ -7,6 +7,7 @@
#include <linux/device/devres.h>
#include <linux/firmware/imx/sm.h>
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/scmi_protocol.h>
diff --git a/drivers/hwmon/scmi-hwmon.c b/drivers/hwmon/scmi-hwmon.c
index eec223d174c0..57b91e931c5d 100644
--- a/drivers/hwmon/scmi-hwmon.c
+++ b/drivers/hwmon/scmi-hwmon.c
@@ -8,6 +8,7 @@
#include <linux/hwmon.h>
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/scmi_protocol.h>
#include <linux/slab.h>
#include <linux/sysfs.h>
diff --git a/drivers/iio/common/scmi_sensors/scmi_iio.c b/drivers/iio/common/scmi_sensors/scmi_iio.c
index 442b40ef27cf..3babc4261965 100644
--- a/drivers/iio/common/scmi_sensors/scmi_iio.c
+++ b/drivers/iio/common/scmi_sensors/scmi_iio.c
@@ -15,6 +15,7 @@
#include <linux/kernel.h>
#include <linux/kthread.h>
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/mutex.h>
#include <linux/scmi_protocol.h>
#include <linux/time.h>
diff --git a/drivers/input/keyboard/imx-sm-bbm-key.c b/drivers/input/keyboard/imx-sm-bbm-key.c
index 96486bd23d60..36e349136ee7 100644
--- a/drivers/input/keyboard/imx-sm-bbm-key.c
+++ b/drivers/input/keyboard/imx-sm-bbm-key.c
@@ -6,6 +6,7 @@
#include <linux/input.h>
#include <linux/jiffies.h>
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/of.h>
#include <linux/platform_device.h>
#include <linux/rtc.h>
diff --git a/drivers/pmdomain/arm/scmi_perf_domain.c b/drivers/pmdomain/arm/scmi_perf_domain.c
index 3693423459c9..741375ad325b 100644
--- a/drivers/pmdomain/arm/scmi_perf_domain.c
+++ b/drivers/pmdomain/arm/scmi_perf_domain.c
@@ -8,6 +8,7 @@
#include <linux/err.h>
#include <linux/device.h>
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/pm_domain.h>
#include <linux/pm_opp.h>
#include <linux/scmi_protocol.h>
diff --git a/drivers/pmdomain/arm/scmi_pm_domain.c b/drivers/pmdomain/arm/scmi_pm_domain.c
index 3d73aef21d2f..0948d05c9e3c 100644
--- a/drivers/pmdomain/arm/scmi_pm_domain.c
+++ b/drivers/pmdomain/arm/scmi_pm_domain.c
@@ -8,6 +8,7 @@
#include <linux/err.h>
#include <linux/io.h>
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/pm_domain.h>
#include <linux/scmi_protocol.h>
diff --git a/drivers/powercap/arm_scmi_powercap.c b/drivers/powercap/arm_scmi_powercap.c
index ab66e9a3b1e2..332e4e26f1e5 100644
--- a/drivers/powercap/arm_scmi_powercap.c
+++ b/drivers/powercap/arm_scmi_powercap.c
@@ -10,6 +10,7 @@
#include <linux/limits.h>
#include <linux/list.h>
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/powercap.h>
#include <linux/scmi_protocol.h>
#include <linux/slab.h>
diff --git a/drivers/regulator/scmi-regulator.c b/drivers/regulator/scmi-regulator.c
index c005e65ba0ec..f55f228cb133 100644
--- a/drivers/regulator/scmi-regulator.c
+++ b/drivers/regulator/scmi-regulator.c
@@ -25,6 +25,7 @@
#include <linux/linear_range.h>
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/of.h>
#include <linux/regulator/driver.h>
#include <linux/regulator/machine.h>
diff --git a/drivers/reset/reset-scmi.c b/drivers/reset/reset-scmi.c
index 4335811e0cfa..a6739df1d3c2 100644
--- a/drivers/reset/reset-scmi.c
+++ b/drivers/reset/reset-scmi.c
@@ -6,6 +6,7 @@
*/
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/of.h>
#include <linux/device.h>
#include <linux/reset-controller.h>
diff --git a/drivers/rtc/rtc-imx-sm-bbm.c b/drivers/rtc/rtc-imx-sm-bbm.c
index daa472be7c80..c8643718cef1 100644
--- a/drivers/rtc/rtc-imx-sm-bbm.c
+++ b/drivers/rtc/rtc-imx-sm-bbm.c
@@ -5,6 +5,7 @@
#include <linux/jiffies.h>
#include <linux/module.h>
+#include <linux/mod_devicetable.h>
#include <linux/platform_device.h>
#include <linux/rtc.h>
#include <linux/scmi_protocol.h>
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 3b0c9a251a2e..769382f2eadd 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -473,6 +473,17 @@ struct rpmsg_device_id {
kernel_ulong_t driver_data;
};
+/* scmi */
+
+#define SCMI_NAME_SIZE 32
+#define SCMI_MODULE_PREFIX "scmi:"
+
+struct scmi_device_id {
+ __u8 protocol_id;
+ char name[SCMI_NAME_SIZE];
+ kernel_ulong_t driver_data;
+};
+
/* i2c */
#define I2C_NAME_SIZE 20
diff --git a/include/linux/scmi_protocol.h b/include/linux/scmi_protocol.h
index 5ab73b1ab9aa..61f5ecfe0133 100644
--- a/include/linux/scmi_protocol.h
+++ b/include/linux/scmi_protocol.h
@@ -951,10 +951,7 @@ struct scmi_device {
#define to_scmi_dev(d) container_of_const(d, struct scmi_device, dev)
-struct scmi_device_id {
- u8 protocol_id;
- const char *name;
-};
+struct scmi_device_id;
struct scmi_driver {
const char *name;
diff --git a/scripts/mod/devicetable-offsets.c b/scripts/mod/devicetable-offsets.c
index b4178c42d08f..da5bd712c8da 100644
--- a/scripts/mod/devicetable-offsets.c
+++ b/scripts/mod/devicetable-offsets.c
@@ -144,6 +144,10 @@ int main(void)
DEVID(rpmsg_device_id);
DEVID_FIELD(rpmsg_device_id, name);
+ DEVID(scmi_device_id);
+ DEVID_FIELD(scmi_device_id, protocol_id);
+ DEVID_FIELD(scmi_device_id, name);
+
DEVID(i2c_device_id);
DEVID_FIELD(i2c_device_id, name);
diff --git a/scripts/mod/file2alias.c b/scripts/mod/file2alias.c
index 8d36c74dec2d..a5283f4c8e6f 100644
--- a/scripts/mod/file2alias.c
+++ b/scripts/mod/file2alias.c
@@ -852,6 +852,16 @@ static void do_rpmsg_entry(struct module *mod, void *symval)
module_alias_printf(mod, false, RPMSG_DEVICE_MODALIAS_FMT, *name);
}
+/* Looks like: scmi:NN:S */
+static void do_scmi_entry(struct module *mod, void *symval)
+{
+ DEF_FIELD(symval, scmi_device_id, protocol_id);
+ DEF_FIELD_ADDR(symval, scmi_device_id, name);
+
+ module_alias_printf(mod, false, SCMI_MODULE_PREFIX "%02x:%s",
+ protocol_id, *name);
+}
+
/* Looks like: i2c:S */
static void do_i2c_entry(struct module *mod, void *symval)
{
@@ -1491,6 +1501,7 @@ static const struct devtable devtable[] = {
{"virtio", SIZE_virtio_device_id, do_virtio_entry},
{"vmbus", SIZE_hv_vmbus_device_id, do_vmbus_entry},
{"rpmsg", SIZE_rpmsg_device_id, do_rpmsg_entry},
+ {"scmi", SIZE_scmi_device_id, do_scmi_entry},
{"i2c", SIZE_i2c_device_id, do_i2c_entry},
{"i3c", SIZE_i3c_device_id, do_i3c_entry},
{"slim", SIZE_slim_device_id, do_slim_entry},
--
2.53.0
^ permalink raw reply related
* [PATCH v2 0/2] firmware: arm_scmi: Ensure automatic module loading
From: Bjorn Andersson @ 2026-06-18 15:56 UTC (permalink / raw)
To: Sudeep Holla, Cristian Marussi, Nathan Chancellor, Nicolas Schier,
Michael Turquette
Cc: arm-scmi, linux-arm-kernel, linux-kernel, linux-kbuild,
Hans de Goede, Bjorn Andersson, Stephen Boyd, Brian Masney,
Rafael J. Wysocki, Viresh Kumar, Frank Li, Sascha Hauer,
Pengutronix Kernel Team, Fabio Estevam, Guenter Roeck,
Jyoti Bhayana, Jonathan Cameron, David Lechner, Nuno Sá,
Andy Shevchenko, Dmitry Torokhov, Ulf Hansson, Liam Girdwood,
Mark Brown, Philipp Zabel, Alexandre Belloni, linux-clk, linux-pm,
imx, linux-hwmon, linux-iio, linux-input, linux-rtc
SCMI drivers such as the Arm SCMI CPUfreq driver are allowed to built as
modules, but they are then not automatically loaded. Rework the SCMI
device table alias support to make modpost consume the information from
MODULE_DEVICE_TABLE(scmi, ...) and allow drivers to be loaded based on
this information, if known. Also add a protocol-based alias to also
trigger driver loading when only the SCMI protocol id is known.
Signed-off-by: Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
---
Changes in v2:
- Use request_module_nowait()
- Drop #include <linux/mod_devicetable.h> from scmi_protocol.h
- Link to v1: https://patch.msgid.link/20260616-scmi-modalias-v1-0-662b8dd52ab2@oss.qualcomm.com
To: Sudeep Holla <sudeep.holla@kernel.org>
To: Cristian Marussi <cristian.marussi@arm.com>
To: Michael Turquette <mturquette@baylibre.com>
To: Nicolas Schier <nsc@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: Brian Masney <bmasney@redhat.com>
Cc: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Frank Li <Frank.Li@nxp.com>
Cc: Sascha Hauer <s.hauer@pengutronix.de>
Cc: Pengutronix Kernel Team <kernel@pengutronix.de>
Cc: Fabio Estevam <festevam@gmail.com>
Cc: Guenter Roeck <linux@roeck-us.net>
Cc: Jyoti Bhayana <jbhayana@google.com>
Cc: Jonathan Cameron <jic23@kernel.org>
Cc: David Lechner <dlechner@baylibre.com>
Cc: Nuno Sá <nuno.sa@analog.com>
Cc: Andy Shevchenko <andy@kernel.org>
Cc: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Ulf Hansson <ulfh@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>
Cc: Mark Brown <broonie@kernel.org>
Cc: Philipp Zabel <p.zabel@pengutronix.de>
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: arm-scmi@vger.kernel.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: imx@lists.linux.dev
Cc: linux-hwmon@vger.kernel.org
Cc: linux-iio@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-rtc@vger.kernel.org
Cc: linux-kbuild@vger.kernel.org
---
Bjorn Andersson (2):
module: add SCMI device table alias support
firmware: arm_scmi: request modules for discovered protocols
drivers/clk/clk-scmi.c | 1 +
drivers/cpufreq/scmi-cpufreq.c | 1 +
drivers/firmware/arm_scmi/bus.c | 20 ++++++++++----------
drivers/firmware/arm_scmi/driver.c | 3 +++
drivers/firmware/arm_scmi/scmi_power_control.c | 1 +
drivers/firmware/imx/sm-cpu.c | 1 +
drivers/firmware/imx/sm-lmm.c | 1 +
drivers/firmware/imx/sm-misc.c | 1 +
drivers/hwmon/scmi-hwmon.c | 1 +
drivers/iio/common/scmi_sensors/scmi_iio.c | 1 +
drivers/input/keyboard/imx-sm-bbm-key.c | 1 +
drivers/pmdomain/arm/scmi_perf_domain.c | 1 +
drivers/pmdomain/arm/scmi_pm_domain.c | 1 +
drivers/powercap/arm_scmi_powercap.c | 1 +
drivers/regulator/scmi-regulator.c | 1 +
drivers/reset/reset-scmi.c | 1 +
drivers/rtc/rtc-imx-sm-bbm.c | 1 +
include/linux/mod_devicetable.h | 12 ++++++++++++
include/linux/scmi_protocol.h | 5 +----
scripts/mod/devicetable-offsets.c | 4 ++++
scripts/mod/file2alias.c | 13 +++++++++++++
21 files changed, 58 insertions(+), 14 deletions(-)
---
base-commit: 8d6dbbbe3ba62de0a63e962ee004afb848c8e3ac
change-id: 20260616-scmi-modalias-0f32421bd452
Best regards,
--
Bjorn Andersson <bjorn.andersson@oss.qualcomm.com>
^ permalink raw reply
* Re: [PATCH 12/12] rtc: rzn1: Add support for Renesas RZ/T2H and RZ/N2H SoCs
From: Lad, Prabhakar @ 2026-06-18 13:28 UTC (permalink / raw)
To: Wolfram Sang
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <ajKAqn1F074JJazF@shikoro>
Hi Wolfram,
Thank you for the review.
On Wed, Jun 17, 2026 at 12:10 PM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
>
> On Mon, Jun 15, 2026 at 04:48:05PM +0100, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > Add a new compatible string "renesas,r9a09g077-rtc" to the OF match table
> > to support the RTC IP variant found on the RZ/T2H and RZ/N2H SoCs.
> >
> > These newer SoCs integrate a closely related variant of the RZ/N1 RTC IP.
> > The RZ/T2H and RZ/N2H variants lack the RTCA0SUBU and RTCA0TCR registers,
>
> The RTCA0TCR is also not on RZ/N1.
>
Ah, right I missed "Not available in this LSI.", I will update the
description accordingly in v2.
Cheers,
Prabhakar
> > those registers are not accessed or used when operating under the
> > rzn1_rtc_ops_scmp configurations, making the current infrastructure
> > compatible.
> >
> > The RZ/T2H RTC variant also supports a 1 Hz output signal on the
> > RTCAT1HZ pin, controlled by the RTCA0CTL1[RTCA01HZE] bit. This bit is
> > marked as reserved in the RZ/N1 hardware manual, making RZ/T2H a
> > distinct RTC variant despite its overall compatibility with the RZ/N1
> > implementation.
> >
> > Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
>
> With that fixed:
>
> Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com>
>
^ permalink raw reply
* Re: [PATCH 11/12] rtc: rzn1: use FIELD_PREP/FIELD_GET and GENMASK for register access
From: Lad, Prabhakar @ 2026-06-18 13:26 UTC (permalink / raw)
To: Wolfram Sang
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <ajJ_qwXhJbKB3Xli@shikoro>
Hi Wolfram,
On Wed, Jun 17, 2026 at 12:06 PM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
>
> Hi,
>
> Sashiko found issues with your patch. I curated the list and left only those
> which I see as valid. Please have a look at these issues.
>
Agreed, I will replace the 0x3f with RZN1_RTC_SUBU_RTCA0FX macro in
the next version.
Cheers,
Prabhakar
> Thank you and happy hacking,
>
> Wolfram
>
> > Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> > - [Low] Incomplete refactoring: open-coded logic remains for RZN1_RTC_SUBU_RTCA0FX
> > --
> >
> > commit 2e16f66c80c483d619655d20fbb859a42e9d1b6d
> > Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > rtc: rzn1: use FIELD_PREP/FIELD_GET and GENMASK for register access
> >
> > This commit replaces open-coded shift and mask operations with the bitfield
> > API in the rzn1 RTC driver to improve readability and match the hardware
> > manual.
> >
> > > diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> > > index c7ef3c81180f4..9f9cf9882fc49 100644
> > > --- a/drivers/rtc/rtc-rzn1.c
> > > +++ b/drivers/rtc/rtc-rzn1.c
> > [ ... ]
> > > @@ -306,7 +312,7 @@ static int rzn1_rtc_read_offset(struct device *dev, long *offset)
> > > val = readl(rtc->base + RZN1_RTC_SUBU);
> > > ppb_per_step = val & RZN1_RTC_SUBU_DEV ? 1017 : 3051;
> > > subtract = val & RZN1_RTC_SUBU_DECR;
> > > - val &= 0x3F;
> > > + val = FIELD_GET(RZN1_RTC_SUBU_RTCA0FX, val);
> > >
> > > if (!val)
> > > *offset = 0;
> >
> > [Severity: Low]
> > Since the stated goal of this patch is to replace open-coded masks with the
> > bitfield API, should the remaining 0x3F masks for this register be updated as
> > well?
> >
> > In rzn1_rtc_read_offset() just below this change, there is still an explicit
> > mask used when calculating the offset:
> >
> > *offset = -(((~val) & 0x3F) + 1) * ppb_per_step;
> >
> > Additionally, it looks like the write path in rzn1_rtc_set_offset() was missed
> > entirely during the refactoring. It continues to use open-coded logic rather
> > than FIELD_PREP when constructing the RZN1_RTC_SUBU register:
> >
> > subu |= RZN1_RTC_SUBU_DECR;
> > subu |= (~(-steps - 1)) & 0x3F;
> >
> > Would it make sense to update these locations so the bitfield access is
> > consistent across the driver?
> >
> > --
> > Sashiko AI review · https://sashiko.dev/#/patchset/20260615154805.1619693-1-prabhakar.mahadev-lad.rj@bp.renesas.com?part=11
^ permalink raw reply
* Re: [PATCH 09/12] rtc: rzn1: Use temporary variable for struct device
From: Lad, Prabhakar @ 2026-06-18 13:10 UTC (permalink / raw)
To: Wolfram Sang
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <ajKAPJGrea01XVeI@shikoro>
Hi Wolfram,
On Wed, Jun 17, 2026 at 12:08 PM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
>
> Hi,
>
> Sashiko found issues, not introduced by your patch, but still. I
> curated the list and left only those which I think are valid. Do you
> have time to look at these issues?
>
> Thank you and happy hacking,
>
> Wolfram
>
> > Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
> >
> > Pre-existing issues:
> > - [High] Asynchronous pm_runtime_put() is used instead of pm_runtime_put_sync() before runtime PM is disabled, potentially leaving the device powered on.
> > - [High] If the optional 'xtal' clock is missing, readl_poll_timeout() loops forever with a 0 timeout, risking a boot hang.
> > - [High] The driver's `remove` callback prematurely disables hardware interrupts and drops the runtime PM reference while the RTC device is still fully registered.
> > --
> >
> > commit b7f73c7d0932a6e78b12419c5912ad3243637b8f
> > Author: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > rtc: rzn1: Use temporary variable for struct device
> >
> > This patch simplifies the rzn1_rtc_probe function by using a local temporary
> > variable for the struct device pointer. This avoids repeated dereferences of
> > pdev->dev throughout the function.
> >
> > > diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> > > index bc6af59744e48..25cad9213147d 100644
> > > --- a/drivers/rtc/rtc-rzn1.c
> > > +++ b/drivers/rtc/rtc-rzn1.c
> > [ ... ]
> > > if (IS_ERR(xtal)) {
> > > ret = PTR_ERR(xtal);
> > > goto dis_runtime_pm;
> > [ ... ]
> > > @@ -486,18 +487,18 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
> > [ ... ]
> > > device_init_wakeup(dev, true);
> > >
> > > ret = devm_rtc_register_device(rtc->rtcdev);
> >
> > [Severity: High]
> > This isn't a bug introduced by this patch, but does registering the RTC
> > device using devm_rtc_register_device() create a race condition during
> > teardown?
> >
> > In rzn1_rtc_remove(), the driver manually disables interrupts and calls
> > pm_runtime_put() before devres has unregistered the RTC device:
> >
> > writel(0, rtc->base + RZN1_RTC_CTL1);
> > pm_runtime_put(&pdev->dev);
> >
> > Could userspace still interact with the RTC during this window via ioctls
> > or sysfs, potentially causing synchronous bus faults since the hardware is
> > already suspended? Should teardown be bound using
> > devm_add_action_or_reset() to guarantee correct reverse execution order?
>
> [wsa] Or maybe not use devm then?
>
Maybe just add two `devm_add_action_or_reset()` calls: one to clear
interrupts and another to call pm_runtime_put()?
> >
> > > if (ret)
> > > @@ -506,7 +507,7 @@ static int rzn1_rtc_probe(struct platform_device *pdev)
> > > return 0;
> > >
> > > dis_runtime_pm:
> > > - pm_runtime_put(&pdev->dev);
> > > + pm_runtime_put(dev);
> >
> > [Severity: High]
> > This is a pre-existing issue, but does using pm_runtime_put() here (and in
> > rzn1_rtc_remove) leave the device powered on indefinitely?
> >
> > Since devm_pm_runtime_enable(dev) schedules pm_runtime_disable() to
> > execute during devres cleanup, calling pm_runtime_put() only queues an
> > asynchronous idle check. The immediate return triggers devres cleanup,
> > which executes a barrier that explicitly cancels pending async operations.
> >
> > Should this use pm_runtime_put_sync() instead to ensure the device is
> > synchronously suspended before teardown?
> >
Although there were some patches accepted for similar kind of issue
reported by Sashiko, do you think I should switch to
pm_runtime_put_sync() (Ive not seen any issues)
Cheers,
Prabhakar
^ permalink raw reply
* Re: [PATCH 07/12] rtc: rzn1: fix alarm range check truncation on 32-bit systems
From: Alexandre Belloni @ 2026-06-18 12:26 UTC (permalink / raw)
To: Lad, Prabhakar
Cc: Miquel Raynal, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Wolfram Sang, linux-rtc,
linux-renesas-soc, devicetree, linux-kernel, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <CA+V-a8uHVR0i+3PY_qi3i0H6fMJSUFb=1cwrgw0VeztVQk-dWw@mail.gmail.com>
On 18/06/2026 11:49:12+0100, Lad, Prabhakar wrote:
> Hi Alexandre,
>
> On Wed, Jun 17, 2026 at 5:55 PM Alexandre Belloni
> <alexandre.belloni@bootlin.com> wrote:
> >
> > On 15/06/2026 16:48:00+0100, Prabhakar wrote:
> > > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> > >
> > > alarm and farest were declared as unsigned long, but
> > > rtc_tm_to_time64() returns time64_t (s64). On 32-bit systems where
> > > unsigned long is 32 bits, the assignment silently truncates the upper
> > > 32 bits of the timestamp.
> > >
> > > Fix by declaring alarm and farest as time64_t and replacing
> > > time_after() with a direct signed comparison, which is correct for
> > > time64_t values that will never realistically overflow.
> > >
> >
> > I'd argue that this is never going to overflow ever as unsigned long
> > gets you to 2106 which is way past the usable range of the RTC so there
> > is a trade off between the size you are going to take on the stack and
> > the actual usefulness of the fix.
> >
> While it's true that unsigned long lasts until 2106 (well past this
> RTC's practical lifetime), rtc_tm_to_time64() explicitly returns
> time64_t. Using unsigned long causes silent truncation and types
> mismatch with the API, which modern static analyzers flag. Given that
> this function is not deeply nested, the 8-byte stack trade-off seems
> worth it for type cleanliness and consistency. What do you think?
>
I'll take the patch but I still find t a bit irritating that the
justification for this kind of patches is static analyzers report an
issue so let's make the kernel less efficient for everyone.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH 08/12] rtc: rzn1: Dynamically calculate synchronization delay based on clock rate
From: Lad, Prabhakar @ 2026-06-18 11:23 UTC (permalink / raw)
To: Wolfram Sang
Cc: Miquel Raynal, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Geert Uytterhoeven,
Magnus Damm, linux-rtc, linux-renesas-soc, devicetree,
linux-kernel, Biju Das, Fabrizio Castro, Lad Prabhakar
In-Reply-To: <ajJ95P-jxChrTY9w@shikoro>
Hi Wolfram,
Thank you for the review.
On Wed, Jun 17, 2026 at 11:58 AM Wolfram Sang
<wsa+renesas@sang-engineering.com> wrote:
>
>
> As mentioned in another thread:
>
> > drivers/rtc/rtc-rzn1.c | 19 ++++++++++++++-----
> > 1 file changed, 14 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/rtc/rtc-rzn1.c b/drivers/rtc/rtc-rzn1.c
> > index 06339adae71f..bc6af59744e4 100644
> > --- a/drivers/rtc/rtc-rzn1.c
> > +++ b/drivers/rtc/rtc-rzn1.c
> > @@ -71,6 +71,7 @@ struct rzn1_rtc {
> > */
> > spinlock_t ctl1_access_lock;
> > struct rtc_time tm_alarm;
> > + unsigned long sync_time;
> > int alarm_irq;
> > int sec_irq;
> > bool alarm_enabled;
>
> rate = 32768 here...
>
Agreed (in the rzn1_rtc_probe, to be precise).
> > + rtc->sync_time = DIV_ROUND_UP(2 * NSEC_PER_MSEC, rate);
> > +
> > }
>
> ... and move this to the main body of the function.
>
>
> Then, we should have all values always initialized.
>
Agreed, I will fix it in v2.
Cheers,
Prabhakar
^ permalink raw reply
* Re: [PATCH 07/12] rtc: rzn1: fix alarm range check truncation on 32-bit systems
From: Lad, Prabhakar @ 2026-06-18 10:49 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Miquel Raynal, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Geert Uytterhoeven, Magnus Damm, Wolfram Sang, linux-rtc,
linux-renesas-soc, devicetree, linux-kernel, Biju Das,
Fabrizio Castro, Lad Prabhakar
In-Reply-To: <20260617165538dad7e36b@mail.local>
Hi Alexandre,
On Wed, Jun 17, 2026 at 5:55 PM Alexandre Belloni
<alexandre.belloni@bootlin.com> wrote:
>
> On 15/06/2026 16:48:00+0100, Prabhakar wrote:
> > From: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com>
> >
> > alarm and farest were declared as unsigned long, but
> > rtc_tm_to_time64() returns time64_t (s64). On 32-bit systems where
> > unsigned long is 32 bits, the assignment silently truncates the upper
> > 32 bits of the timestamp.
> >
> > Fix by declaring alarm and farest as time64_t and replacing
> > time_after() with a direct signed comparison, which is correct for
> > time64_t values that will never realistically overflow.
> >
>
> I'd argue that this is never going to overflow ever as unsigned long
> gets you to 2106 which is way past the usable range of the RTC so there
> is a trade off between the size you are going to take on the stack and
> the actual usefulness of the fix.
>
While it's true that unsigned long lasts until 2106 (well past this
RTC's practical lifetime), rtc_tm_to_time64() explicitly returns
time64_t. Using unsigned long causes silent truncation and types
mismatch with the API, which modern static analyzers flag. Given that
this function is not deeply nested, the 8-byte stack trade-off seems
worth it for type cleanliness and consistency. What do you think?
Cheers,
Prabhakar
^ 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