* 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
* Re: [PATCH RESEND v2 3/3] mfd: sec: drop now unused struct sec_pmic_dev::irq_data
From: André Draszik @ 2026-01-13 13:48 UTC (permalink / raw)
To: Lee Jones
Cc: Krzysztof Kozlowski, Alexandre Belloni, Peter Griffin,
Tudor Ambarus, Will McVicker, Juan Yescas, Douglas Anderson,
kernel-team, Kaustabh Chakraborty, linux-kernel,
linux-samsung-soc, linux-rtc
In-Reply-To: <20260109104534.GF1118061@google.com>
Hi Lee,
Thanks for your review.
On Fri, 2026-01-09 at 10:45 +0000, Lee Jones wrote:
> On Wed, 17 Dec 2025, André Draszik wrote:
>
> > 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>
> > ---
> > drivers/mfd/sec-common.c | 9 +++---
> > drivers/mfd/sec-core.h | 2 +-
> > drivers/mfd/sec-irq.c | 63 ++++++++++++++++++----------------------
> > include/linux/mfd/samsung/core.h | 1 -
> > 4 files changed, 35 insertions(+), 40 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 d992e41e716dcdc060421e1db8475523842a12be..96f53c3617da4cb54f650f9b98c0b934b823ceda 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_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;
> > 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, regmap, 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,28 @@ 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);
> > + irq_data, chained_irq_chip);
>
> That's a shame.
>
> By keeping irq_data, you could have cleaned-up a bunch of these ugly
> calls by simply passing around sec_pmic or better yet dev (then extract
> sec_pmic from there).
>
> Thus:
>
> return s2mpg1x_add_chained_irq_chip(sec_pmic->dev, sec_pmic->regmap_pmic, chained_pirq,
> irq_data, chained_irq_chip, &sec_pmic->irq_data);
> irq_data, chained_irq_chip);
>
> Becomes:
>
> return s2mpg1x_add_chained_irq_chip(dev, chained_pirq, irq_data, chained_irq_chip);
s2mpg1x_add_chained_irq_chip() was modelled to be consistent with other
drivers doing a similar setup:
drivers/mfd/intel_soc_pmic_bxtwc.c
drivers/mfd/max77759.c
Maybe they're not good examples, but then maybe they also should be changed,
to ensure people don't copy from them.
As-is, it can easily be extended for additional chained chips, as the relevant
arguments are parameters and it can be used as a template for the benefit of
other (new) drivers (writers).
It slightly diverged from above two drivers in v2 since you requested for it
to 'return' 'struct regmap_irq_chip_data *' instead of having
'struct regmap_irq_chip_data **' an additional argument in v1, though.
With your proposed change it won't be able to serve as example code as
easily. I see benefit in having similar code for similar setup. Anyway,
I'll change it again.
Cheers,
Andre'
^ permalink raw reply
* Re: [PATCH v5 2/3] mfd: simple-mfd-i2c: add default value
From: Lee Jones @ 2026-01-13 12:42 UTC (permalink / raw)
To: 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: <20260108-p1-kconfig-fix-v5-2-6fe19f460269@linux.spacemit.com>
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.
--
Lee Jones [李琼斯]
^ permalink raw reply
* [PATCH v2 11/16] rtc: pic32: update include to use pic32.h from platform_data
From: Brian Masney @ 2026-01-12 22:48 UTC (permalink / raw)
To: Thomas Bogendoerfer, Claudiu Beznea
Cc: linux-mips, linux-kernel, Brian Masney, Alexandre Belloni,
linux-rtc
In-Reply-To: <20260112-mips-pic32-header-move-v2-0-927d516b1ff9@redhat.com>
Use the linux/platform_data/pic32.h include instead of
asm/mach-pic32/pic32.h so that the asm variant can be dropped. This
is in preparation for allowing some drivers to be compiled on other
architectures with COMPILE_TEST enabled.
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Signed-off-by: Brian Masney <bmasney@redhat.com>
---
To: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: linux-rtc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
| 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
--git a/drivers/rtc/rtc-pic32.c b/drivers/rtc/rtc-pic32.c
index 52c11532bc3a3696359ca56349b42860aa90c966..3c7a38a4ac08eb0f5a44ae4e470c208a9d1dd599 100644
--- a/drivers/rtc/rtc-pic32.c
+++ b/drivers/rtc/rtc-pic32.c
@@ -15,8 +15,7 @@
#include <linux/clk.h>
#include <linux/rtc.h>
#include <linux/bcd.h>
-
-#include <asm/mach-pic32/pic32.h>
+#include <linux/platform_data/pic32.h>
#define PIC32_RTCCON 0x00
#define PIC32_RTCCON_ON BIT(15)
--
2.52.0
^ permalink raw reply related
* [PATCH v2 00/16] MIPS: move pic32.h header file from asm to platform_data
From: Brian Masney @ 2026-01-12 22:47 UTC (permalink / raw)
To: Thomas Bogendoerfer, Claudiu Beznea
Cc: linux-mips, linux-kernel, Brian Masney, Michael Turquette,
Stephen Boyd, linux-clk, Thomas Gleixner, Adrian Hunter,
Ulf Hansson, linux-mmc, Linus Walleij, linux-gpio,
Alexandre Belloni, linux-rtc, Greg Kroah-Hartman, Jiri Slaby,
linux-serial, Guenter Roeck, Wim Van Sebroeck, linux-watchdog
There are currently some pic32 MIPS drivers that are in tree, and are
only configured to be compiled on the MIPS pic32 platform. There's a
risk of breaking some of these drivers when migrating drivers away from
legacy APIs. It happened to me with a pic32 clk driver.
Let's go ahead and move the pic32.h from the asm to the platform_data
include directory in the tree. This will make it easier, and cleaner to
enable COMPILE_TEST for some of these pic32 drivers. To do this requires
updating some includes, which I do at the beginning of this series.
This series was compile tested on a centos-stream-10 arm64 host in two
different configurations:
- native arm64 build with COMPILE_TEST (via make allmodconfig)
- MIPS cross compile on arm64 with:
ARCH=mips CROSS_COMPILE=mips64-linux-gnu- make pic32mzda_defconfig
Note that there is a separate MIPS compile error in linux-next, and I
reported it at https://lore.kernel.org/all/aWVs2gVB418WiMVa@redhat.com/
I included a patch at the end that shows enabling COMPILE_TEST for a
pic32 clk driver.
Merge Strategy
==============
- Patches 1-15 can go through the MIPS tree.
- Patch 16 I can repost to Claudiu after patches 1-15 are in Linus's
tree after the next merge window. There is a separate patch set that
fixes a compiler error I unintentionally introduced via the clk tree.
https://lore.kernel.org/linux-clk/CABx5tq+eOocJ41X-GSgkGy6S+s+Am1yCS099wqP695NtwALTmg@mail.gmail.com/T/
Signed-off-by: Brian Masney <bmasney@redhat.com>
---
Changes in v2:
- Fix native MIPS build by updating include files
- Link to v1: https://lore.kernel.org/r/20260109-mips-pic32-header-move-v1-0-99859c55783d@redhat.com
---
Brian Masney (16):
MIPS: pic32: include linux/io.h header on several files
MIPS: pic32: include linux/types.h on pic32.h
MIPS: pic32: drop unused include linux/io.h from pic32.h
MIPS: copy pic32.h header file from asm/mach-pic32/ to include/platform-data/
MAINTAINERS: add include/linux/platform_data/pic32.h to MIPS entry
MIPS: update include to use pic32.h from platform_data
clk: microchip: core: update include to use pic32.h from platform_data
irqchip/irq-pic32-evic: update include to use pic32.h from platform_data
mmc: sdhci-pic32: update include to use pic32.h from platform_data
pinctrl: pic32: update include to use pic32.h from platform_data
rtc: pic32: update include to use pic32.h from platform_data
serial: pic32_uart: update include to use pic32.h from platform_data
watchdog: pic32-dmt: update include to use pic32.h from platform_data
watchdog: pic32-wdt: update include to use pic32.h from platform_data
MIPS: drop unused pic32.h header
clk: microchip: core: allow driver to be compiled with COMPILE_TEST
MAINTAINERS | 1 +
arch/mips/pic32/common/reset.c | 3 ++-
arch/mips/pic32/pic32mzda/config.c | 3 +--
arch/mips/pic32/pic32mzda/early_clk.c | 3 ++-
arch/mips/pic32/pic32mzda/early_console.c | 3 ++-
drivers/clk/microchip/Kconfig | 2 +-
drivers/clk/microchip/clk-core.c | 6 +++++-
drivers/irqchip/irq-pic32-evic.c | 2 +-
drivers/mmc/host/sdhci-pic32.c | 2 +-
drivers/pinctrl/pinctrl-pic32.c | 3 +--
drivers/rtc/rtc-pic32.c | 3 +--
drivers/tty/serial/pic32_uart.c | 3 +--
drivers/watchdog/pic32-dmt.c | 3 +--
drivers/watchdog/pic32-wdt.c | 3 +--
.../mach-pic32 => include/linux/platform_data}/pic32.h | 17 ++++++++++-------
15 files changed, 31 insertions(+), 26 deletions(-)
---
base-commit: f417b7ffcbef7d76b0d8860518f50dae0e7e5eda
change-id: 20260109-mips-pic32-header-move-6ac9965aa70a
Best regards,
--
Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCH] rtc: max31335: use correct CONFIG symbol in IS_REACHABLE()
From: Nuno Sá @ 2026-01-12 13:23 UTC (permalink / raw)
To: Randy Dunlap, linux-kernel; +Cc: Antoniu Miclaus, Alexandre Belloni, linux-rtc
In-Reply-To: <20260108045432.2705691-1-rdunlap@infradead.org>
On Wed, 2026-01-07 at 20:54 -0800, Randy Dunlap wrote:
> IS_REACHABLE() is meant to be used with full symbol names from a kernel
> .config file, not the shortened symbols used in Kconfig files, so
> change HWMON to CONFIG_HWMON in 3 places.
>
> Fixes: dedaf03b99d6 ("rtc: max31335: add driver support")
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
> ---
Acked-by: Nuno Sá <nuno.sa@analog.com>
> Cc: Antoniu Miclaus <antoniu.miclaus@analog.com>
> Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
> Cc: linux-rtc@vger.kernel.org
>
> drivers/rtc/rtc-max31335.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> --- linux-next-20260107.orig/drivers/rtc/rtc-max31335.c
> +++ linux-next-20260107/drivers/rtc/rtc-max31335.c
> @@ -591,7 +591,7 @@ static struct nvmem_config max31335_nvme
> .size = MAX31335_RAM_SIZE,
> };
>
> -#if IS_REACHABLE(HWMON)
> +#if IS_REACHABLE(CONFIG_HWMON)
> static int max31335_read_temp(struct device *dev, enum hwmon_sensor_types type,
> u32 attr, int channel, long *val)
> {
> @@ -672,7 +672,7 @@ static int max31335_clkout_register(stru
> static int max31335_probe(struct i2c_client *client)
> {
> struct max31335_data *max31335;
> -#if IS_REACHABLE(HWMON)
> +#if IS_REACHABLE(CONFIG_HWMON)
> struct device *hwmon;
> #endif
> const struct chip_desc *match;
> @@ -727,7 +727,7 @@ static int max31335_probe(struct i2c_cli
> return dev_err_probe(&client->dev, ret,
> "cannot register rtc nvmem\n");
>
> -#if IS_REACHABLE(HWMON)
> +#if IS_REACHABLE(CONFIG_HWMON)
> if (max31335->chip->temp_reg) {
> hwmon = devm_hwmon_device_register_with_info(&client->dev, client->name,
> max31335,
> &max31335_chip_info, NULL);
^ permalink raw reply
* Re: [PATCH RESEND v6 00/17] Support ROHM BD72720 PMIC
From: Matti Vaittinen @ 2026-01-12 12:04 UTC (permalink / raw)
To: Sebastian Reichel, Lee Jones
Cc: 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: <aWRFs3CJvd37BaoH@venus>
On 12/01/2026 02:53, Sebastian Reichel wrote:
> Hi,
>
> 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).
Yours,
-- Matti
--
---
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* Re: [PATCH RESEND v6 16/17] power: supply: bd71828-power: Support ROHM BD72720
From: Matti Vaittinen @ 2026-01-12 6:44 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Matti Vaittinen, Lee Jones, 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: <aWRERf70jg-IzqIx@venus>
On 12/01/2026 02:51, Sebastian Reichel wrote:
> Hi,
>
> On Mon, Dec 15, 2025 at 03:21:19PM +0200, Matti Vaittinen wrote:
>> From: Matti Vaittinen <mazziesaccount@gmail.com>
>>
>> The ROHM BD72720 is a power management IC with a charger and coulomb
>> counter block which is closely related to the charger / coulomb counter
>> found from the BD71815, BD71828, BD71879 which are all supported by the
>> bd71828-power driver. Due to the similarities it makes sense to support
>> also the BD72720 with the same driver.
>>
>> Add basic support for the charger logic on ROHM BD72720.
>>
>> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
>>
>> ---
>> Revision history:
>> v2 => :
>> - No changes
>>
>> RFCv1 => v2:
>> - Support using 9-bit register addresses (offset of 0x100) with the
>> BD72720
>> - Simplify probe and IC data as we don't need two regmaps
>> - Drop two BD72720 specific functions as we no longer need different
>> regmap for it.
>>
>> Note: This patch depends on the series: "power: supply: add charger for
>> BD71828" by Andreas:
>> https://lore.kernel.org/all/20250918-bd71828-charger-v5-0-851164839c28@kemnade.info/
>
> That should be in v6.19?
Ah, right. As Andreas also stated, yes. This is no longer relevant. I
simply forgot to clean-up the note from this patch.
>> @@ -958,21 +1043,27 @@ static int bd71828_power_probe(struct platform_device *pdev)
>> struct power_supply_config ac_cfg = {};
>> struct power_supply_config bat_cfg = {};
>> int ret;
>> - struct regmap *regmap;
>> -
>> - regmap = dev_get_regmap(pdev->dev.parent, NULL);
>> - if (!regmap) {
>> - dev_err(&pdev->dev, "No parent regmap\n");
>> - return -EINVAL;
>> - }
>>
>> pwr = devm_kzalloc(&pdev->dev, sizeof(*pwr), GFP_KERNEL);
>> if (!pwr)
>> return -ENOMEM;
>>
>> - pwr->regmap = regmap;
>> - pwr->dev = &pdev->dev;
>> + /*
>> + * The BD72720 MFD device registers two regmaps. Power-supply driver
>> + * uses the "wrap-map", which provides access to both of the I2C slave
>> + * addresses used by the BD72720
>> + */
>> pwr->chip_type = platform_get_device_id(pdev)->driver_data;
>> + if (pwr->chip_type != ROHM_CHIP_TYPE_BD72720)
>> + pwr->regmap = dev_get_regmap(pdev->dev.parent, NULL);
>> + else
>> + pwr->regmap = dev_get_regmap(pdev->dev.parent, "wrap-map");
>> + if (!pwr->regmap) {
>> + dev_err(&pdev->dev, "No parent regmap\n");
>> + return -EINVAL;
>> + }
>
> return dev_err_probe(&pdev->dev, -EINVAL, "No parent regmap\n");
>
> Otherwise LGTM.
Thanks Sebastian! I appreciate the review!
This driver uses dev_err_probe() only in cases where the error to be
returned is not hard-coded. The design dates back to when I was first
introduced to the dev_err_probe() - and using pattern like:
ret = -EINVAL;
if (ret == -EPROBE_DEFER)
...
(which results from calling the dev_err_probe with hard-coded error)
felt very repulsive to me.
I have since quit resisting the 'use dev_err_probe() for all probe error
paths' -policy (since Resistance is futile - and because there are other
benefits besides the deferred probe handling) - but I suppose we should
clean-up also the other similar cases in this driver (I see at least one
other occurrence in the chip_type-check below). Is it Ok to merge this
as is, and do a follow-up patch to clean-up all the occurrences? If yes,
then this might go "as-is" via MFD, together with the other stuff, right?
I can also re-spin this with the print fixed and:
- add new patch to fix the other occurrence.
- meld the fix for existing print in this patch.
Just please let me know your preference.
>> switch (pwr->chip_type) {
>> case ROHM_CHIP_TYPE_BD71828:
>> @@ -985,6 +1076,12 @@ static int bd71828_power_probe(struct platform_device *pdev)
>> pwr->get_temp = bd71815_get_temp;
>> pwr->regs = &pwr_regs_bd71815;
>> break;
>> + case ROHM_CHIP_TYPE_BD72720:
>> + pwr->bat_inserted = bd71828_bat_inserted;
>> + pwr->regs = &pwr_regs_bd72720;
>> + pwr->get_temp = bd71828_get_temp;
>> + dev_dbg(pwr->dev, "Found ROHM BD72720\n");
>> + break;
>> default:
>> dev_err(pwr->dev, "Unknown PMIC\n");
>> return -EINVAL;
The other occurrence --^
>> @@ -1030,6 +1127,7 @@ static int bd71828_power_probe(struct platform_device *pdev)
>> static const struct platform_device_id bd71828_charger_id[] = {
>> { "bd71815-power", ROHM_CHIP_TYPE_BD71815 },
>> { "bd71828-power", ROHM_CHIP_TYPE_BD71828 },
>> + { "bd72720-power", ROHM_CHIP_TYPE_BD72720 },
>> { },
>> };
>> MODULE_DEVICE_TABLE(platform, bd71828_charger_id);
>> --
>> 2.52.0
Yours,
-- Matti
--
---
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* Re: [PATCH RESEND v6 16/17] power: supply: bd71828-power: Support ROHM BD72720
From: Andreas Kemnade @ 2026-01-12 6:11 UTC (permalink / raw)
To: Sebastian Reichel
Cc: Matti Vaittinen, Matti Vaittinen, Lee Jones, 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
In-Reply-To: <aWRERf70jg-IzqIx@venus>
On Mon, 12 Jan 2026 01:51:58 +0100
Sebastian Reichel <sebastian.reichel@collabora.com> wrote:
> Hi,
>
> On Mon, Dec 15, 2025 at 03:21:19PM +0200, Matti Vaittinen wrote:
> > From: Matti Vaittinen <mazziesaccount@gmail.com>
> >
> > The ROHM BD72720 is a power management IC with a charger and coulomb
> > counter block which is closely related to the charger / coulomb counter
> > found from the BD71815, BD71828, BD71879 which are all supported by the
> > bd71828-power driver. Due to the similarities it makes sense to support
> > also the BD72720 with the same driver.
> >
> > Add basic support for the charger logic on ROHM BD72720.
> >
> > Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> >
> > ---
> > Revision history:
> > v2 => :
> > - No changes
> >
> > RFCv1 => v2:
> > - Support using 9-bit register addresses (offset of 0x100) with the
> > BD72720
> > - Simplify probe and IC data as we don't need two regmaps
> > - Drop two BD72720 specific functions as we no longer need different
> > regmap for it.
> >
> > Note: This patch depends on the series: "power: supply: add charger for
> > BD71828" by Andreas:
> > https://lore.kernel.org/all/20250918-bd71828-charger-v5-0-851164839c28@kemnade.info/
>
> That should be in v6.19?
>
yes, it is.
Just this note survived...
Regards,
Andreas
^ permalink raw reply
* Re: [PATCH v5 1/3] regulator: spacemit: MFD_SPACEMIT_P1 as dependencies
From: Troy Mitchell @ 2026-01-12 1:51 UTC (permalink / raw)
To: Alexandre Belloni, Troy Mitchell
Cc: Lee Jones, Yixun Lan, Alex Elder, Andi Shyti, Liam Girdwood,
Mark Brown, linux-kernel, linux-riscv, spacemit, linux-i2c,
linux-rtc
In-Reply-To: <20260109224147267169ba@mail.local>
On Sat Jan 10, 2026 at 6:41 AM CST, Alexandre Belloni wrote:
> On 08/01/2026 16:38:54+0800, Troy Mitchell wrote:
>> diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
>> index d2335276cce5ffbd500bbaf251d1761a9116aee9..b51888a9a78f399a6af3294fc19f60792576332c 100644
>> --- a/drivers/regulator/Kconfig
>> +++ b/drivers/regulator/Kconfig
>> @@ -1496,9 +1496,8 @@ config REGULATOR_SLG51000
>> config REGULATOR_SPACEMIT_P1
>> tristate "SpacemiT P1 regulators"
>> depends on ARCH_SPACEMIT || COMPILE_TEST
>> - depends on I2C
>> - select MFD_SPACEMIT_P1
>> - default ARCH_SPACEMIT
>> + depends on MFD_SPACEMIT_P1
>> + default m if MFD_SPACEMIT_P1
>
> default MFD_SPACEMIT_P1 is certainly enough here.
Yes, Thanks!
I'll use it in the next version.
- Troy
^ 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