* [RFC PATCH v3 0/5] rust: Add RTC driver support
From: Ke Sun @ 2026-01-16 16:21 UTC (permalink / raw)
To: Alexandre Belloni, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, Danilo Krummrich
Cc: linux-rtc, rust-for-linux, Alvin Sun, Ke Sun
This patch series adds RTC (Real-Time Clock) driver support for the Rust
kernel, including the necessary infrastructure and a complete driver
implementation for the PL031 RTC.
---
v3:
- Add rtc_ops_dev() helper with RTC_OPS_USE_RTC_DEV flag to allow drivers to
choose device pointer for rtc_class_ops callbacks. This enables Rust RTC
drivers to store drvdata on rtc->dev while maintaining backward compatibility
for existing C drivers without requiring driver modifications
- Refactor AMBA and RTC abstractions to address v2 review feedback
v2: https://lore.kernel.org/rust-for-linux/20260107143738.3021892-1-sunke@kylinos.cn/
- Migrate RTC driver data storage from parent device to RTC device for
unified interface
- Expand AMBA bus abstractions to full driver support with enhanced
functionality
- Refactor device wakeup API by moving wake IRQ setup to IRQ layer
- Simplify RTC core framework by removing multi-bus abstractions,
focusing on core operations
- Optimize PL031 driver implementation and remove build assertion
dependency
v1: https://lore.kernel.org/rust-for-linux/20260104060621.3757812-1-sunke@kylinos.cn/
- Add AMBA bus abstractions
- Add device wakeup support
- Add RTC core framework with multi-bus support
- Add PL031 RTC driver
---
Ke Sun (5):
rtc: add device selector for rtc_class_ops callbacks
rust: add AMBA bus driver support
rust: add device wakeup capability support
rust: add RTC core abstractions and data structures
rust: add PL031 RTC driver
drivers/rtc/Kconfig | 9 +
drivers/rtc/Makefile | 1 +
drivers/rtc/dev.c | 6 +-
drivers/rtc/interface.c | 18 +-
drivers/rtc/proc.c | 2 +-
drivers/rtc/rtc_pl031_rust.rs | 513 ++++++++++++++++
include/linux/rtc.h | 15 +
rust/bindings/bindings_helper.h | 3 +
rust/helpers/device.c | 6 +
rust/helpers/helpers.c | 1 +
rust/helpers/rtc.c | 9 +
rust/kernel/amba.rs | 441 ++++++++++++++
rust/kernel/device.rs | 18 +-
rust/kernel/irq/request.rs | 17 +
rust/kernel/lib.rs | 4 +
rust/kernel/rtc.rs | 1008 +++++++++++++++++++++++++++++++
16 files changed, 2057 insertions(+), 14 deletions(-)
create mode 100644 drivers/rtc/rtc_pl031_rust.rs
create mode 100644 rust/helpers/rtc.c
create mode 100644 rust/kernel/amba.rs
create mode 100644 rust/kernel/rtc.rs
base-commit: 944aacb68baf7624ab8d277d0ebf07f025ca137c
--
2.43.0
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-binding: rtc: loongson: Document Loongson-2K0300 compatible
From: Binbin Zhou @ 2026-01-16 1:14 UTC (permalink / raw)
To: Rob Herring
Cc: Binbin Zhou, Huacai Chen, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, linux-rtc, Xiaochuang Mao, Huacai Chen,
Xuerui Wang, loongarch, devicetree, linux-mips, Keguang Zhang
In-Reply-To: <CAL_JsqJVD3o41Zch6fMY6s-qmyd9cQg6CJ+iya+3kdtuqvNMoA@mail.gmail.com>
Hi Rob:
Thanks for your reply.
On Fri, Jan 16, 2026 at 1:00 AM Rob Herring <robh@kernel.org> wrote:
>
> On Thu, Jan 15, 2026 at 1:39 AM Binbin Zhou <zhoubb.aaron@gmail.com> wrote:
> >
> > Hi Rob:
> >
> > Thanks for your reply.
> >
> > On Thu, Jan 15, 2026 at 4:58 AM Rob Herring <robh@kernel.org> wrote:
> > >
> > > On Wed, Jan 07, 2026 at 09:22:41AM +0800, Binbin Zhou wrote:
> > > > Hi Rob:
> > > >
> > > > Thanks for your review.
> > > >
> > > > On Wed, Jan 7, 2026 at 3:13 AM Rob Herring <robh@kernel.org> wrote:
> > > > >
> > > > > On Tue, Jan 06, 2026 at 09:33:32AM +0800, Binbin Zhou wrote:
> > > > > > Add "loongson,ls2k0300-rtc" dedicated compatible to represent the RTC
> > > > > > interface of the Loongson-2K0300 chip.
> > > > > >
> > > > > > Its hardware design is similar to that of the Loongson-1B, but it does
> > > > > > not support the alarm feature.
> > > > >
> > > > > But you are requiring the interrupt property for it? Isn't it no alarm
> > > > > feature means no interrupt?
> > > >
> > > > Yes, the `interrupts` attribute is not required without the alarm feature.
> > > >
> > > > But my judgment condition is `not contains` (added in patch-1[1]).
> > > > There are only a few SoCs on the Loongson platform that don't support
> > > > the RTC alarm feature, so I think `not contains` looks cleaner and
> > > > simpler.
> > >
> > > I should have said allowing rather than requiring.
> > >
> > > You are allowing (though not requiring) 'interrupts' for Loongson-1B and
> > > Loongson-2K0300. In patch 1, you made it required for other platforms
> > > which is an ABI change. That's fine if it was a mistake and is truly
> > > required.
> >
> > Emm, it's true that for the binding interface, Patch-1 is indeed an
> > ABI change, but it's more of a fixed patch.
> >
> > Throughout all existing Loongson DTS{i}, RTC nodes decide whether to
> > include the `interrupts` property or not based on the alarm feature.
> > Loongson-1c rtc nodes do not include the `interrupts` attribute [1],
> > while all other Loongson chip rtc nodes do [2].
> >
> > So, while this is an ABI change, I don't think it affects existing
> > Loongson DTS{i} rtc nodes. Also, it more accurately describes the
> > features of the corresponding RTC device.
> >
> > Therefore, I would like to clarify it in the Patch-1 commit message of
> > the next patch version and fix the error in the commit title:
> > dt-binding -> dt-bindings.
> >
> > How do you feel about that?
>
> That's fine, but you also need:
>
> else:
> properties:
> interrupts: false
>
> So that on the 2 platforms without an interrupt(alarm), 'interrupts'
> is not allowed.
>
> With that, you might as well just drop the 'not' and flip the 'then'
> and 'else' schemas around.
OK, I'll fall back to the writeup in the v1 patchset as follows:
if:
properties:
compatible:
contains:
enum:
- loongson,ls1c-rtc
- loongson,ls2k0300-rtc
then:
properties:
interrupts: false
>
> Rob
--
Thanks.
Binbin
^ permalink raw reply
* Re: [PATCH 00/27] clk: remove deprecated API divider_round_rate() and friends
From: Dmitry Baryshkov @ 2026-01-15 21:05 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney
Cc: linux-clk, linux-kernel, Chen Wang, Inochi Amaoto, sophgo,
Chen-Yu Tsai, Maxime Ripard, Jernej Skrabec, Samuel Holland,
linux-arm-kernel, linux-sunxi, Alexandre Belloni, linux-rtc,
Andreas Färber, Manivannan Sadhasivam, linux-actions,
Keguang Zhang, linux-mips, Taichi Sugaya, Takao Orito,
Jacky Huang, Shan-Chun Hung, Vladimir Zapolskiy,
Piotr Wojtaszczyk, Bjorn Andersson, linux-arm-msm, Orson Zhai,
Baolin Wang, Chunyan Zhang, Maxime Coquelin, Alexandre Torgue,
linux-stm32, Michal Simek, Rob Clark, Dmitry Baryshkov,
David Airlie, Simona Vetter, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, dri-devel, freedreno, Vinod Koul,
Neil Armstrong, linux-phy
In-Reply-To: <20260108-clk-divider-round-rate-v1-0-535a3ed73bf3@redhat.com>
On Thu, 08 Jan 2026 16:16:18 -0500, Brian Masney wrote:
> Here's a series that gets rid of the deprecated APIs
> divider_round_rate(), divider_round_rate_parent(), and
> divider_ro_round_rate_parent() since these functions are just wrappers
> for the determine_rate variant.
>
> Note that when I converted some of these drivers from round_rate to
> determine_rate, this was mistakenly converted to the following in some
> cases:
>
> [...]
Applied to msm-next, thanks!
[24/27] drm/msm/dsi_phy_14nm: convert from divider_round_rate() to divider_determine_rate()
https://gitlab.freedesktop.org/lumag/msm/-/commit/1d232f793d4d
Best regards,
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-binding: rtc: loongson: Document Loongson-2K0300 compatible
From: Rob Herring @ 2026-01-15 17:00 UTC (permalink / raw)
To: Binbin Zhou
Cc: Binbin Zhou, Huacai Chen, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, linux-rtc, Xiaochuang Mao, Huacai Chen,
Xuerui Wang, loongarch, devicetree, linux-mips, Keguang Zhang
In-Reply-To: <CAMpQs4+v=KhLW_Cru801p06vmpjJFotvyDfKBALg6mbwxFU5-A@mail.gmail.com>
On Thu, Jan 15, 2026 at 1:39 AM Binbin Zhou <zhoubb.aaron@gmail.com> wrote:
>
> Hi Rob:
>
> Thanks for your reply.
>
> On Thu, Jan 15, 2026 at 4:58 AM Rob Herring <robh@kernel.org> wrote:
> >
> > On Wed, Jan 07, 2026 at 09:22:41AM +0800, Binbin Zhou wrote:
> > > Hi Rob:
> > >
> > > Thanks for your review.
> > >
> > > On Wed, Jan 7, 2026 at 3:13 AM Rob Herring <robh@kernel.org> wrote:
> > > >
> > > > On Tue, Jan 06, 2026 at 09:33:32AM +0800, Binbin Zhou wrote:
> > > > > Add "loongson,ls2k0300-rtc" dedicated compatible to represent the RTC
> > > > > interface of the Loongson-2K0300 chip.
> > > > >
> > > > > Its hardware design is similar to that of the Loongson-1B, but it does
> > > > > not support the alarm feature.
> > > >
> > > > But you are requiring the interrupt property for it? Isn't it no alarm
> > > > feature means no interrupt?
> > >
> > > Yes, the `interrupts` attribute is not required without the alarm feature.
> > >
> > > But my judgment condition is `not contains` (added in patch-1[1]).
> > > There are only a few SoCs on the Loongson platform that don't support
> > > the RTC alarm feature, so I think `not contains` looks cleaner and
> > > simpler.
> >
> > I should have said allowing rather than requiring.
> >
> > You are allowing (though not requiring) 'interrupts' for Loongson-1B and
> > Loongson-2K0300. In patch 1, you made it required for other platforms
> > which is an ABI change. That's fine if it was a mistake and is truly
> > required.
>
> Emm, it's true that for the binding interface, Patch-1 is indeed an
> ABI change, but it's more of a fixed patch.
>
> Throughout all existing Loongson DTS{i}, RTC nodes decide whether to
> include the `interrupts` property or not based on the alarm feature.
> Loongson-1c rtc nodes do not include the `interrupts` attribute [1],
> while all other Loongson chip rtc nodes do [2].
>
> So, while this is an ABI change, I don't think it affects existing
> Loongson DTS{i} rtc nodes. Also, it more accurately describes the
> features of the corresponding RTC device.
>
> Therefore, I would like to clarify it in the Patch-1 commit message of
> the next patch version and fix the error in the commit title:
> dt-binding -> dt-bindings.
>
> How do you feel about that?
That's fine, but you also need:
else:
properties:
interrupts: false
So that on the 2 platforms without an interrupt(alarm), 'interrupts'
is not allowed.
With that, you might as well just drop the 'not' and flip the 'then'
and 'else' schemas around.
Rob
^ permalink raw reply
* [GIT PULL] Immutable branch between MFD, Clk, GPIO, Power, Regulator and RTC due for the v6.20 merge window
From: Lee Jones @ 2026-01-15 13:49 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Matti Vaittinen, Pavel Machek, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Sebastian Reichel, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Linus Walleij,
Bartosz Golaszewski, Alexandre Belloni, linux-leds, devicetree,
linux-kernel, linux-pm, linux-clk, linux-gpio, linux-rtc,
Andreas Kemnade
In-Reply-To: <cover.1765804226.git.mazziesaccount@gmail.com>
Enjoy!
The following changes since commit 8f0b4cce4481fb22653697cced8d0d04027cb1e8:
Linux 6.19-rc1 (2025-12-14 16:05:07 +1200)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd.git ib-mfd-clk-gpio-power-regulator-rtc-v6.20
for you to fetch changes up to e39951f8ad500648b9ab132f8042d6e47da441cf:
MAINTAINERS: Add ROHM BD72720 PMIC (2026-01-13 12:50:37 +0000)
----------------------------------------------------------------
Immutable branch between MFD, Clk, GPIO, Power, Regulator and RTC due for the v6.20 merge window
----------------------------------------------------------------
Matti Vaittinen (17):
dt-bindings: regulator: ROHM BD72720
dt-bindings: battery: Clarify trickle-charge
dt-bindings: battery: Add trickle-charge upper limit
dt-bindings: battery: Voltage drop properties
dt-bindings: mfd: ROHM BD72720
dt-bindings: leds: bd72720: Add BD72720
mfd: rohm-bd71828: Use regmap_reg_range()
mfd: rohm-bd71828: Use standard file header format
mfd: rohm-bd71828: Support ROHM BD72720
regulator: bd71828: rename IC specific entities
regulator: bd71828: Support ROHM BD72720
gpio: Support ROHM BD72720 gpios
clk: clk-bd718x7: Support BD72720 clk gate
rtc: bd70528: Support BD72720 rtc
power: supply: bd71828: Support wider register addresses
power: supply: bd71828-power: Support ROHM BD72720
MAINTAINERS: Add ROHM BD72720 PMIC
.../bindings/leds/rohm,bd71828-leds.yaml | 7 +-
.../devicetree/bindings/mfd/rohm,bd72720-pmic.yaml | 339 +++++++
.../devicetree/bindings/power/supply/battery.yaml | 33 +-
.../bindings/regulator/rohm,bd72720-regulator.yaml | 148 +++
MAINTAINERS | 2 +
drivers/clk/Kconfig | 4 +-
drivers/clk/clk-bd718x7.c | 10 +-
drivers/gpio/Kconfig | 9 +
drivers/gpio/Makefile | 1 +
drivers/gpio/gpio-bd72720.c | 281 ++++++
drivers/mfd/Kconfig | 18 +-
drivers/mfd/rohm-bd71828.c | 555 ++++++++++-
drivers/power/supply/bd71828-power.c | 160 ++-
drivers/regulator/Kconfig | 8 +-
drivers/regulator/bd71828-regulator.c | 1025 +++++++++++++++++++-
drivers/rtc/Kconfig | 3 +-
drivers/rtc/rtc-bd70528.c | 21 +-
include/linux/mfd/rohm-bd72720.h | 634 ++++++++++++
include/linux/mfd/rohm-generic.h | 1 +
19 files changed, 3127 insertions(+), 132 deletions(-)
create mode 100644 Documentation/devicetree/bindings/mfd/rohm,bd72720-pmic.yaml
create mode 100644 Documentation/devicetree/bindings/regulator/rohm,bd72720-regulator.yaml
create mode 100644 drivers/gpio/gpio-bd72720.c
create mode 100644 include/linux/mfd/rohm-bd72720.h
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v2 3/5] rtc: zynqmp: rework read_offset
From: Tomas Melin @ 2026-01-15 7:41 UTC (permalink / raw)
To: kernel test robot, Alexandre Belloni, Michal Simek
Cc: oe-kbuild-all, linux-rtc, linux-arm-kernel, linux-kernel
In-Reply-To: <202601150836.Yk8DcSZW-lkp@intel.com>
Hi,
On 15/01/2026 02:42, kernel test robot wrote:
>
> arm-linux-gnueabi-ld: drivers/spi/spi-amlogic-spifc-a4.o: in function `aml_sfc_set_bus_width':
> spi-amlogic-spifc-a4.c:(.text.aml_sfc_set_bus_width+0x8c): undefined reference to `__ffsdi2'
> arm-linux-gnueabi-ld: spi-amlogic-spifc-a4.c:(.text.aml_sfc_set_bus_width+0xac): undefined reference to `__ffsdi2'
> arm-linux-gnueabi-ld: spi-amlogic-spifc-a4.c:(.text.aml_sfc_set_bus_width+0xcc): undefined reference to `__ffsdi2'
> arm-linux-gnueabi-ld: drivers/rtc/rtc-zynqmp.o: in function `xlnx_rtc_read_offset':
>>> rtc-zynqmp.c:(.text.xlnx_rtc_read_offset+0xd0): undefined reference to `__aeabi_ldivmod'
>>> arm-linux-gnueabi-ld: rtc-zynqmp.c:(.text.xlnx_rtc_read_offset+0x15c): undefined reference to `__aeabi_ldivmod'
AFAIU this is related to compiling for arm 32 bit target. Is this error
relevant since this driver is for aarch64 zynqmp specifically? If so,
what would be correct way of fixing?
Thanks,
Tomas
>
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-binding: rtc: loongson: Document Loongson-2K0300 compatible
From: Binbin Zhou @ 2026-01-15 7:38 UTC (permalink / raw)
To: Rob Herring
Cc: Binbin Zhou, Huacai Chen, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, linux-rtc, Xiaochuang Mao, Huacai Chen,
Xuerui Wang, loongarch, devicetree, linux-mips, Keguang Zhang
In-Reply-To: <20260114205855.GA3190839-robh@kernel.org>
Hi Rob:
Thanks for your reply.
On Thu, Jan 15, 2026 at 4:58 AM Rob Herring <robh@kernel.org> wrote:
>
> On Wed, Jan 07, 2026 at 09:22:41AM +0800, Binbin Zhou wrote:
> > Hi Rob:
> >
> > Thanks for your review.
> >
> > On Wed, Jan 7, 2026 at 3:13 AM Rob Herring <robh@kernel.org> wrote:
> > >
> > > On Tue, Jan 06, 2026 at 09:33:32AM +0800, Binbin Zhou wrote:
> > > > Add "loongson,ls2k0300-rtc" dedicated compatible to represent the RTC
> > > > interface of the Loongson-2K0300 chip.
> > > >
> > > > Its hardware design is similar to that of the Loongson-1B, but it does
> > > > not support the alarm feature.
> > >
> > > But you are requiring the interrupt property for it? Isn't it no alarm
> > > feature means no interrupt?
> >
> > Yes, the `interrupts` attribute is not required without the alarm feature.
> >
> > But my judgment condition is `not contains` (added in patch-1[1]).
> > There are only a few SoCs on the Loongson platform that don't support
> > the RTC alarm feature, so I think `not contains` looks cleaner and
> > simpler.
>
> I should have said allowing rather than requiring.
>
> You are allowing (though not requiring) 'interrupts' for Loongson-1B and
> Loongson-2K0300. In patch 1, you made it required for other platforms
> which is an ABI change. That's fine if it was a mistake and is truly
> required.
Emm, it's true that for the binding interface, Patch-1 is indeed an
ABI change, but it's more of a fixed patch.
Throughout all existing Loongson DTS{i}, RTC nodes decide whether to
include the `interrupts` property or not based on the alarm feature.
Loongson-1c rtc nodes do not include the `interrupts` attribute [1],
while all other Loongson chip rtc nodes do [2].
So, while this is an ABI change, I don't think it affects existing
Loongson DTS{i} rtc nodes. Also, it more accurately describes the
features of the corresponding RTC device.
Therefore, I would like to clarify it in the Patch-1 commit message of
the next patch version and fix the error in the commit title:
dt-binding -> dt-bindings.
How do you feel about that?
[1]: https://elixir.bootlin.com/linux/v6.18/source/arch/mips/boot/dts/loongson/loongson1c.dtsi#L98
[2]: https://elixir.bootlin.com/linux/v6.18/source/arch/loongarch/boot/dts/loongson-2k0500.dtsi#L486
>
> Rob
--
Thanks.
Binbin
^ permalink raw reply
* Re: [PATCH v2 4/5] rtc: zynqmp: rework set_offset
From: Tomas Melin @ 2026-01-15 7:24 UTC (permalink / raw)
To: T, Harini, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <LV5PR12MB980481A1DC737957538A9924928FA@LV5PR12MB9804.namprd12.prod.outlook.com>
Hi,
On 14/01/2026 17:37, T, Harini wrote:
>> +++ b/drivers/rtc/rtc-zynqmp.c
>> @@ -208,13 +208,13 @@ static int xlnx_rtc_read_offset(struct device *dev,
>> long *offset) static int xlnx_rtc_set_offset(struct device *dev, long offset) {
>> struct xlnx_rtc_dev *xrtcdev = dev_get_drvdata(dev);
>> - unsigned long long rtc_ppb = RTC_PPB;
>> - unsigned int tick_mult = do_div(rtc_ppb, xrtcdev->freq);
>> - unsigned char fract_tick = 0;
>> + int max_tick, tick_mult, fract_offset, fract_part;
>> unsigned int calibval;
>> - short int max_tick;
>> - int fract_offset;
>> + int fract_data = 0;
>> + int freq = xrtcdev->freq;
> Please follow reverse XMAS tree style.
I can fix this with a follow up version.
Thanks,
Tomas
>>
>> + /* Tick to offset multiplier */
>> + tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, xrtcdev->freq);
>> if (offset < RTC_MIN_OFFSET || offset > RTC_MAX_OFFSET)
>> return -ERANGE;
>>
>> @@ -223,29 +223,22 @@ static int xlnx_rtc_set_offset(struct device *dev,
>> long offset)
>>
>> /* Number fractional ticks for given offset */
>> if (fract_offset) {
>> - if (fract_offset < 0) {
>> - fract_offset = fract_offset + tick_mult;
>> + fract_part = DIV_ROUND_UP(tick_mult, RTC_FR_MAX_TICKS);
>> + fract_data = fract_offset / fract_part;
>> + /* Subtract one from max_tick while adding fract_offset */
>> + if (fract_offset < 0 && fract_data) {
>> max_tick--;
>> - }
>> - if (fract_offset > (tick_mult / RTC_FR_MAX_TICKS)) {
>> - for (fract_tick = 1; fract_tick < 16; fract_tick++) {
>> - if (fract_offset <=
>> - (fract_tick *
>> - (tick_mult / RTC_FR_MAX_TICKS)))
>> - break;
>> - }
>> + fract_data += RTC_FR_MAX_TICKS;
>> }
>> }
>>
>> /* Zynqmp RTC uses second and fractional tick
>> * counters for compensation
>> */
>> - calibval = max_tick + RTC_CALIB_DEF;
>> -
>> - if (fract_tick)
>> - calibval |= RTC_FR_EN;
>> + calibval = max_tick + freq;
>>
>> - calibval |= (fract_tick << RTC_FR_DATSHIFT);
>> + if (fract_data)
>> + calibval |= (RTC_FR_EN | (fract_data <<
>> + RTC_FR_DATSHIFT));
>>
>> writel(calibval, (xrtcdev->reg_base + RTC_CALIB_WR));
>>
>>
>> --
>> 2.47.3
>>
>
> Thanks,
> Harini T
^ permalink raw reply
* Re: [PATCH v2 3/5] rtc: zynqmp: rework read_offset
From: kernel test robot @ 2026-01-15 0:42 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni, Michal Simek
Cc: oe-kbuild-all, linux-rtc, linux-arm-kernel, linux-kernel,
Tomas Melin
In-Reply-To: <20260108-zynqmp-rtc-updates-v2-3-864c161fa83d@vaisala.com>
Hi Tomas,
kernel test robot noticed the following build errors:
[auto build test ERROR on abelloni/rtc-next]
[also build test ERROR on xilinx-xlnx/master linus/master v6.19-rc5]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url: https://github.com/intel-lab-lkp/linux/commits/Tomas-Melin/rtc-zynqmp-check-calibration-max-value/20260108-223800
base: https://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git rtc-next
patch link: https://lore.kernel.org/r/20260108-zynqmp-rtc-updates-v2-3-864c161fa83d%40vaisala.com
patch subject: [PATCH v2 3/5] rtc: zynqmp: rework read_offset
config: arm-allyesconfig (https://download.01.org/0day-ci/archive/20260115/202601150836.Yk8DcSZW-lkp@intel.com/config)
compiler: arm-linux-gnueabi-gcc (GCC) 15.2.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260115/202601150836.Yk8DcSZW-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202601150836.Yk8DcSZW-lkp@intel.com/
All errors (new ones prefixed by >>):
arm-linux-gnueabi-ld: drivers/spi/spi-amlogic-spifc-a4.o: in function `aml_sfc_set_bus_width':
spi-amlogic-spifc-a4.c:(.text.aml_sfc_set_bus_width+0x8c): undefined reference to `__ffsdi2'
arm-linux-gnueabi-ld: spi-amlogic-spifc-a4.c:(.text.aml_sfc_set_bus_width+0xac): undefined reference to `__ffsdi2'
arm-linux-gnueabi-ld: spi-amlogic-spifc-a4.c:(.text.aml_sfc_set_bus_width+0xcc): undefined reference to `__ffsdi2'
arm-linux-gnueabi-ld: drivers/rtc/rtc-zynqmp.o: in function `xlnx_rtc_read_offset':
>> rtc-zynqmp.c:(.text.xlnx_rtc_read_offset+0xd0): undefined reference to `__aeabi_ldivmod'
>> arm-linux-gnueabi-ld: rtc-zynqmp.c:(.text.xlnx_rtc_read_offset+0x15c): undefined reference to `__aeabi_ldivmod'
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] rtc: migrate driver data to RTC device
From: Danilo Krummrich @ 2026-01-14 23:48 UTC (permalink / raw)
To: Ke Sun
Cc: Alexandre Belloni, Greg KH, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, linux-rtc, rust-for-linux, Alvin Sun
In-Reply-To: <f426f19d-a14c-4d9c-8587-2f7b4290024a@kylinos.cn>
On Thu Jan 15, 2026 at 12:23 AM CET, Ke Sun wrote:
> RTC ops callbacks receive struct device * as the first parameter.
> Traditionally this is rtc->dev.parent (the physical bus device), but Rust
> drivers store driver data on rtc->dev itself,
This is not only about Rust. Class device private data should be stored in the
driver_data field of the struct device embedded in the class device in general.
> so callbacks need &rtc->dev to access it.
Class device callbacks should just carry the class device itself, rather than
the embedded struct device.
> We considered switching all callbacks to use rtc->dev directly, but that would
> require modifying 182 RTC drivers and extensive testing/validation work.
I don't know if it's that bad, the change would be trivial. You just need to
repeat it pretty often. :) Tools like Coccinelle [1] can help a lot with such
refactorings.
> Instead, we propose an alternative approach:
>
> - Added RTC_OPS_USE_RTC_DEV flag (currently stored in rtc->features bitmap)
> - Created rtc_ops_dev() helper that returns &rtc->dev if flag is set,
> otherwise
> rtc->dev.parent. Default behavior (returning rtc->dev.parent) maintains
> backward compatibility
> - Updated all rtc->ops->callback call sites to use rtc_ops_dev(rtc)
Not sure if that intermediate step is needed, but it doesn't seem unreasonable
to me.
While eventually this is up to the RTC subsystem maintainer, from a driver-core
perspective this refactoring is encouraged:
Drivers should generally distinguish between stuff that is stored in the private
data of the bus device and private data of the class device, e.g. since they
have independent lifecycles and not all data might be relevant in all scopes.
Forcing drivers to also store the class device private data in the parent bus
device private data can be considered an anti-pattern.
[1] https://docs.kernel.org/dev-tools/coccinelle.html
^ permalink raw reply
* Re: [RFC PATCH v2 1/5] rtc: migrate driver data to RTC device
From: Ke Sun @ 2026-01-14 23:23 UTC (permalink / raw)
To: Alexandre Belloni, Danilo Krummrich, Greg KH
Cc: Miguel Ojeda, Boqun Feng, Gary Guo, Björn Roy Baron,
Benno Lossin, Andreas Hindborg, Alice Ryhl, Trevor Gross,
linux-rtc, rust-for-linux, Alvin Sun
In-Reply-To: <202601081401239bbfff9d@mail.local>
On 1/8/26 22:01, Alexandre Belloni wrote:
> On 08/01/2026 14:52:08+0100, Danilo Krummrich wrote:
>> On Thu Jan 8, 2026 at 2:45 PM CET, Ke Sun wrote:
>>> On 1/8/26 19:12, Danilo Krummrich wrote:
>>>> On Wed Jan 7, 2026 at 3:37 PM CET, Ke Sun wrote:
>>>>> diff --git a/drivers/rtc/dev.c b/drivers/rtc/dev.c
>>>>> index baf1a8ca8b2b1..0f62ba9342e3e 100644
>>>>> --- a/drivers/rtc/dev.c
>>>>> +++ b/drivers/rtc/dev.c
>>>>> @@ -410,7 +410,7 @@ static long rtc_dev_ioctl(struct file *file,
>>>>> }
>>>>> default:
>>>>> if (rtc->ops->param_get)
>>>>> - err = rtc->ops->param_get(rtc->dev.parent, ¶m);
>>>>> + err = rtc->ops->param_get(&rtc->dev, ¶m);
>>>> It would make more sense to just pass a struct rtc_device than the embedded
>>>> struct device in the RTC callbacks.
>>> I considered passing struct rtc_device directly, but chose &rtc->dev
>>> to minimize changes to existing drivers, since most callbacks use
>>> dev_get_drvdata() on the device parameter.
>> No, you should not expose the embedded base device. For accessing the private
>> data you should add helpers like rtc_get_drvdata(). This is what other
>> subsystems do as well, e.g. [1].
>>
>> [1] https://elixir.bootlin.com/linux/v6.18.3/source/include/linux/i2c.h#L371
> This is not a correct example as i2c is a bus, just like amba is...
> Actually, I don't think the rework is necessary at all or this would
> mean we need to rewor most of our existing subsystems.
RTC ops callbacks receive struct device * as the first parameter.
Traditionally this is rtc->dev.parent
(the physical bus device), but Rust drivers store driver data on
rtc->dev itself, so callbacks need &rtc->dev
to access it. We considered switching all callbacks to use rtc->dev
directly, but that would require modifying
182 RTC drivers and extensive testing/validation work. Instead, we
propose an alternative approach:
- Added RTC_OPS_USE_RTC_DEV flag (currently stored in rtc->features bitmap)
- Created rtc_ops_dev() helper that returns &rtc->dev if flag is set,
otherwise
rtc->dev.parent. Default behavior (returning rtc->dev.parent) maintains
backward compatibility
- Updated all rtc->ops->callback call sites to use rtc_ops_dev(rtc)
Best regard,
Ke Sun
>
>
^ permalink raw reply
* Re: [PATCH v2 2/3] dt-binding: rtc: loongson: Document Loongson-2K0300 compatible
From: Rob Herring @ 2026-01-14 20:58 UTC (permalink / raw)
To: Binbin Zhou
Cc: Binbin Zhou, Huacai Chen, Krzysztof Kozlowski, Conor Dooley,
Alexandre Belloni, linux-rtc, Xiaochuang Mao, Huacai Chen,
Xuerui Wang, loongarch, devicetree, linux-mips, Keguang Zhang
In-Reply-To: <CAMpQs4LpKSLGKySmzHeysS3x78inUQy9DF4dShneNymDvAi4Ew@mail.gmail.com>
On Wed, Jan 07, 2026 at 09:22:41AM +0800, Binbin Zhou wrote:
> Hi Rob:
>
> Thanks for your review.
>
> On Wed, Jan 7, 2026 at 3:13 AM Rob Herring <robh@kernel.org> wrote:
> >
> > On Tue, Jan 06, 2026 at 09:33:32AM +0800, Binbin Zhou wrote:
> > > Add "loongson,ls2k0300-rtc" dedicated compatible to represent the RTC
> > > interface of the Loongson-2K0300 chip.
> > >
> > > Its hardware design is similar to that of the Loongson-1B, but it does
> > > not support the alarm feature.
> >
> > But you are requiring the interrupt property for it? Isn't it no alarm
> > feature means no interrupt?
>
> Yes, the `interrupts` attribute is not required without the alarm feature.
>
> But my judgment condition is `not contains` (added in patch-1[1]).
> There are only a few SoCs on the Loongson platform that don't support
> the RTC alarm feature, so I think `not contains` looks cleaner and
> simpler.
I should have said allowing rather than requiring.
You are allowing (though not requiring) 'interrupts' for Loongson-1B and
Loongson-2K0300. In patch 1, you made it required for other platforms
which is an ABI change. That's fine if it was a mistake and is truly
required.
Rob
^ permalink raw reply
* RE: [PATCH v2 0/5] rtc: zynqmp: fixes for read and set offset
From: T, Harini @ 2026-01-14 15:44 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260108-zynqmp-rtc-updates-v2-0-864c161fa83d@vaisala.com>
[Public]
Write +34335 ppb → Read +34335 ppb (0 ppb error)
Write -34335 ppb → Read -34326 ppb (9 ppb error)
Asymmetry: 9 ppb
The 9 ppb error is acceptable as it's well within the hardware's ±1908 ppb
quantization limit (4-bit fractional resolution)
Tested-by: Harini T <harini.t@amd.com>
Thanks,
Harini T
> -----Original Message-----
> From: Tomas Melin <tomas.melin@vaisala.com>
> Sent: Thursday, January 8, 2026 6:21 PM
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
> <michal.simek@amd.com>
> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
> Subject: [PATCH v2 0/5] rtc: zynqmp: fixes for read and set offset
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> Add improvements for read and set offset functions.
> The basic functionality is still the same, but offset correction values are now
> updated to match with expected.
>
> The RTC calibration value operates with full ticks, and fractional ticks which
> are a 1/16 of a full tick.
> The 16 lowest bits in the calibration registers are for the full ticks and value
> matches the external oscillator in Hz. Through that, the maximum and
> minimum offset values can be calculated dynamically, as they depend on the
> input frequency used.
>
> For docs on the calibration register, see https://docs.amd.com/r/en-
> US/ug1087-zynq-ultrascale-registers/CALIB_READ-RTC-Register
>
> Due to rounding errors (different number of fract ticks), offset readback will
> differ slightly depending on if the offset is negative or positive.
>
> For example
> $ echo 34335 > offset
> $ cat offset
> 34335
> $ echo -34335 > offset
> $ cat offset
> -34326
>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> Changes in v2:
> - Add commit introducing check for calibration value overflow
> - Update comments
> - Align data types across set and read
> - Rename fract_tick as fract_data conforming to data sheet
> - Further improve on set offset calculation logic
> - Link to v1: https://lore.kernel.org/r/20251201-zynqmp-rtc-updates-v1-0-
> 33875c1e385b@vaisala.com
>
> ---
> Tomas Melin (5):
> rtc: zynqmp: correct frequency value
> rtc: zynqmp: check calibration max value
> rtc: zynqmp: rework read_offset
> rtc: zynqmp: rework set_offset
> rtc: zynqmp: use dynamic max and min offset ranges
>
> drivers/rtc/rtc-zynqmp.c | 74 ++++++++++++++++++++++++++---------------------
> -
> 1 file changed, 40 insertions(+), 34 deletions(-)
> ---
> base-commit: cd635e33b0113287c94021be53d2a7c61a1614e9
> change-id: 20251201-zynqmp-rtc-updates-d260364cc01b
>
> Best regards,
> --
> Tomas Melin <tomas.melin@vaisala.com>
>
^ permalink raw reply
* RE: [PATCH v2 5/5] rtc: zynqmp: use dynamic max and min offset ranges
From: T, Harini @ 2026-01-14 15:37 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260108-zynqmp-rtc-updates-v2-5-864c161fa83d@vaisala.com>
[Public]
Reviewed-by: Harini T <harini.t@amd.com>
Thanks,
Harini T
> -----Original Message-----
> From: Tomas Melin <tomas.melin@vaisala.com>
> Sent: Thursday, January 8, 2026 6:21 PM
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
> <michal.simek@amd.com>
> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
> Subject: [PATCH v2 5/5] rtc: zynqmp: use dynamic max and min offset ranges
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> Maximum and minimum offsets in ppb that can be handled are dependent
> on the rtc clock frequency and what can fit in the 16-bit register field.
>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> drivers/rtc/rtc-zynqmp.c | 8 +++-----
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
> d15c256e7ae56058ddc38849af6424cd29b8965e..f508c61f4046e906d9569cc7
> 79a1360474a85fd2 100644
> --- a/drivers/rtc/rtc-zynqmp.c
> +++ b/drivers/rtc/rtc-zynqmp.c
> @@ -44,8 +44,6 @@
> #define RTC_FR_MASK 0xF0000
> #define RTC_FR_MAX_TICKS 16
> #define RTC_PPB 1000000000LL
> -#define RTC_MIN_OFFSET -32768000
> -#define RTC_MAX_OFFSET 32767000
>
> struct xlnx_rtc_dev {
> struct rtc_device *rtc;
> @@ -215,12 +213,12 @@ static int xlnx_rtc_set_offset(struct device *dev,
> long offset)
>
> /* Tick to offset multiplier */
> tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, xrtcdev->freq);
> - if (offset < RTC_MIN_OFFSET || offset > RTC_MAX_OFFSET)
> - return -ERANGE;
> -
> /* Number ticks for given offset */
> max_tick = div_s64_rem(offset, tick_mult, &fract_offset);
>
> + if (freq + max_tick > RTC_TICK_MASK || (freq + max_tick < 1))
> + return -ERANGE;
> +
> /* Number fractional ticks for given offset */
> if (fract_offset) {
> fract_part = DIV_ROUND_UP(tick_mult, RTC_FR_MAX_TICKS);
>
> --
> 2.47.3
>
^ permalink raw reply
* RE: [PATCH v2 4/5] rtc: zynqmp: rework set_offset
From: T, Harini @ 2026-01-14 15:37 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260108-zynqmp-rtc-updates-v2-4-864c161fa83d@vaisala.com>
[Public]
Hi,
> -----Original Message-----
> From: Tomas Melin <tomas.melin@vaisala.com>
> Sent: Thursday, January 8, 2026 6:21 PM
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
> <michal.simek@amd.com>
> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
> Subject: [PATCH v2 4/5] rtc: zynqmp: rework set_offset
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> set_offset was using remainder of do_div as tick_mult which resulted in
> wrong offset. Calibration value also assumed builtin calibration default.
> Update fract_offset to correctly calculate the value for negative offset and
> replace the for loop with division.
>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> drivers/rtc/rtc-zynqmp.c | 33 +++++++++++++--------------------
> 1 file changed, 13 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
> 6740c3aed1897d4b50a02c4823a746d9c2ae2655..d15c256e7ae56058ddc3884
> 9af6424cd29b8965e 100644
> --- a/drivers/rtc/rtc-zynqmp.c
> +++ b/drivers/rtc/rtc-zynqmp.c
> @@ -208,13 +208,13 @@ static int xlnx_rtc_read_offset(struct device *dev,
> long *offset) static int xlnx_rtc_set_offset(struct device *dev, long offset) {
> struct xlnx_rtc_dev *xrtcdev = dev_get_drvdata(dev);
> - unsigned long long rtc_ppb = RTC_PPB;
> - unsigned int tick_mult = do_div(rtc_ppb, xrtcdev->freq);
> - unsigned char fract_tick = 0;
> + int max_tick, tick_mult, fract_offset, fract_part;
> unsigned int calibval;
> - short int max_tick;
> - int fract_offset;
> + int fract_data = 0;
> + int freq = xrtcdev->freq;
Please follow reverse XMAS tree style.
>
> + /* Tick to offset multiplier */
> + tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, xrtcdev->freq);
> if (offset < RTC_MIN_OFFSET || offset > RTC_MAX_OFFSET)
> return -ERANGE;
>
> @@ -223,29 +223,22 @@ static int xlnx_rtc_set_offset(struct device *dev,
> long offset)
>
> /* Number fractional ticks for given offset */
> if (fract_offset) {
> - if (fract_offset < 0) {
> - fract_offset = fract_offset + tick_mult;
> + fract_part = DIV_ROUND_UP(tick_mult, RTC_FR_MAX_TICKS);
> + fract_data = fract_offset / fract_part;
> + /* Subtract one from max_tick while adding fract_offset */
> + if (fract_offset < 0 && fract_data) {
> max_tick--;
> - }
> - if (fract_offset > (tick_mult / RTC_FR_MAX_TICKS)) {
> - for (fract_tick = 1; fract_tick < 16; fract_tick++) {
> - if (fract_offset <=
> - (fract_tick *
> - (tick_mult / RTC_FR_MAX_TICKS)))
> - break;
> - }
> + fract_data += RTC_FR_MAX_TICKS;
> }
> }
>
> /* Zynqmp RTC uses second and fractional tick
> * counters for compensation
> */
> - calibval = max_tick + RTC_CALIB_DEF;
> -
> - if (fract_tick)
> - calibval |= RTC_FR_EN;
> + calibval = max_tick + freq;
>
> - calibval |= (fract_tick << RTC_FR_DATSHIFT);
> + if (fract_data)
> + calibval |= (RTC_FR_EN | (fract_data <<
> + RTC_FR_DATSHIFT));
>
> writel(calibval, (xrtcdev->reg_base + RTC_CALIB_WR));
>
>
> --
> 2.47.3
>
Thanks,
Harini T
^ permalink raw reply
* RE: [PATCH v2 3/5] rtc: zynqmp: rework read_offset
From: T, Harini @ 2026-01-14 15:36 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260108-zynqmp-rtc-updates-v2-3-864c161fa83d@vaisala.com>
[Public]
Reviewed-by: Harini T <harini.t@amd.com>
Thanks,
Harini T
> -----Original Message-----
> From: Tomas Melin <tomas.melin@vaisala.com>
> Sent: Thursday, January 8, 2026 6:21 PM
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
> <michal.simek@amd.com>
> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
> Subject: [PATCH v2 3/5] rtc: zynqmp: rework read_offset
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> read_offset() was using static frequency for determining the tick offset. It was
> also using remainder from do_div() operation as tick_mult value which
> caused the offset to be incorrect.
>
> At the same time, rework function to improve readability.
> It is worth noting, that due to rounding errors, the offset readback will differ
> slightly for positive and negative calibration values.
>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> drivers/rtc/rtc-zynqmp.c | 25 ++++++++++++++++---------
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
> caacce3725e2ef3803ea42d40e77ceaeb7d7b914..6740c3aed1897d4b50a02c4
> 823a746d9c2ae2655 100644
> --- a/drivers/rtc/rtc-zynqmp.c
> +++ b/drivers/rtc/rtc-zynqmp.c
> @@ -178,21 +178,28 @@ static void xlnx_init_rtc(struct xlnx_rtc_dev
> *xrtcdev) static int xlnx_rtc_read_offset(struct device *dev, long *offset) {
> struct xlnx_rtc_dev *xrtcdev = dev_get_drvdata(dev);
> - unsigned long long rtc_ppb = RTC_PPB;
> - unsigned int tick_mult = do_div(rtc_ppb, xrtcdev->freq);
> - unsigned int calibval;
> + unsigned int calibval, fract_data, fract_part;
> + int freq = xrtcdev->freq;
> + int max_tick, tick_mult;
> long offset_val;
>
> + /* Tick to offset multiplier */
> + tick_mult = DIV_ROUND_CLOSEST(RTC_PPB, freq);
> +
> calibval = readl(xrtcdev->reg_base + RTC_CALIB_RD);
> /* Offset with seconds ticks */
> - offset_val = calibval & RTC_TICK_MASK;
> - offset_val = offset_val - RTC_CALIB_DEF;
> - offset_val = offset_val * tick_mult;
> + max_tick = calibval & RTC_TICK_MASK;
> + offset_val = max_tick - freq;
> + /* Convert to ppb */
> + offset_val *= tick_mult;
>
> /* Offset with fractional ticks */
> - if (calibval & RTC_FR_EN)
> - offset_val += ((calibval & RTC_FR_MASK) >> RTC_FR_DATSHIFT)
> - * (tick_mult / RTC_FR_MAX_TICKS);
> + if (calibval & RTC_FR_EN) {
> + fract_data = (calibval & RTC_FR_MASK) >> RTC_FR_DATSHIFT;
> + fract_part = DIV_ROUND_UP(tick_mult, RTC_FR_MAX_TICKS);
> + offset_val += (fract_part * fract_data);
> + }
> +
> *offset = offset_val;
>
> return 0;
>
> --
> 2.47.3
>
^ permalink raw reply
* RE: [PATCH v2 2/5] rtc: zynqmp: check calibration max value
From: T, Harini @ 2026-01-14 15:35 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260108-zynqmp-rtc-updates-v2-2-864c161fa83d@vaisala.com>
[Public]
Reviewed-by: Harini T <harini.t@amd.com>
Thanks,
Harini T
> -----Original Message-----
> From: Tomas Melin <tomas.melin@vaisala.com>
> Sent: Thursday, January 8, 2026 6:21 PM
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
> <michal.simek@amd.com>
> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
> Subject: [PATCH v2 2/5] rtc: zynqmp: check calibration max value
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> Enable check to not overflow the calibration max value.
>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> drivers/rtc/rtc-zynqmp.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
> 856bc1678e7d31144f320ae9f75fc58c742a2a64..caacce3725e2ef3803ea42d40
> e77ceaeb7d7b914 100644
> --- a/drivers/rtc/rtc-zynqmp.c
> +++ b/drivers/rtc/rtc-zynqmp.c
> @@ -349,6 +349,11 @@ static int xlnx_rtc_probe(struct platform_device
> *pdev)
> xrtcdev->freq--;
> }
>
> + if (xrtcdev->freq > RTC_TICK_MASK) {
> + dev_err(&pdev->dev, "Invalid RTC calibration value\n");
> + return -EINVAL;
> + }
> +
> ret = readl(xrtcdev->reg_base + RTC_CALIB_RD);
> if (!ret)
> writel(xrtcdev->freq, (xrtcdev->reg_base + RTC_CALIB_WR));
>
> --
> 2.47.3
>
^ permalink raw reply
* RE: [PATCH v2 1/5] rtc: zynqmp: correct frequency value
From: T, Harini @ 2026-01-14 15:35 UTC (permalink / raw)
To: Tomas Melin, Alexandre Belloni, Simek, Michal
Cc: linux-rtc@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
In-Reply-To: <20260108-zynqmp-rtc-updates-v2-1-864c161fa83d@vaisala.com>
[Public]
Reviewed-by: Harini T <harini.t@amd.com>
Thanks,
Harini T
> -----Original Message-----
> From: Tomas Melin <tomas.melin@vaisala.com>
> Sent: Thursday, January 8, 2026 6:21 PM
> To: Alexandre Belloni <alexandre.belloni@bootlin.com>; Simek, Michal
> <michal.simek@amd.com>
> Cc: linux-rtc@vger.kernel.org; linux-arm-kernel@lists.infradead.org; linux-
> kernel@vger.kernel.org; Tomas Melin <tomas.melin@vaisala.com>
> Subject: [PATCH v2 1/5] rtc: zynqmp: correct frequency value
>
> Caution: This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
> Fix calibration value in case a clock reference is provided.
> The actual calibration value written into register is frequency - 1.
>
> Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
> ---
> drivers/rtc/rtc-zynqmp.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/rtc/rtc-zynqmp.c b/drivers/rtc/rtc-zynqmp.c index
> 3baa2b481d9f2008750046005283b98a0d546c5c..856bc1678e7d31144f320ae
> 9f75fc58c742a2a64 100644
> --- a/drivers/rtc/rtc-zynqmp.c
> +++ b/drivers/rtc/rtc-zynqmp.c
> @@ -345,7 +345,10 @@ static int xlnx_rtc_probe(struct platform_device
> *pdev)
> &xrtcdev->freq);
> if (ret)
> xrtcdev->freq = RTC_CALIB_DEF;
> + } else {
> + xrtcdev->freq--;
> }
> +
> ret = readl(xrtcdev->reg_base + RTC_CALIB_RD);
> if (!ret)
> writel(xrtcdev->freq, (xrtcdev->reg_base + RTC_CALIB_WR));
>
> --
> 2.47.3
>
^ permalink raw reply
* Re: [PATCH v5 2/3] mfd: simple-mfd-i2c: add default value
From: Troy Mitchell @ 2026-01-14 7:40 UTC (permalink / raw)
To: Lee Jones, Troy Mitchell
Cc: Yixun Lan, Alex Elder, Andi Shyti, Alexandre Belloni,
Liam Girdwood, Mark Brown, linux-kernel, linux-riscv, spacemit,
linux-i2c, linux-rtc
In-Reply-To: <20260113124241.GB2842980@google.com>
On Tue Jan 13, 2026 at 8:42 PM CST, Lee Jones wrote:
> On Thu, 08 Jan 2026, Troy Mitchell wrote:
>
>> The default value of the P1 sub-device depends on the value
>> of P1, so P1 should have a default value here.
>>
>> Acked-by: Alex Elder <elder@riscstar.com>
>> Signed-off-by: Troy Mitchell <troy.mitchell@linux.spacemit.com>
>> ---
>> Change log in v5:
>> - nothing
>> - Link to v4: https://lore.kernel.org/all/20251225-p1-kconfig-fix-v4-2-44b6728117c1@linux.spacemit.com/
>>
>> Change log in v4:
>> - default m if ARCH_SPACEMIT instead of default ARCH_SPACEMIT
>> - Link to v3: https://lore.kernel.org/all/20251118-p1-kconfig-fix-v3-4-8839c5ac5db3@linux.spacemit.com/
>> ---
>> drivers/mfd/Kconfig | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
>> index aace5766b38aa5e46e32a8a7b42eea238159fbcf..c757bc365029dc794c658fc5b10084a0f29ac9b6 100644
>> --- a/drivers/mfd/Kconfig
>> +++ b/drivers/mfd/Kconfig
>> @@ -1276,6 +1276,7 @@ config MFD_SPACEMIT_P1
>> depends on ARCH_SPACEMIT || COMPILE_TEST
>> depends on I2C
>> select MFD_SIMPLE_MFD_I2C
>> + default m if ARCH_SPACEMIT
>> help
>> This option supports the I2C-based SpacemiT P1 PMIC, which
>> contains regulators, a power switch, GPIOs, an RTC, and more.
>
> I already applied v4.
Apologies, I missed this.
I will remove the patch in the next version. Thank you for your work.
- Troy
^ permalink raw reply
* Re: [PATCH RESEND v6 00/17] Support ROHM BD72720 PMIC
From: Sebastian Reichel @ 2026-01-14 0:26 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Lee Jones, Matti Vaittinen, Pavel Machek, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Linus Walleij,
Bartosz Golaszewski, Alexandre Belloni, linux-leds, devicetree,
linux-kernel, linux-pm, linux-clk, linux-gpio, linux-rtc,
Andreas Kemnade
In-Reply-To: <ebb14cef-9927-4211-94ef-2f209abeb406@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1621 bytes --]
Hi,
On Mon, Jan 12, 2026 at 02:04:47PM +0200, Matti Vaittinen wrote:
> On 12/01/2026 02:53, Sebastian Reichel wrote:
> > On Fri, Jan 09, 2026 at 09:38:31AM +0000, Lee Jones wrote:
> > > [...]
> > > > > The MFD parts LGTM.
> > > >
> > > > Thanks Lee!
> > > >
> > > > > What Acks are you waiting on? What's the merge strategy?
> > > >
> > > > I think everything else has been acked by maintainers, except the
> > > > power-supply parts. I think those have only been looked at by Andreas and
> > > > Linus W. Haven't heard anything from Sebastian :(
> >
> > Yes, I'm lacking behind quite a bit, sorry for that.
> >
> > > > I would love to see the patches 1 - 14 and 17 to be merged (via MFD?). I
> > > > could then re-spin the 15 and 16 to limited audience as I hope Sebastian had
> > > > time to take a look at them. However, I don't think any of the other patches
> > > > in the series depend on the last .
> >
> > Sounds good to me.
>
> Ah. Since the 15/17:
> "[PATCH RESEND v6 15/17] power: supply: bd71828: Support wider register
> addresses" was now acked by Sebastian, then it can also go via MFD?
>
> Also, if it is Ok to address all the "dev_err() + return ERRNO" => "return
> dev_err_probe(,ERRNO,)" conversions in a follow-up, then I guess the whole
> series, including 16/17 is good to go? If this is the case, please just let
> me know and I'll send the follow-up. Otherwise, I will re-spin the 16/17 and
> add a new patch for the remaining "dev_err() + return ERRNO" => "return
> dev_err_probe(,ERRNO,)" case(s)
That's fine with me.
Greetings,
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] rtc: add BSM flags descriptions
From: Hugo Villeneuve @ 2026-01-13 15:04 UTC (permalink / raw)
To: Hugo Villeneuve
Cc: Alexandre Belloni, Hugo Villeneuve, linux-rtc, linux-kernel
In-Reply-To: <20250721153332.2177134-1-hugo@hugovil.com>
On Mon, 21 Jul 2025 11:33:31 -0400
Hugo Villeneuve <hugo@hugovil.com> wrote:
> From: Hugo Villeneuve <hvilleneuve@dimonoff.com>
>
> It is hard to decipher what the RTC BSM flags mean, so add
> meaningful descriptions.
>
> Signed-off-by: Hugo Villeneuve <hvilleneuve@dimonoff.com>
> ---
> include/uapi/linux/rtc.h | 11 ++++++++---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/include/uapi/linux/rtc.h b/include/uapi/linux/rtc.h
> index 97aca4503a6a..da65130e316d 100644
> --- a/include/uapi/linux/rtc.h
> +++ b/include/uapi/linux/rtc.h
> @@ -141,10 +141,15 @@ struct rtc_param {
> #define RTC_PARAM_CORRECTION 1
> #define RTC_PARAM_BACKUP_SWITCH_MODE 2
>
> +/* Backup switch mode */
> #define RTC_BSM_DISABLED 0
> -#define RTC_BSM_DIRECT 1
> -#define RTC_BSM_LEVEL 2
> -#define RTC_BSM_STANDBY 3
> +#define RTC_BSM_DIRECT 1 /* Switch if Vbackup > Vdd */
> +#define RTC_BSM_LEVEL 2 /* Switch based on a threshold, usually with an hysteresis */
> +#define RTC_BSM_STANDBY 3 /*
> + * Switch if Vdd > Vbackup.
> + * Useful to ensure the RTC doesn't draw any
> + * power until the device is first powered on.
> + */
>
> #define RTC_MAX_FREQ 8192
Ping?
>
>
> base-commit: 0bafe291cb429d39b5ff70bcf7b2f3ab026dcb02
> --
> 2.39.5
>
>
--
Hugo Villeneuve
^ permalink raw reply
* [PATCH v3 3/3] mfd: sec: drop now unused struct sec_pmic_dev::irq_data
From: André Draszik @ 2026-01-13 14:03 UTC (permalink / raw)
To: Krzysztof Kozlowski, Lee Jones, Alexandre Belloni
Cc: Peter Griffin, Tudor Ambarus, Will McVicker, Juan Yescas,
Douglas Anderson, kernel-team, Kaustabh Chakraborty, linux-kernel,
linux-samsung-soc, linux-rtc, André Draszik
In-Reply-To: <20260113-s5m-alarm-v3-0-855a19db1277@linaro.org>
This was used only to allow the s5m RTC driver to deal with the alarm
IRQ. That driver now uses a different approach to acquire that IRQ, and
::irq_data doesn't need to be kept around anymore.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
v3:
- make s2mpg1x_add_chained_irq_chip() specific to PMIC irq chip (Lee),
and rename to s2mpg1x_add_chained_pmic() (Andre)
v2:
- return struct regmap_irq_chip_data * in sec_irq_init() (Lee)
---
drivers/mfd/sec-common.c | 9 +++---
drivers/mfd/sec-core.h | 2 +-
drivers/mfd/sec-irq.c | 64 ++++++++++++++++++----------------------
include/linux/mfd/samsung/core.h | 1 -
4 files changed, 35 insertions(+), 41 deletions(-)
diff --git a/drivers/mfd/sec-common.c b/drivers/mfd/sec-common.c
index 77370db52a7ba81234136b29f85892f4b197f429..0021f9ae8484fd0afc2e47c813a953c91fa38546 100644
--- a/drivers/mfd/sec-common.c
+++ b/drivers/mfd/sec-common.c
@@ -163,6 +163,7 @@ sec_pmic_parse_dt_pdata(struct device *dev)
int sec_pmic_probe(struct device *dev, int device_type, unsigned int irq,
struct regmap *regmap, struct i2c_client *client)
{
+ struct regmap_irq_chip_data *irq_data;
struct sec_platform_data *pdata;
const struct mfd_cell *sec_devs;
struct sec_pmic_dev *sec_pmic;
@@ -187,9 +188,9 @@ int sec_pmic_probe(struct device *dev, int device_type, unsigned int irq,
sec_pmic->pdata = pdata;
- ret = sec_irq_init(sec_pmic);
- if (ret)
- return ret;
+ irq_data = sec_irq_init(sec_pmic);
+ if (IS_ERR(irq_data))
+ return PTR_ERR(irq_data);
pm_runtime_set_active(sec_pmic->dev);
@@ -240,7 +241,7 @@ int sec_pmic_probe(struct device *dev, int device_type, unsigned int irq,
sec_pmic->device_type);
}
ret = devm_mfd_add_devices(sec_pmic->dev, -1, sec_devs, num_sec_devs,
- NULL, 0, regmap_irq_get_domain(sec_pmic->irq_data));
+ NULL, 0, regmap_irq_get_domain(irq_data));
if (ret)
return ret;
diff --git a/drivers/mfd/sec-core.h b/drivers/mfd/sec-core.h
index 92c7558ab8b0de44a52e028eeb7998e38358cb4c..8d85c70c232612d1f7e5fb61b2acd25bf03a62e0 100644
--- a/drivers/mfd/sec-core.h
+++ b/drivers/mfd/sec-core.h
@@ -18,6 +18,6 @@ int sec_pmic_probe(struct device *dev, int device_type, unsigned int irq,
struct regmap *regmap, struct i2c_client *client);
void sec_pmic_shutdown(struct device *dev);
-int sec_irq_init(struct sec_pmic_dev *sec_pmic);
+struct regmap_irq_chip_data *sec_irq_init(struct sec_pmic_dev *sec_pmic);
#endif /* __SEC_CORE_INT_H */
diff --git a/drivers/mfd/sec-irq.c b/drivers/mfd/sec-irq.c
index 74ac70002d1fc54c7eeb78cfc21b6117a3e14b03..e0dd122e8fe5ad86ae1e97dc1a4b1605d1813a64 100644
--- a/drivers/mfd/sec-irq.c
+++ b/drivers/mfd/sec-irq.c
@@ -268,26 +268,28 @@ static const struct regmap_irq_chip s5m8767_irq_chip = {
.ack_base = S5M8767_REG_INT1,
};
-static int s2mpg1x_add_chained_irq_chip(struct device *dev, struct regmap *regmap, int pirq,
- struct regmap_irq_chip_data *parent,
- const struct regmap_irq_chip *chip,
- struct regmap_irq_chip_data **data)
+static struct regmap_irq_chip_data *
+s2mpg1x_add_chained_pmic(struct sec_pmic_dev *sec_pmic, int pirq,
+ struct regmap_irq_chip_data *parent, const struct regmap_irq_chip *chip)
{
+ struct device *dev = sec_pmic->dev;
+ struct regmap_irq_chip_data *data;
int irq, ret;
irq = regmap_irq_get_virq(parent, pirq);
if (irq < 0)
- return dev_err_probe(dev, irq, "Failed to get parent vIRQ(%d) for chip %s\n", pirq,
- chip->name);
+ return dev_err_ptr_probe(dev, irq, "Failed to get parent vIRQ(%d) for chip %s\n",
+ pirq, chip->name);
- ret = devm_regmap_add_irq_chip(dev, regmap, irq, IRQF_ONESHOT | IRQF_SHARED, 0, chip, data);
+ ret = devm_regmap_add_irq_chip(dev, sec_pmic->regmap_pmic, irq,
+ IRQF_ONESHOT | IRQF_SHARED, 0, chip, &data);
if (ret)
- return dev_err_probe(dev, ret, "Failed to add %s IRQ chip\n", chip->name);
+ return dev_err_ptr_probe(dev, ret, "Failed to add %s IRQ chip\n", chip->name);
- return 0;
+ return data;
}
-static int sec_irq_init_s2mpg1x(struct sec_pmic_dev *sec_pmic)
+static struct regmap_irq_chip_data *sec_irq_init_s2mpg1x(struct sec_pmic_dev *sec_pmic)
{
const struct regmap_irq_chip *irq_chip, *chained_irq_chip;
struct regmap_irq_chip_data *irq_data;
@@ -302,27 +304,27 @@ static int sec_irq_init_s2mpg1x(struct sec_pmic_dev *sec_pmic)
chained_pirq = S2MPG10_COMMON_IRQ_PMIC;
break;
default:
- return dev_err_probe(sec_pmic->dev, -EINVAL, "Unsupported device type %d\n",
- sec_pmic->device_type);
+ return dev_err_ptr_probe(sec_pmic->dev, -EINVAL, "Unsupported device type %d\n",
+ sec_pmic->device_type);
}
regmap_common = dev_get_regmap(sec_pmic->dev, "common");
if (!regmap_common)
- return dev_err_probe(sec_pmic->dev, -EINVAL, "No 'common' regmap %d\n",
- sec_pmic->device_type);
+ return dev_err_ptr_probe(sec_pmic->dev, -EINVAL, "No 'common' regmap %d\n",
+ sec_pmic->device_type);
ret = devm_regmap_add_irq_chip(sec_pmic->dev, regmap_common, sec_pmic->irq, IRQF_ONESHOT, 0,
irq_chip, &irq_data);
if (ret)
- return dev_err_probe(sec_pmic->dev, ret, "Failed to add %s IRQ chip\n",
- irq_chip->name);
+ return dev_err_ptr_probe(sec_pmic->dev, ret, "Failed to add %s IRQ chip\n",
+ irq_chip->name);
- return s2mpg1x_add_chained_irq_chip(sec_pmic->dev, sec_pmic->regmap_pmic, chained_pirq,
- irq_data, chained_irq_chip, &sec_pmic->irq_data);
+ return s2mpg1x_add_chained_pmic(sec_pmic, chained_pirq, irq_data, chained_irq_chip);
}
-int sec_irq_init(struct sec_pmic_dev *sec_pmic)
+struct regmap_irq_chip_data *sec_irq_init(struct sec_pmic_dev *sec_pmic)
{
+ struct regmap_irq_chip_data *sec_irq_chip_data;
const struct regmap_irq_chip *sec_irq_chip;
int ret;
@@ -331,7 +333,7 @@ int sec_irq_init(struct sec_pmic_dev *sec_pmic)
sec_irq_chip = &s5m8767_irq_chip;
break;
case S2DOS05:
- return 0;
+ return NULL;
case S2MPA01:
sec_irq_chip = &s2mps14_irq_chip;
break;
@@ -356,30 +358,22 @@ int sec_irq_init(struct sec_pmic_dev *sec_pmic)
sec_irq_chip = &s2mpu05_irq_chip;
break;
default:
- return dev_err_probe(sec_pmic->dev, -EINVAL,
- "Unsupported device type %d\n",
- sec_pmic->device_type);
+ return dev_err_ptr_probe(sec_pmic->dev, -EINVAL, "Unsupported device type %d\n",
+ sec_pmic->device_type);
}
if (!sec_pmic->irq) {
dev_warn(sec_pmic->dev,
"No interrupt specified, no interrupts\n");
- return 0;
+ return NULL;
}
ret = devm_regmap_add_irq_chip(sec_pmic->dev, sec_pmic->regmap_pmic,
sec_pmic->irq, IRQF_ONESHOT,
- 0, sec_irq_chip, &sec_pmic->irq_data);
+ 0, sec_irq_chip, &sec_irq_chip_data);
if (ret)
- return dev_err_probe(sec_pmic->dev, ret,
- "Failed to add %s IRQ chip\n",
- sec_irq_chip->name);
+ return dev_err_ptr_probe(sec_pmic->dev, ret, "Failed to add %s IRQ chip\n",
+ sec_irq_chip->name);
- /*
- * The rtc-s5m driver requests S2MPS14_IRQ_RTCA0 also for S2MPS11
- * so the interrupt number must be consistent.
- */
- BUILD_BUG_ON(((enum s2mps14_irq)S2MPS11_IRQ_RTCA0) != S2MPS14_IRQ_RTCA0);
-
- return 0;
+ return sec_irq_chip_data;
}
diff --git a/include/linux/mfd/samsung/core.h b/include/linux/mfd/samsung/core.h
index d785e101fe795a5d8f9cccf4ccc4232437e89416..c7c3c8cd8d5f99ef0cc3188e1c3b49031f4750f2 100644
--- a/include/linux/mfd/samsung/core.h
+++ b/include/linux/mfd/samsung/core.h
@@ -69,7 +69,6 @@ struct sec_pmic_dev {
int device_type;
int irq;
- struct regmap_irq_chip_data *irq_data;
};
struct sec_platform_data {
--
2.52.0.457.g6b5491de43-goog
^ permalink raw reply related
* [PATCH v3 2/3] rtc: s5m: query platform device IRQ resource for alarm IRQ
From: André Draszik @ 2026-01-13 14:03 UTC (permalink / raw)
To: Krzysztof Kozlowski, Lee Jones, Alexandre Belloni
Cc: Peter Griffin, Tudor Ambarus, Will McVicker, Juan Yescas,
Douglas Anderson, kernel-team, Kaustabh Chakraborty, linux-kernel,
linux-samsung-soc, linux-rtc, André Draszik
In-Reply-To: <20260113-s5m-alarm-v3-0-855a19db1277@linaro.org>
The core driver now exposes the alarm IRQ as a resource, so we can drop
the lookup from here to simplify the code and make adding support for
additional variants easier in this driver.
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
drivers/rtc/rtc-s5m.c | 21 ++++++++-------------
1 file changed, 8 insertions(+), 13 deletions(-)
diff --git a/drivers/rtc/rtc-s5m.c b/drivers/rtc/rtc-s5m.c
index a7220b4d0e8dd35786b060e2a4106e2a39fe743f..c6ed5a4ca8a0e4554b1c88c879b01fc384735007 100644
--- a/drivers/rtc/rtc-s5m.c
+++ b/drivers/rtc/rtc-s5m.c
@@ -15,7 +15,6 @@
#include <linux/rtc.h>
#include <linux/platform_device.h>
#include <linux/mfd/samsung/core.h>
-#include <linux/mfd/samsung/irq.h>
#include <linux/mfd/samsung/rtc.h>
#include <linux/mfd/samsung/s2mps14.h>
@@ -683,22 +682,18 @@ static int s5m_rtc_probe(struct platform_device *pdev)
case S2MPS15X:
regmap_cfg = &s2mps14_rtc_regmap_config;
info->regs = &s2mps15_rtc_regs;
- alarm_irq = S2MPS14_IRQ_RTCA0;
break;
case S2MPS14X:
regmap_cfg = &s2mps14_rtc_regmap_config;
info->regs = &s2mps14_rtc_regs;
- alarm_irq = S2MPS14_IRQ_RTCA0;
break;
case S2MPS13X:
regmap_cfg = &s2mps14_rtc_regmap_config;
info->regs = &s2mps13_rtc_regs;
- alarm_irq = S2MPS14_IRQ_RTCA0;
break;
case S5M8767X:
regmap_cfg = &s5m_rtc_regmap_config;
info->regs = &s5m_rtc_regs;
- alarm_irq = S5M8767_IRQ_RTCA1;
break;
default:
return dev_err_probe(&pdev->dev, -ENODEV,
@@ -719,7 +714,6 @@ static int s5m_rtc_probe(struct platform_device *pdev)
"Failed to allocate regmap\n");
} else if (device_type == S2MPG10) {
info->regs = &s2mpg10_rtc_regs;
- alarm_irq = S2MPG10_IRQ_RTCA0;
} else {
return dev_err_probe(&pdev->dev, -ENODEV,
"Unsupported device type %d\n",
@@ -730,13 +724,14 @@ static int s5m_rtc_probe(struct platform_device *pdev)
info->s5m87xx = s5m87xx;
info->device_type = device_type;
- if (s5m87xx->irq_data) {
- info->irq = regmap_irq_get_virq(s5m87xx->irq_data, alarm_irq);
- if (info->irq <= 0)
- return dev_err_probe(&pdev->dev, -EINVAL,
- "Failed to get virtual IRQ %d\n",
- alarm_irq);
- }
+ alarm_irq = platform_get_irq_byname_optional(pdev, "alarm");
+ if (alarm_irq > 0)
+ info->irq = alarm_irq;
+ else if (alarm_irq == -ENXIO)
+ info->irq = 0;
+ else
+ return dev_err_probe(&pdev->dev, alarm_irq ? : -EINVAL,
+ "IRQ 'alarm' not found\n");
platform_set_drvdata(pdev, info);
--
2.52.0.457.g6b5491de43-goog
^ permalink raw reply related
* [PATCH v3 1/3] mfd: sec: add rtc alarm IRQ as platform device resource
From: André Draszik @ 2026-01-13 14:03 UTC (permalink / raw)
To: Krzysztof Kozlowski, Lee Jones, Alexandre Belloni
Cc: Peter Griffin, Tudor Ambarus, Will McVicker, Juan Yescas,
Douglas Anderson, kernel-team, Kaustabh Chakraborty, linux-kernel,
linux-samsung-soc, linux-rtc, André Draszik
In-Reply-To: <20260113-s5m-alarm-v3-0-855a19db1277@linaro.org>
By adding the RTC alarm IRQ to the MFD cell as a resource, the child
driver (rtc) can simply query that IRQ, instead of having a lookup
table itself.
This change therefore allows the child driver to be simplified with
regards to determining the alarm IRQ.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
drivers/mfd/sec-common.c | 38 +++++++++++++++++++++++++++++---------
1 file changed, 29 insertions(+), 9 deletions(-)
diff --git a/drivers/mfd/sec-common.c b/drivers/mfd/sec-common.c
index 42d55e70e34c8d7cd68cddaecc88017e259365b4..77370db52a7ba81234136b29f85892f4b197f429 100644
--- a/drivers/mfd/sec-common.c
+++ b/drivers/mfd/sec-common.c
@@ -23,9 +23,13 @@
#include <linux/regmap.h>
#include "sec-core.h"
+static const struct resource s5m8767_rtc_resources[] = {
+ DEFINE_RES_IRQ_NAMED(S5M8767_IRQ_RTCA1, "alarm"),
+};
+
static const struct mfd_cell s5m8767_devs[] = {
MFD_CELL_NAME("s5m8767-pmic"),
- MFD_CELL_NAME("s5m-rtc"),
+ MFD_CELL_RES("s5m-rtc", s5m8767_rtc_resources),
MFD_CELL_OF("s5m8767-clk", NULL, NULL, 0, 0, "samsung,s5m8767-clk"),
};
@@ -33,50 +37,66 @@ static const struct mfd_cell s2dos05_devs[] = {
MFD_CELL_NAME("s2dos05-regulator"),
};
+static const struct resource s2mpg10_rtc_resources[] = {
+ DEFINE_RES_IRQ_NAMED(S2MPG10_IRQ_RTCA0, "alarm"),
+};
+
static const struct mfd_cell s2mpg10_devs[] = {
MFD_CELL_NAME("s2mpg10-meter"),
MFD_CELL_NAME("s2mpg10-regulator"),
- MFD_CELL_NAME("s2mpg10-rtc"),
+ MFD_CELL_RES("s2mpg10-rtc", s2mpg10_rtc_resources),
MFD_CELL_OF("s2mpg10-clk", NULL, NULL, 0, 0, "samsung,s2mpg10-clk"),
MFD_CELL_OF("s2mpg10-gpio", NULL, NULL, 0, 0, "samsung,s2mpg10-gpio"),
};
+static const struct resource s2mps11_rtc_resources[] = {
+ DEFINE_RES_IRQ_NAMED(S2MPS11_IRQ_RTCA0, "alarm"),
+};
+
static const struct mfd_cell s2mps11_devs[] = {
MFD_CELL_NAME("s2mps11-regulator"),
- MFD_CELL_NAME("s2mps14-rtc"),
+ MFD_CELL_RES("s2mps14-rtc", s2mps11_rtc_resources),
MFD_CELL_OF("s2mps11-clk", NULL, NULL, 0, 0, "samsung,s2mps11-clk"),
};
+static const struct resource s2mps14_rtc_resources[] = {
+ DEFINE_RES_IRQ_NAMED(S2MPS14_IRQ_RTCA0, "alarm"),
+};
+
static const struct mfd_cell s2mps13_devs[] = {
MFD_CELL_NAME("s2mps13-regulator"),
- MFD_CELL_NAME("s2mps13-rtc"),
+ MFD_CELL_RES("s2mps13-rtc", s2mps14_rtc_resources),
MFD_CELL_OF("s2mps13-clk", NULL, NULL, 0, 0, "samsung,s2mps13-clk"),
};
static const struct mfd_cell s2mps14_devs[] = {
MFD_CELL_NAME("s2mps14-regulator"),
- MFD_CELL_NAME("s2mps14-rtc"),
+ MFD_CELL_RES("s2mps14-rtc", s2mps14_rtc_resources),
MFD_CELL_OF("s2mps14-clk", NULL, NULL, 0, 0, "samsung,s2mps14-clk"),
};
static const struct mfd_cell s2mps15_devs[] = {
MFD_CELL_NAME("s2mps15-regulator"),
- MFD_CELL_NAME("s2mps15-rtc"),
+ MFD_CELL_RES("s2mps15-rtc", s2mps14_rtc_resources),
MFD_CELL_OF("s2mps13-clk", NULL, NULL, 0, 0, "samsung,s2mps13-clk"),
};
static const struct mfd_cell s2mpa01_devs[] = {
MFD_CELL_NAME("s2mpa01-pmic"),
- MFD_CELL_NAME("s2mps14-rtc"),
+ MFD_CELL_RES("s2mps14-rtc", s2mps14_rtc_resources),
};
static const struct mfd_cell s2mpu02_devs[] = {
MFD_CELL_NAME("s2mpu02-regulator"),
};
+static const struct resource s2mpu05_rtc_resources[] = {
+ DEFINE_RES_IRQ_NAMED(S2MPU05_IRQ_RTCA0, "alarm"),
+};
+
static const struct mfd_cell s2mpu05_devs[] = {
MFD_CELL_NAME("s2mpu05-regulator"),
- MFD_CELL_NAME("s2mps15-rtc"),
+ MFD_CELL_RES("s2mps15-rtc", s2mpu05_rtc_resources),
};
static void sec_pmic_dump_rev(struct sec_pmic_dev *sec_pmic)
@@ -220,7 +240,7 @@ int sec_pmic_probe(struct device *dev, int device_type, unsigned int irq,
sec_pmic->device_type);
}
ret = devm_mfd_add_devices(sec_pmic->dev, -1, sec_devs, num_sec_devs,
- NULL, 0, NULL);
+ NULL, 0, regmap_irq_get_domain(sec_pmic->irq_data));
if (ret)
return ret;
--
2.52.0.457.g6b5491de43-goog
^ permalink raw reply related
* [PATCH v3 0/3] Samsung mfd/rtc driver alarm IRQ simplification
From: André Draszik @ 2026-01-13 14:03 UTC (permalink / raw)
To: Krzysztof Kozlowski, Lee Jones, Alexandre Belloni
Cc: Peter Griffin, Tudor Ambarus, Will McVicker, Juan Yescas,
Douglas Anderson, kernel-team, Kaustabh Chakraborty, linux-kernel,
linux-samsung-soc, linux-rtc, André Draszik
Hi,
With the attached patches the Samsung s5m RTC driver is simplified a
little bit with regards to alarm IRQ acquisition.
The end result is that instead of having a list of IRQ numbers for each
variant (and a BUILD_BUG_ON() to ensure consistency), the RTC driver
queries the 'alarm' platform resource from the parent (mfd cell).
Additionally, we can drop a now-useless field from runtime data,
reducing memory consumption slightly.
The attached patches must be applied in-order as patch 2 without 1 will
fail at runtime, and patch 3 without 2 will fail at build time. I would
expect them all to go via the MFD tree. Alternatively, they could be
applied individually to the respective kernel trees during multiple
kernel release cycles, but that seems a needless complication and
delay.
Signed-off-by: André Draszik <andre.draszik@linaro.org>
---
Changes in v3:
- make s2mpg1x_add_chained_irq_chip() specific to PMIC irq chip (Lee),
and rename to s2mpg1x_add_chained_pmic() (Andre)
- Link to v2: https://lore.kernel.org/r/20251120-s5m-alarm-v2-0-cc15f0e32161@linaro.org
Changes in v2:
- rebase on top of https://lore.kernel.org/r/20251114-s2mpg10-chained-irq-v1-1-34ddfa49c4cd@linaro.org
- return struct regmap_irq_chip_data * in sec_irq_init() (Lee)
- collect tags
- Link to v1: https://lore.kernel.org/r/20251114-s5m-alarm-v1-0-c9b3bebae65f@linaro.org
---
André Draszik (3):
mfd: sec: add rtc alarm IRQ as platform device resource
rtc: s5m: query platform device IRQ resource for alarm IRQ
mfd: sec: drop now unused struct sec_pmic_dev::irq_data
drivers/mfd/sec-common.c | 45 ++++++++++++++++++++--------
drivers/mfd/sec-core.h | 2 +-
drivers/mfd/sec-irq.c | 64 ++++++++++++++++++----------------------
drivers/rtc/rtc-s5m.c | 21 +++++--------
include/linux/mfd/samsung/core.h | 1 -
5 files changed, 71 insertions(+), 62 deletions(-)
---
base-commit: 0f853ca2a798ead9d24d39cad99b0966815c582a
change-id: 20251114-s5m-alarm-3de705ea53ce
Best regards,
--
André Draszik <andre.draszik@linaro.org>
^ 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