* [PATCH v3 2/6] rtc: zynqmp: correct frequency value
From: Tomas Melin @ 2026-01-19 9:51 UTC (permalink / raw)
To: Alexandre Belloni, Michal Simek
Cc: linux-rtc, linux-arm-kernel, linux-kernel, Tomas Melin, Harini T
In-Reply-To: <20260119-zynqmp-rtc-updates-v3-0-acd902fdeab1@vaisala.com>
Fix calibration value in case a clock reference is provided.
The actual calibration value written into register is
frequency - 1.
Reviewed-by: Harini T <harini.t@amd.com>
Tested-by: Harini T <harini.t@amd.com>
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..856bc1678e7d31144f320ae9f75fc58c742a2a64 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 related
* [PATCH v3 5/6] rtc: zynqmp: rework set_offset
From: Tomas Melin @ 2026-01-19 9:51 UTC (permalink / raw)
To: Alexandre Belloni, Michal Simek
Cc: linux-rtc, linux-arm-kernel, linux-kernel, Tomas Melin, Harini T
In-Reply-To: <20260119-zynqmp-rtc-updates-v3-0-acd902fdeab1@vaisala.com>
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.
Tested-by: Harini T <harini.t@amd.com>
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..1bc957b3a9058aa1d809696c13662ecef0437a92 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;
+ int freq = xrtcdev->freq;
unsigned int calibval;
- short int max_tick;
- int fract_offset;
+ int fract_data = 0;
+ /* 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
^ permalink raw reply related
* [PATCH v3 0/6] rtc: zynqmp: fixes for read and set offset
From: Tomas Melin @ 2026-01-19 9:51 UTC (permalink / raw)
To: Alexandre Belloni, Michal Simek
Cc: linux-rtc, linux-arm-kernel, linux-kernel, Tomas Melin,
kernel test robot, Harini T
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. This is however well below the granularity
provided by the hardware.
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 v3:
- Add commit for limiting building of driver to zynqmp arch.
- Reorder variable declarations in set_offset
- Link to v2: https://lore.kernel.org/r/20260108-zynqmp-rtc-updates-v2-0-864c161fa83d@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 (6):
rtc: zynqmp: declare dependency on arch
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/Kconfig | 2 +-
drivers/rtc/rtc-zynqmp.c | 74 ++++++++++++++++++++++++++----------------------
2 files changed, 41 insertions(+), 35 deletions(-)
---
base-commit: cd635e33b0113287c94021be53d2a7c61a1614e9
change-id: 20251201-zynqmp-rtc-updates-d260364cc01b
Best regards,
--
Tomas Melin <tomas.melin@vaisala.com>
^ permalink raw reply
* [PATCH v3 3/6] rtc: zynqmp: check calibration max value
From: Tomas Melin @ 2026-01-19 9:51 UTC (permalink / raw)
To: Alexandre Belloni, Michal Simek
Cc: linux-rtc, linux-arm-kernel, linux-kernel, Tomas Melin, Harini T
In-Reply-To: <20260119-zynqmp-rtc-updates-v3-0-acd902fdeab1@vaisala.com>
Enable check to not overflow the calibration
max value.
Reviewed-by: Harini T <harini.t@amd.com>
Tested-by: Harini T <harini.t@amd.com>
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..caacce3725e2ef3803ea42d40e77ceaeb7d7b914 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 related
* [PATCH v3 1/6] rtc: zynqmp: declare dependency on arch
From: Tomas Melin @ 2026-01-19 9:51 UTC (permalink / raw)
To: Alexandre Belloni, Michal Simek
Cc: linux-rtc, linux-arm-kernel, linux-kernel, Tomas Melin,
kernel test robot
In-Reply-To: <20260119-zynqmp-rtc-updates-v3-0-acd902fdeab1@vaisala.com>
Driver is compatible with RTC controller found on zynqmp.
Configure dependency to enable building only when zynqmp architecture
is enabled.
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Tomas Melin <tomas.melin@vaisala.com>
---
drivers/rtc/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index 2933c41c77c88e60df721fe65b9c8afb995ae51e..46b497524cbfb5d0c1662dcaddbb6d28b4ae2abe 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1376,7 +1376,7 @@ config RTC_DRV_OPTEE
config RTC_DRV_ZYNQMP
tristate "Xilinx Zynq Ultrascale+ MPSoC RTC"
- depends on OF && HAS_IOMEM
+ depends on OF && HAS_IOMEM && ARCH_ZYNQMP
help
If you say yes here you get support for the RTC controller found on
Xilinx Zynq Ultrascale+ MPSoC.
--
2.47.3
^ permalink raw reply related
* [PATCH v3 4/6] rtc: zynqmp: rework read_offset
From: Tomas Melin @ 2026-01-19 9:51 UTC (permalink / raw)
To: Alexandre Belloni, Michal Simek
Cc: linux-rtc, linux-arm-kernel, linux-kernel, Tomas Melin, Harini T
In-Reply-To: <20260119-zynqmp-rtc-updates-v3-0-acd902fdeab1@vaisala.com>
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.
Reviewed-by: Harini T <harini.t@amd.com>
Tested-by: Harini T <harini.t@amd.com>
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..6740c3aed1897d4b50a02c4823a746d9c2ae2655 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 related
* [PATCH v3 6/6] rtc: zynqmp: use dynamic max and min offset ranges
From: Tomas Melin @ 2026-01-19 9:51 UTC (permalink / raw)
To: Alexandre Belloni, Michal Simek
Cc: linux-rtc, linux-arm-kernel, linux-kernel, Tomas Melin, Harini T
In-Reply-To: <20260119-zynqmp-rtc-updates-v3-0-acd902fdeab1@vaisala.com>
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.
Reviewed-by: Harini T <harini.t@amd.com>
Tested-by: Harini T <harini.t@amd.com>
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 1bc957b3a9058aa1d809696c13662ecef0437a92..8fc2f838707c32297e812ef1b8a195ff55f849e3 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 related
* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Danilo Krummrich @ 2026-01-19 14:32 UTC (permalink / raw)
To: Ke Sun
Cc: Alexandre Belloni, 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,
Greg Kroah-Hartman, Rafael J. Wysocki
In-Reply-To: <20260116162203.296844-2-sunke@kylinos.cn>
On Fri Jan 16, 2026 at 5:21 PM CET, Ke Sun wrote:
> diff --git a/drivers/rtc/dev.c b/drivers/rtc/dev.c
> index baf1a8ca8b2b1..eddcc5a69db3b 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_ops_dev(rtc), ¶m);
> else
> err = -EINVAL;
> }
<snip>
> +/**
> + * rtc_ops_dev - Get the device pointer for RTC ops callbacks
> + * @rtc: RTC device
> + *
> + * Returns &rtc->dev if RTC_OPS_USE_RTC_DEV flag is set,
> + * otherwise returns rtc->dev.parent.
> + */
> +static inline struct device *rtc_ops_dev(struct rtc_device *rtc)
> +{
> + if (test_bit(RTC_OPS_USE_RTC_DEV, &rtc->flags))
> + return &rtc->dev;
> + return rtc->dev.parent;
> +}
I understand that the idea is to gradually convert all drivers to use the RTC
device, rather than it's parent device in RTC device callbacks.
My main concern is that once that has been achieved it's still not what we want
to have eventually, i.e. RTC device callbacks should ideally take a struct
rtc_device as argument and not the embedded base struct device.
I.e. we'd kick off a conversion process that won't reach the actual desired
state.
^ permalink raw reply
* Re: [PATCH v3 2/3] dt-bindings: rtc: loongson: Document Loongson-2K0300 compatible
From: Conor Dooley @ 2026-01-19 18:21 UTC (permalink / raw)
To: Binbin Zhou
Cc: Binbin Zhou, Huacai Chen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alexandre Belloni, linux-rtc, Xiaochuang Mao,
Huacai Chen, Xuerui Wang, loongarch, devicetree, linux-mips,
Keguang Zhang
In-Reply-To: <0c6a4fd221b5bf05f06cae9bb543a5bf7ea59f57.1768616276.git.zhoubinbin@loongson.cn>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: rtc: loongson: Correct Loongson-1C interrupts property
From: Conor Dooley @ 2026-01-19 18:24 UTC (permalink / raw)
To: Binbin Zhou
Cc: Binbin Zhou, Huacai Chen, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Alexandre Belloni, linux-rtc, Xiaochuang Mao,
Huacai Chen, Xuerui Wang, loongarch, devicetree, linux-mips,
Keguang Zhang
In-Reply-To: <b6295c907410f6708115cba4df0959ee6629f8a5.1768616276.git.zhoubinbin@loongson.cn>
[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]
On Sat, Jan 17, 2026 at 10:26:48AM +0800, Binbin Zhou wrote:
> The `interrupts` property indicates an RTC alarm interrupt, which is
> required for RTCs that support the alarm feature, which is not supported
> by the Loongson-1C RTC. We exclude it for a more accurate description.
>
> Changing the `allowed` property is ABI-breaking behavior, but
> throughout the existing Loongson DTS{i}, the description of the RTC
> nodes conforms to the modified bingding rules.
Right, changing properties is an ABI break, but when following the ABI
would've produced something non-functional, breaking it is not really
relevant.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
>
> Thus, the existing Loongson DTS{i} will not be affected.
>
> Fixes: 487ef32caebe ("dt-bindings: rtc: Split loongson,ls2x-rtc into SoC-based compatibles")
> Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
> Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
> ---
> .../devicetree/bindings/rtc/loongson,rtc.yaml | 11 +++++++++++
> 1 file changed, 11 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
> index f89c1f660aee..fac90a18153e 100644
> --- a/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
> +++ b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
> @@ -42,6 +42,17 @@ required:
>
> unevaluatedProperties: false
>
> +if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - loongson,ls1c-rtc
> +
> +then:
> + properties:
> + interrupts: false
> +
> examples:
> - |
> #include <dt-bindings/interrupt-controller/irq.h>
> --
> 2.47.3
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] rtc: interface: Alarm race handling should not discard preceding error
From: Alexandre Belloni @ 2026-01-19 23:08 UTC (permalink / raw)
To: linux-rtc, Anthony Pighin (Nokia)
In-Reply-To: <BN0PR08MB6951415A751F236375A2945683D1A@BN0PR08MB6951.namprd08.prod.outlook.com>
On Tue, 25 Nov 2025 17:35:19 +0000, Anthony Pighin (Nokia) wrote:
> Commit 795cda8338ea ("rtc: interface: Fix long-standing race when setting
> alarm") should not discard any errors from the preceding validations.
>
> Prior to that commit, if the alarm feature was disabled, or the
> set_alarm failed, a meaningful error code would be returned to the
> caller for further action.
>
> [...]
Applied, after fixing the patch that has been mangled by outlook...
Also, you had this checkpatch error:
CHECK: From:/Signed-off-by: email comments mismatch: 'From: Anthony Pighin (Nokia) <anthony.pighin@nokia.com>' != 'Signed-off-by: Anthony Pighin <anthony.pighin@nokia.com>'
[1/1] rtc: interface: Alarm race handling should not discard preceding error
https://git.kernel.org/abelloni/c/c6cf26c15ce7
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] rtc: pcf8563: use correct of_node for output clock
From: Alexandre Belloni @ 2026-01-19 23:17 UTC (permalink / raw)
To: linux-rtc, John Keeping; +Cc: stable, Nobuhiro Iwamatsu, linux-kernel
In-Reply-To: <20260108184749.3413348-1-jkeeping@inmusicbrands.com>
On Thu, 08 Jan 2026 18:47:48 +0000, John Keeping wrote:
> When switching to regmap, the i2c_client pointer was removed from struct
> pcf8563 so this function switched to using the RTC device instead. But
> the RTC device is a child of the original I2C device and does not have
> an associated of_node.
>
> Reference the correct device's of_node to ensure that the output clock
> can be found when referenced by other devices and so that the override
> clock name is read correctly.
>
> [...]
Applied, thanks!
[1/1] rtc: pcf8563: use correct of_node for output clock
https://git.kernel.org/abelloni/c/a380a02ea3dd
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] rtc: nvvrs: Add ARCH_TEGRA to the NV VRS RTC driver
From: Alexandre Belloni @ 2026-01-19 23:17 UTC (permalink / raw)
To: linux-rtc, Peter Robinson; +Cc: Shubhi Garg, Jon Hunter
In-Reply-To: <20251222035651.433603-1-pbrobinson@gmail.com>
On Mon, 22 Dec 2025 03:56:48 +0000, Peter Robinson wrote:
> The NV VRS RTC driver currently is only supported on the
> Tegra platform so add a dep for ARCH_TEGRA and compile test
> so it doesn't show up universally across all arches/platforms.
>
>
Applied, thanks!
[1/1] rtc: nvvrs: Add ARCH_TEGRA to the NV VRS RTC driver
https://git.kernel.org/abelloni/c/f9ecfd9bfedb
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH] rtc: max31335: use correct CONFIG symbol in IS_REACHABLE()
From: Alexandre Belloni @ 2026-01-19 23:17 UTC (permalink / raw)
To: linux-kernel, Randy Dunlap; +Cc: Antoniu Miclaus, linux-rtc
In-Reply-To: <20260108045432.2705691-1-rdunlap@infradead.org>
On Wed, 07 Jan 2026 20:54:32 -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.
>
>
Applied, thanks!
[1/1] rtc: max31335: use correct CONFIG symbol in IS_REACHABLE()
https://git.kernel.org/abelloni/c/d5aca9a17f6d
Best regards,
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: rtc: loongson: Correct Loongson-1C interrupts property
From: Alexandre Belloni @ 2026-01-20 7:50 UTC (permalink / raw)
To: Conor Dooley
Cc: Binbin Zhou, Binbin Zhou, Huacai Chen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-rtc, Xiaochuang Mao,
Huacai Chen, Xuerui Wang, loongarch, devicetree, linux-mips,
Keguang Zhang
In-Reply-To: <20260119-tricking-premiere-ada70700f804@spud>
On 19/01/2026 18:24:36+0000, Conor Dooley wrote:
> On Sat, Jan 17, 2026 at 10:26:48AM +0800, Binbin Zhou wrote:
> > The `interrupts` property indicates an RTC alarm interrupt, which is
> > required for RTCs that support the alarm feature, which is not supported
> > by the Loongson-1C RTC. We exclude it for a more accurate description.
> >
> > Changing the `allowed` property is ABI-breaking behavior, but
> > throughout the existing Loongson DTS{i}, the description of the RTC
> > nodes conforms to the modified bingding rules.
>
> Right, changing properties is an ABI break, but when following the ABI
> would've produced something non-functional, breaking it is not really
> relevant.
But the HW has the interrupt, the fact that is not functional doesn't
mean it isn't there. I thought we should describe the hardware?
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> pw-bot: not-applicable
>
> >
> > Thus, the existing Loongson DTS{i} will not be affected.
> >
> > Fixes: 487ef32caebe ("dt-bindings: rtc: Split loongson,ls2x-rtc into SoC-based compatibles")
> > Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
> > Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
> > ---
> > .../devicetree/bindings/rtc/loongson,rtc.yaml | 11 +++++++++++
> > 1 file changed, 11 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
> > index f89c1f660aee..fac90a18153e 100644
> > --- a/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
> > +++ b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
> > @@ -42,6 +42,17 @@ required:
> >
> > unevaluatedProperties: false
> >
> > +if:
> > + properties:
> > + compatible:
> > + contains:
> > + enum:
> > + - loongson,ls1c-rtc
> > +
> > +then:
> > + properties:
> > + interrupts: false
> > +
> > examples:
> > - |
> > #include <dt-bindings/interrupt-controller/irq.h>
> > --
> > 2.47.3
> >
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [RFC PATCH v3 1/5] rtc: add device selector for rtc_class_ops callbacks
From: Ke Sun @ 2026-01-20 8:01 UTC (permalink / raw)
To: Danilo Krummrich, Ke Sun
Cc: Alexandre Belloni, Miguel Ojeda, Boqun Feng, Gary Guo,
Björn Roy Baron, Benno Lossin, Andreas Hindborg, Alice Ryhl,
Trevor Gross, linux-rtc, rust-for-linux, Greg Kroah-Hartman,
Rafael J. Wysocki
In-Reply-To: <DFSN0O9RRVD6.1LCI38JKGO1R0@kernel.org>
On 1/19/26 22:32, Danilo Krummrich wrote:
> On Fri Jan 16, 2026 at 5:21 PM CET, Ke Sun wrote:
>> diff --git a/drivers/rtc/dev.c b/drivers/rtc/dev.c
>> index baf1a8ca8b2b1..eddcc5a69db3b 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_ops_dev(rtc), ¶m);
>> else
>> err = -EINVAL;
>> }
> <snip>
>
>> +/**
>> + * rtc_ops_dev - Get the device pointer for RTC ops callbacks
>> + * @rtc: RTC device
>> + *
>> + * Returns &rtc->dev if RTC_OPS_USE_RTC_DEV flag is set,
>> + * otherwise returns rtc->dev.parent.
>> + */
>> +static inline struct device *rtc_ops_dev(struct rtc_device *rtc)
>> +{
>> + if (test_bit(RTC_OPS_USE_RTC_DEV, &rtc->flags))
>> + return &rtc->dev;
>> + return rtc->dev.parent;
>> +}
> I understand that the idea is to gradually convert all drivers to use the RTC
> device, rather than it's parent device in RTC device callbacks.
>
> My main concern is that once that has been achieved it's still not what we want
> to have eventually, i.e. RTC device callbacks should ideally take a struct
> rtc_device as argument and not the embedded base struct device.
>
> I.e. we'd kick off a conversion process that won't reach the actual desired
> state.
Hi Danilo,
This is indeed an intermediate step.
Full cleanup is in progress, but it's large and untested. I'm working on a
complete cleanup involving ~190+ files across arch/, drivers/rtc/, and
drivers/virtio/. Most changes are straightforward interface replacements,
but some drivers need additional modifications. Given the scale, I haven't
fully tested everything and can't guarantee correctness yet.
The intermediate step enables gradual migration, allowing us to:
- Clean up and test each rtc driver incrementally
- Ensure correctness through gradual changes
- Avoid breaking existing functionality
Once all cleanup is complete and tested, changing all rtc_class_ops
callbacks to use struct rtc_device * will be much simpler and safer.
Currently there seem to be only these two approaches. I'm still waiting
for Alexandre's suggestion on how to proceed specifically, but haven't
received a response yet.
Best regard,
Ke Sun
^ permalink raw reply
* Re: [PATCH v2 0/3] Samsung mfd/rtc driver alarm IRQ simplification
From: Lee Jones @ 2026-01-20 15:49 UTC (permalink / raw)
To: Krzysztof Kozlowski, Lee Jones, Alexandre Belloni,
André Draszik
Cc: Peter Griffin, Tudor Ambarus, Will McVicker, Juan Yescas,
Douglas Anderson, kernel-team, Kaustabh Chakraborty, linux-kernel,
linux-samsung-soc, linux-rtc
In-Reply-To: <20251120-s5m-alarm-v2-0-cc15f0e32161@linaro.org>
On Thu, 20 Nov 2025 14:38:03 +0000, André Draszik wrote:
> 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).
>
> [...]
Applied, thanks!
[1/3] mfd: sec: add rtc alarm IRQ as platform device resource
(no commit info)
[2/3] rtc: s5m: query platform device IRQ resource for alarm IRQ
commit: c70aee3dd85482c67720eb642d59ebbb9433faa5
[3/3] mfd: sec: drop now unused struct sec_pmic_dev::irq_data
(no commit info)
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v3 0/3] Samsung mfd/rtc driver alarm IRQ simplification
From: Lee Jones @ 2026-01-20 15:49 UTC (permalink / raw)
To: Krzysztof Kozlowski, Lee Jones, Alexandre Belloni,
André Draszik
Cc: Peter Griffin, Tudor Ambarus, Will McVicker, Juan Yescas,
Douglas Anderson, kernel-team, Kaustabh Chakraborty, linux-kernel,
linux-samsung-soc, linux-rtc
In-Reply-To: <20260113-s5m-alarm-v3-0-855a19db1277@linaro.org>
On Tue, 13 Jan 2026 14:03:10 +0000, André Draszik wrote:
> 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).
>
> [...]
Applied, thanks!
[1/3] mfd: sec: add rtc alarm IRQ as platform device resource
commit: 153ae5c52b7063ac0926926d0cc9b53ee9d7fed2
[2/3] rtc: s5m: query platform device IRQ resource for alarm IRQ
commit: c70aee3dd85482c67720eb642d59ebbb9433faa5
[3/3] mfd: sec: drop now unused struct sec_pmic_dev::irq_data
commit: b31583a1a9ab32923734ceb5fc95e536dfacccf7
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v3 0/3] Samsung mfd/rtc driver alarm IRQ simplification
From: Lee Jones @ 2026-01-20 15:50 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alexandre Belloni, André Draszik
Cc: Peter Griffin, Tudor Ambarus, Will McVicker, Juan Yescas,
Douglas Anderson, kernel-team, Kaustabh Chakraborty, linux-kernel,
linux-samsung-soc, linux-rtc
In-Reply-To: <176892416020.2292562.12972171855041051987.b4-ty@kernel.org>
On Tue, 20 Jan 2026, Lee Jones wrote:
> On Tue, 13 Jan 2026 14:03:10 +0000, André Draszik wrote:
> > 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).
> >
> > [...]
>
> Applied, thanks!
>
> [1/3] mfd: sec: add rtc alarm IRQ as platform device resource
> commit: 153ae5c52b7063ac0926926d0cc9b53ee9d7fed2
> [2/3] rtc: s5m: query platform device IRQ resource for alarm IRQ
> commit: c70aee3dd85482c67720eb642d59ebbb9433faa5
> [3/3] mfd: sec: drop now unused struct sec_pmic_dev::irq_data
> commit: b31583a1a9ab32923734ceb5fc95e536dfacccf7
Submitted for testing. Pull-request to follow.
For my own reference: ib-mfd-rtc-6.20
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v2 0/3] Samsung mfd/rtc driver alarm IRQ simplification
From: Lee Jones @ 2026-01-20 15:52 UTC (permalink / raw)
To: Krzysztof Kozlowski, Alexandre Belloni, André Draszik, tools,
users
Cc: Peter Griffin, Tudor Ambarus, Will McVicker, Juan Yescas,
Douglas Anderson, kernel-team, Kaustabh Chakraborty, linux-kernel,
linux-samsung-soc, linux-rtc
In-Reply-To: <176892415694.2292562.7457528145774108517.b4-ty@kernel.org>
On Tue, 20 Jan 2026, Lee Jones wrote:
> On Thu, 20 Nov 2025 14:38:03 +0000, André Draszik wrote:
> > 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).
> >
> > [...]
>
> Applied, thanks!
>
> [1/3] mfd: sec: add rtc alarm IRQ as platform device resource
> (no commit info)
> [2/3] rtc: s5m: query platform device IRQ resource for alarm IRQ
> commit: c70aee3dd85482c67720eb642d59ebbb9433faa5
> [3/3] mfd: sec: drop now unused struct sec_pmic_dev::irq_data
> (no commit info)
Looks like b4 is having a bad day.
I just applied v3, not this set.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v2 0/3] Samsung mfd/rtc driver alarm IRQ simplification
From: Mark Brown @ 2026-01-20 15:58 UTC (permalink / raw)
To: Lee Jones
Cc: Krzysztof Kozlowski, Alexandre Belloni, André Draszik, tools,
users, Peter Griffin, Tudor Ambarus, Will McVicker, Juan Yescas,
Douglas Anderson, kernel-team, Kaustabh Chakraborty, linux-kernel,
linux-samsung-soc, linux-rtc
In-Reply-To: <20260120155241.GG1354723@google.com>
[-- Attachment #1: Type: text/plain, Size: 731 bytes --]
On Tue, Jan 20, 2026 at 03:52:41PM +0000, Lee Jones wrote:
> On Tue, 20 Jan 2026, Lee Jones wrote:
> > [1/3] mfd: sec: add rtc alarm IRQ as platform device resource
> > (no commit info)
> > [2/3] rtc: s5m: query platform device IRQ resource for alarm IRQ
> > commit: c70aee3dd85482c67720eb642d59ebbb9433faa5
> > [3/3] mfd: sec: drop now unused struct sec_pmic_dev::irq_data
> > (no commit info)
> Looks like b4 is having a bad day.
> I just applied v3, not this set.
If you fetch a series but don't delete it from the database then (with
b4 ty -d) then b4 will remember it and if any commits in what gets
applied match it'll generate a mail for b4 ty -a. Usually that's when
some commits didn't get changed.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 0/3] Samsung mfd/rtc driver alarm IRQ simplification
From: Lee Jones @ 2026-01-20 17:24 UTC (permalink / raw)
To: Mark Brown
Cc: Krzysztof Kozlowski, Alexandre Belloni, André Draszik, tools,
users, Peter Griffin, Tudor Ambarus, Will McVicker, Juan Yescas,
Douglas Anderson, kernel-team, Kaustabh Chakraborty, linux-kernel,
linux-samsung-soc, linux-rtc
In-Reply-To: <e9bde783-42f3-4f28-9a5e-aa65f36db9ca@sirena.org.uk>
On Tue, 20 Jan 2026, Mark Brown wrote:
> On Tue, Jan 20, 2026 at 03:52:41PM +0000, Lee Jones wrote:
> > On Tue, 20 Jan 2026, Lee Jones wrote:
>
> > > [1/3] mfd: sec: add rtc alarm IRQ as platform device resource
> > > (no commit info)
> > > [2/3] rtc: s5m: query platform device IRQ resource for alarm IRQ
> > > commit: c70aee3dd85482c67720eb642d59ebbb9433faa5
> > > [3/3] mfd: sec: drop now unused struct sec_pmic_dev::irq_data
> > > (no commit info)
>
> > Looks like b4 is having a bad day.
>
> > I just applied v3, not this set.
>
> If you fetch a series but don't delete it from the database then (with
> b4 ty -d) then b4 will remember it and if any commits in what gets
> applied match it'll generate a mail for b4 ty -a. Usually that's when
> some commits didn't get changed.
The last attempt to apply this failed with conflicts.
I wonder why b4 stored that as a success?
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v2 0/3] Samsung mfd/rtc driver alarm IRQ simplification
From: Mark Brown @ 2026-01-20 17:28 UTC (permalink / raw)
To: Lee Jones
Cc: Krzysztof Kozlowski, Alexandre Belloni, André Draszik, tools,
users, Peter Griffin, Tudor Ambarus, Will McVicker, Juan Yescas,
Douglas Anderson, kernel-team, Kaustabh Chakraborty, linux-kernel,
linux-samsung-soc, linux-rtc
In-Reply-To: <20260120172405.GI1354723@google.com>
[-- Attachment #1: Type: text/plain, Size: 770 bytes --]
On Tue, Jan 20, 2026 at 05:24:05PM +0000, Lee Jones wrote:
> On Tue, 20 Jan 2026, Mark Brown wrote:
> > If you fetch a series but don't delete it from the database then (with
> > b4 ty -d) then b4 will remember it and if any commits in what gets
> > applied match it'll generate a mail for b4 ty -a. Usually that's when
> > some commits didn't get changed.
> The last attempt to apply this failed with conflicts.
> I wonder why b4 stored that as a success?
Are you using b4 shazam? I wonder if under the hood it's a mailbox
fetch then an apply. I download a mailbox then script my own
application after the fact so it's not so surprising that it happens for
me, b4 knows nothing about the patches actually being applied until I
tell it to go look to send thanks.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: rtc: loongson: Correct Loongson-1C interrupts property
From: Conor Dooley @ 2026-01-20 19:24 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Binbin Zhou, Binbin Zhou, Huacai Chen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-rtc, Xiaochuang Mao,
Huacai Chen, Xuerui Wang, loongarch, devicetree, linux-mips,
Keguang Zhang
In-Reply-To: <20260120075045e7e864ba@mail.local>
[-- Attachment #1: Type: text/plain, Size: 2671 bytes --]
On Tue, Jan 20, 2026 at 08:50:45AM +0100, Alexandre Belloni wrote:
> On 19/01/2026 18:24:36+0000, Conor Dooley wrote:
> > On Sat, Jan 17, 2026 at 10:26:48AM +0800, Binbin Zhou wrote:
> > > The `interrupts` property indicates an RTC alarm interrupt, which is
> > > required for RTCs that support the alarm feature, which is not supported
> > > by the Loongson-1C RTC. We exclude it for a more accurate description.
> > >
> > > Changing the `allowed` property is ABI-breaking behavior, but
> > > throughout the existing Loongson DTS{i}, the description of the RTC
> > > nodes conforms to the modified bingding rules.
> >
> > Right, changing properties is an ABI break, but when following the ABI
> > would've produced something non-functional, breaking it is not really
> > relevant.
>
>
> But the HW has the interrupt, the fact that is not functional doesn't
> mean it isn't there. I thought we should describe the hardware?
Does the hardware have it? My interpretation of the commit message was
that it didn't have the alarm feature and thus no interrupt? Unless the
interrupt has some other purpose, in which case yeah we shouldn't accept
this change and only the new device should permit there being no
interrupt.
>
> > Acked-by: Conor Dooley <conor.dooley@microchip.com>
> > pw-bot: not-applicable
> >
> > >
> > > Thus, the existing Loongson DTS{i} will not be affected.
> > >
> > > Fixes: 487ef32caebe ("dt-bindings: rtc: Split loongson,ls2x-rtc into SoC-based compatibles")
> > > Reviewed-by: Huacai Chen <chenhuacai@loongson.cn>
> > > Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
> > > ---
> > > .../devicetree/bindings/rtc/loongson,rtc.yaml | 11 +++++++++++
> > > 1 file changed, 11 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
> > > index f89c1f660aee..fac90a18153e 100644
> > > --- a/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
> > > +++ b/Documentation/devicetree/bindings/rtc/loongson,rtc.yaml
> > > @@ -42,6 +42,17 @@ required:
> > >
> > > unevaluatedProperties: false
> > >
> > > +if:
> > > + properties:
> > > + compatible:
> > > + contains:
> > > + enum:
> > > + - loongson,ls1c-rtc
> > > +
> > > +then:
> > > + properties:
> > > + interrupts: false
> > > +
> > > examples:
> > > - |
> > > #include <dt-bindings/interrupt-controller/irq.h>
> > > --
> > > 2.47.3
> > >
>
>
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: rtc: loongson: Correct Loongson-1C interrupts property
From: Alexandre Belloni @ 2026-01-20 22:49 UTC (permalink / raw)
To: Conor Dooley
Cc: Binbin Zhou, Binbin Zhou, Huacai Chen, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-rtc, Xiaochuang Mao,
Huacai Chen, Xuerui Wang, loongarch, devicetree, linux-mips,
Keguang Zhang
In-Reply-To: <20260120-cubical-harmonica-a7b7bbb26b08@spud>
On 20/01/2026 19:24:09+0000, Conor Dooley wrote:
> On Tue, Jan 20, 2026 at 08:50:45AM +0100, Alexandre Belloni wrote:
> > On 19/01/2026 18:24:36+0000, Conor Dooley wrote:
> > > On Sat, Jan 17, 2026 at 10:26:48AM +0800, Binbin Zhou wrote:
> > > > The `interrupts` property indicates an RTC alarm interrupt, which is
> > > > required for RTCs that support the alarm feature, which is not supported
> > > > by the Loongson-1C RTC. We exclude it for a more accurate description.
> > > >
> > > > Changing the `allowed` property is ABI-breaking behavior, but
> > > > throughout the existing Loongson DTS{i}, the description of the RTC
> > > > nodes conforms to the modified bingding rules.
> > >
> > > Right, changing properties is an ABI break, but when following the ABI
> > > would've produced something non-functional, breaking it is not really
> > > relevant.
> >
> >
> > But the HW has the interrupt, the fact that is not functional doesn't
> > mean it isn't there. I thought we should describe the hardware?
>
> Does the hardware have it? My interpretation of the commit message was
> that it didn't have the alarm feature and thus no interrupt? Unless the
> interrupt has some other purpose, in which case yeah we shouldn't accept
> this change and only the new device should permit there being no
> interrupt.
The datasheet shows the interrupt coming out of the RTC and it has the
proper registers. Why it is not functional is not clear to me.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ 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