* [PATCH 3/7] clk: sunxi-ng: sun6i-rtc: Add feature bit for IOSC calibration
From: Junhui Liu @ 2026-01-21 10:59 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Ripard
Cc: linux-clk, linux-arm-kernel, linux-sunxi, linux-kernel, linux-rtc,
devicetree, Junhui Liu
In-Reply-To: <20260121-a733-rtc-v1-0-d359437f23a7@pigmoral.tech>
The sun6i-rtc CCU driver currently uses a global static variable to
denote whether calibration is supported, which makes IOSC operations
tightly coupled to this file.
Convert this into a feature bit to decouple the logic. This allows the
IOSC clock code to be moved into a shared module for reuse by other SoCs.
Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
---
drivers/clk/sunxi-ng/ccu-sun6i-rtc.c | 17 +++++++++--------
drivers/clk/sunxi-ng/ccu_common.h | 1 +
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
index 3088f247d927..6f888169412c 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
@@ -53,8 +53,6 @@ struct sun6i_rtc_match_data {
u8 osc32k_fanout_nparents;
};
-static bool have_iosc_calibration;
-
static int ccu_iosc_enable(struct clk_hw *hw)
{
struct ccu_common *cm = hw_to_ccu_common(hw);
@@ -81,7 +79,7 @@ static unsigned long ccu_iosc_recalc_rate(struct clk_hw *hw,
{
struct ccu_common *cm = hw_to_ccu_common(hw);
- if (have_iosc_calibration) {
+ if (cm->features & CCU_FEATURE_IOSC_CALIBRATION) {
u32 reg = readl(cm->base + IOSC_CLK_CALI_REG);
/*
@@ -120,7 +118,7 @@ static int ccu_iosc_32k_prepare(struct clk_hw *hw)
struct ccu_common *cm = hw_to_ccu_common(hw);
u32 val;
- if (!have_iosc_calibration)
+ if (!(cm->features & CCU_FEATURE_IOSC_CALIBRATION))
return 0;
val = readl(cm->base + IOSC_CLK_CALI_REG);
@@ -135,7 +133,7 @@ static void ccu_iosc_32k_unprepare(struct clk_hw *hw)
struct ccu_common *cm = hw_to_ccu_common(hw);
u32 val;
- if (!have_iosc_calibration)
+ if (!(cm->features & CCU_FEATURE_IOSC_CALIBRATION))
return;
val = readl(cm->base + IOSC_CLK_CALI_REG);
@@ -149,7 +147,7 @@ static unsigned long ccu_iosc_32k_recalc_rate(struct clk_hw *hw,
struct ccu_common *cm = hw_to_ccu_common(hw);
u32 val;
- if (have_iosc_calibration) {
+ if (cm->features & CCU_FEATURE_IOSC_CALIBRATION) {
val = readl(cm->base + IOSC_CLK_CALI_REG);
/* Assume the calibrated 32k clock is accurate. */
@@ -168,7 +166,7 @@ static unsigned long ccu_iosc_32k_recalc_accuracy(struct clk_hw *hw,
struct ccu_common *cm = hw_to_ccu_common(hw);
u32 val;
- if (have_iosc_calibration) {
+ if (cm->features & CCU_FEATURE_IOSC_CALIBRATION) {
val = readl(cm->base + IOSC_CLK_CALI_REG);
/* Assume the calibrated 32k clock is accurate. */
@@ -366,7 +364,10 @@ static int sun6i_rtc_ccu_probe(struct auxiliary_device *adev,
return 0;
data = match->data;
- have_iosc_calibration = data->have_iosc_calibration;
+ if (data->have_iosc_calibration) {
+ iosc_clk.features |= CCU_FEATURE_IOSC_CALIBRATION;
+ iosc_32k_clk.features |= CCU_FEATURE_IOSC_CALIBRATION;
+ }
if (data->have_ext_osc32k) {
const char *fw_name;
diff --git a/drivers/clk/sunxi-ng/ccu_common.h b/drivers/clk/sunxi-ng/ccu_common.h
index bbec283b9d99..d9dc24ad5503 100644
--- a/drivers/clk/sunxi-ng/ccu_common.h
+++ b/drivers/clk/sunxi-ng/ccu_common.h
@@ -21,6 +21,7 @@
#define CCU_FEATURE_CLOSEST_RATE BIT(9)
#define CCU_FEATURE_DUAL_DIV BIT(10)
#define CCU_FEATURE_UPDATE_BIT BIT(11)
+#define CCU_FEATURE_IOSC_CALIBRATION BIT(12)
/* MMC timing mode switch bit */
#define CCU_MMC_NEW_TIMING_MODE BIT(30)
--
2.52.0
^ permalink raw reply related
* [PATCH 2/7] rtc: sun6i: Bind internal CCU via auxiliary bus
From: Junhui Liu @ 2026-01-21 10:59 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Ripard
Cc: linux-clk, linux-arm-kernel, linux-sunxi, linux-kernel, linux-rtc,
devicetree, Junhui Liu
In-Reply-To: <20260121-a733-rtc-v1-0-d359437f23a7@pigmoral.tech>
The sun6i RTC block contains an internal clock control unit (CCU).
Currently, the RTC driver binds this CCU part by directly calling a
probe function exported by the clock framework. This creates a tight
coupling between the RTC and clock drivers and makes it difficult to
add internal CCU support for new SoCs.
Switch to use the auxiliary bus for binding the internal CCU to
decouple the drivers.
Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
---
drivers/clk/sunxi-ng/ccu-sun6i-rtc.c | 29 +++++++++++++++++++++++------
drivers/rtc/rtc-sun6i.c | 31 +++++++++++++++++++++++--------
include/linux/clk/sunxi-ng.h | 2 --
3 files changed, 46 insertions(+), 16 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
index f6bfeba009e8..3088f247d927 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
@@ -3,6 +3,7 @@
// Copyright (c) 2021 Samuel Holland <samuel@sholland.org>
//
+#include <linux/auxiliary_bus.h>
#include <linux/clk.h>
#include <linux/clk-provider.h>
#include <linux/device.h>
@@ -11,8 +12,6 @@
#include <linux/of.h>
#include <linux/of_device.h>
-#include <linux/clk/sunxi-ng.h>
-
#include "ccu_common.h"
#include "ccu_div.h"
@@ -44,6 +43,8 @@
#define DCXO_CTRL_REG 0x160
#define DCXO_CTRL_CLK16M_RC_EN BIT(0)
+#define SUN6I_RTC_AUX_ID(_name) "rtc_sun6i." #_name
+
struct sun6i_rtc_match_data {
bool have_ext_osc32k : 1;
bool have_iosc_calibration : 1;
@@ -349,14 +350,18 @@ static const struct of_device_id sun6i_rtc_ccu_match[] = {
};
MODULE_DEVICE_TABLE(of, sun6i_rtc_ccu_match);
-int sun6i_rtc_ccu_probe(struct device *dev, void __iomem *reg)
+static int sun6i_rtc_ccu_probe(struct auxiliary_device *adev,
+ const struct auxiliary_device_id *id)
{
const struct sun6i_rtc_match_data *data;
struct clk *ext_osc32k_clk = NULL;
const struct of_device_id *match;
+ struct device *dev = &adev->dev;
+ void __iomem *reg = dev->platform_data;
+ struct device *parent = dev->parent;
/* This driver is only used for newer variants of the hardware. */
- match = of_match_device(sun6i_rtc_ccu_match, dev);
+ match = of_match_device(sun6i_rtc_ccu_match, parent);
if (!match)
return 0;
@@ -367,9 +372,9 @@ int sun6i_rtc_ccu_probe(struct device *dev, void __iomem *reg)
const char *fw_name;
/* ext-osc32k was the only input clock in the old binding. */
- fw_name = of_property_present(dev->of_node, "clock-names")
+ fw_name = of_property_present(parent->of_node, "clock-names")
? "ext-osc32k" : NULL;
- ext_osc32k_clk = devm_clk_get_optional(dev, fw_name);
+ ext_osc32k_clk = devm_clk_get_optional(parent, fw_name);
if (IS_ERR(ext_osc32k_clk))
return PTR_ERR(ext_osc32k_clk);
}
@@ -392,6 +397,18 @@ int sun6i_rtc_ccu_probe(struct device *dev, void __iomem *reg)
return devm_sunxi_ccu_probe(dev, reg, &sun6i_rtc_ccu_desc);
}
+static const struct auxiliary_device_id sun6i_ccu_rtc_ids[] = {
+ { .name = SUN6I_RTC_AUX_ID(sun6i) },
+ { /* sentinel */ }
+};
+MODULE_DEVICE_TABLE(auxiliary, sun6i_ccu_rtc_ids);
+
+static struct auxiliary_driver sun6i_ccu_rtc_driver = {
+ .probe = sun6i_rtc_ccu_probe,
+ .id_table = sun6i_ccu_rtc_ids,
+};
+module_auxiliary_driver(sun6i_ccu_rtc_driver);
+
MODULE_IMPORT_NS("SUNXI_CCU");
MODULE_DESCRIPTION("Support for the Allwinner H616/R329 RTC CCU");
MODULE_LICENSE("GPL");
diff --git a/drivers/rtc/rtc-sun6i.c b/drivers/rtc/rtc-sun6i.c
index e5e6013d080e..b4489e0a09ce 100644
--- a/drivers/rtc/rtc-sun6i.c
+++ b/drivers/rtc/rtc-sun6i.c
@@ -11,9 +11,9 @@
* Copyright (c) 2013, Carlo Caione <carlo.caione@gmail.com>
*/
+#include <linux/auxiliary_bus.h>
#include <linux/clk.h>
#include <linux/clk-provider.h>
-#include <linux/clk/sunxi-ng.h>
#include <linux/delay.h>
#include <linux/err.h>
#include <linux/fs.h>
@@ -141,6 +141,11 @@ struct sun6i_rtc_clk_data {
#define RTC_LINEAR_DAY BIT(0)
+struct sun6i_rtc_match_data {
+ const char *adev_name;
+ unsigned long flags;
+};
+
struct sun6i_rtc_dev {
struct rtc_device *rtc;
const struct sun6i_rtc_clk_data *data;
@@ -745,8 +750,10 @@ static void sun6i_rtc_bus_clk_cleanup(void *data)
static int sun6i_rtc_probe(struct platform_device *pdev)
{
+ const struct sun6i_rtc_match_data *data;
struct sun6i_rtc_dev *chip = sun6i_rtc;
struct device *dev = &pdev->dev;
+ struct auxiliary_device *adev;
struct clk *bus_clk;
int ret;
@@ -765,6 +772,8 @@ static int sun6i_rtc_probe(struct platform_device *pdev)
return ret;
}
+ data = of_device_get_match_data(&pdev->dev);
+
if (!chip) {
chip = devm_kzalloc(&pdev->dev, sizeof(*chip), GFP_KERNEL);
if (!chip)
@@ -776,16 +785,17 @@ static int sun6i_rtc_probe(struct platform_device *pdev)
if (IS_ERR(chip->base))
return PTR_ERR(chip->base);
- if (IS_REACHABLE(CONFIG_SUN6I_RTC_CCU)) {
- ret = sun6i_rtc_ccu_probe(dev, chip->base);
- if (ret)
- return ret;
+ if (data && data->adev_name) {
+ adev = devm_auxiliary_device_create(dev, data->adev_name, chip->base);
+ if (!adev)
+ return -ENODEV;
}
}
platform_set_drvdata(pdev, chip);
- chip->flags = (unsigned long)of_device_get_match_data(&pdev->dev);
+ if (data)
+ chip->flags = data->flags;
chip->irq = platform_get_irq(pdev, 0);
if (chip->irq < 0)
@@ -850,6 +860,11 @@ static int sun6i_rtc_probe(struct platform_device *pdev)
return 0;
}
+static const struct sun6i_rtc_match_data sun6i_rtc_match_data = {
+ .adev_name = "sun6i",
+ .flags = RTC_LINEAR_DAY,
+};
+
/*
* As far as RTC functionality goes, all models are the same. The
* datasheets claim that different models have different number of
@@ -865,9 +880,9 @@ static const struct of_device_id sun6i_rtc_dt_ids[] = {
{ .compatible = "allwinner,sun50i-h5-rtc" },
{ .compatible = "allwinner,sun50i-h6-rtc" },
{ .compatible = "allwinner,sun50i-h616-rtc",
- .data = (void *)RTC_LINEAR_DAY },
+ .data = &sun6i_rtc_match_data },
{ .compatible = "allwinner,sun50i-r329-rtc",
- .data = (void *)RTC_LINEAR_DAY },
+ .data = &sun6i_rtc_match_data },
{ /* sentinel */ },
};
MODULE_DEVICE_TABLE(of, sun6i_rtc_dt_ids);
diff --git a/include/linux/clk/sunxi-ng.h b/include/linux/clk/sunxi-ng.h
index 57c8ec44ab4e..cf32123b39f5 100644
--- a/include/linux/clk/sunxi-ng.h
+++ b/include/linux/clk/sunxi-ng.h
@@ -9,6 +9,4 @@
int sunxi_ccu_set_mmc_timing_mode(struct clk *clk, bool new_mode);
int sunxi_ccu_get_mmc_timing_mode(struct clk *clk);
-int sun6i_rtc_ccu_probe(struct device *dev, void __iomem *reg);
-
#endif
--
2.52.0
^ permalink raw reply related
* [PATCH 1/7] dt-bindings: rtc: sun6i: Add Allwinner A733 support
From: Junhui Liu @ 2026-01-21 10:59 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Ripard
Cc: linux-clk, linux-arm-kernel, linux-sunxi, linux-kernel, linux-rtc,
devicetree, Junhui Liu
In-Reply-To: <20260121-a733-rtc-v1-0-d359437f23a7@pigmoral.tech>
The RTC module in the Allwinner A733 SoC is functionally compatible with
the sun6i RTC, but its internal Clock Control Unit (CCU) has significant
changes.
The A733 supports selecting the oscillator between three frequencies:
19.2MHz, 24MHz, and 26MHz. The RTC CCU relies on hardware to detect
which frequency is actually used on the board. By defining all three
frequencies as fixed-clocks in the device tree, the driver can identify
the hardware-detected frequency and expose it to the rest of the system.
Additionally, the A733 RTC CCU provides several new DCXO gate clocks for
specific modules, including SerDes, HDMI, and UFS.
Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
---
.../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 38 ++++++++++++++++++++--
include/dt-bindings/clock/sun60i-a733-rtc.h | 16 +++++++++
2 files changed, 52 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
index 9df5cdb6f63f..b18431955783 100644
--- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
+++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml
@@ -26,6 +26,7 @@ properties:
- allwinner,sun50i-h6-rtc
- allwinner,sun50i-h616-rtc
- allwinner,sun50i-r329-rtc
+ - allwinner,sun60i-a733-rtc
- items:
- const: allwinner,sun50i-a64-rtc
- const: allwinner,sun8i-h3-rtc
@@ -46,11 +47,11 @@ properties:
clocks:
minItems: 1
- maxItems: 4
+ maxItems: 6
clock-names:
minItems: 1
- maxItems: 4
+ maxItems: 6
clock-output-names:
minItems: 1
@@ -156,6 +157,38 @@ allOf:
- clocks
- clock-names
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: allwinner,sun60i-a733-rtc
+
+ then:
+ properties:
+ clocks:
+ minItems: 5
+ items:
+ - description: Bus clock for register access
+ - description: 19.2 MHz oscillator
+ - description: 24 MHz oscillator
+ - description: 26 MHz oscillator
+ - description: AHB parent for internal SPI clock
+ - description: External 32768 Hz oscillator
+
+ clock-names:
+ minItems: 5
+ items:
+ - const: bus
+ - const: osc19M
+ - const: osc24M
+ - const: osc26M
+ - const: ahb
+ - const: ext-osc32k
+
+ required:
+ - clocks
+ - clock-names
+
- if:
properties:
compatible:
@@ -164,6 +197,7 @@ allOf:
- allwinner,sun8i-r40-rtc
- allwinner,sun50i-h616-rtc
- allwinner,sun50i-r329-rtc
+ - allwinner,sun60i-a733-rtc
then:
properties:
diff --git a/include/dt-bindings/clock/sun60i-a733-rtc.h b/include/dt-bindings/clock/sun60i-a733-rtc.h
new file mode 100644
index 000000000000..8a2b5facad73
--- /dev/null
+++ b/include/dt-bindings/clock/sun60i-a733-rtc.h
@@ -0,0 +1,16 @@
+/* SPDX-License-Identifier: GPL-2.0-only OR MIT */
+
+#ifndef _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_
+#define _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_
+
+#define CLK_IOSC 0
+#define CLK_OSC32K 1
+#define CLK_HOSC 2
+#define CLK_RTC_32K 3
+#define CLK_OSC32K_FANOUT 4
+#define CLK_HOSC_SERDES1 5
+#define CLK_HOSC_SERDES0 6
+#define CLK_HOSC_HDMI 7
+#define CLK_HOSC_UFS 8
+
+#endif /* _DT_BINDINGS_CLK_SUN60I_A733_RTC_H_ */
--
2.52.0
^ permalink raw reply related
* [PATCH 0/7] rtc: sun6i: Add support for Allwinner A733 SoC
From: Junhui Liu @ 2026-01-21 10:59 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Ripard
Cc: linux-clk, linux-arm-kernel, linux-sunxi, linux-kernel, linux-rtc,
devicetree, Junhui Liu
Add support for the Allwinner A733 RTC and its internal Clock Control
Unit (CCU). Reuse the rtc-sun6i rtc driver while introducing a new
SoC-specific RTC CCU driver to handle the hardware's evolved clock
structure.
To facilitate this addition and improve driver modularity, transition
the binding between the RTC and its internal CCU from direct
cross-subsystem function calls to the auxiliary bus. Also extract shared
IOSC and 32kHz clock logic into a standalone ccu_rtc module for reuse
across newer SoC generations.
The A733 implementation supports hardware detection of three external
crystal frequencies (19.2MHz, 24MHz and 26MHz), which is represented in
the driver via read-only mux operations. Implement logic to derive a
normalized 32kHz reference from these DCXO sources using fixed
pre-dividers. Additionally, provide several new DCXO gate clocks for
peripherals, including SerDes, HDMI, and UFS.
---
Junhui Liu (7):
dt-bindings: rtc: sun6i: Add Allwinner A733 support
rtc: sun6i: Bind internal CCU via auxiliary bus
clk: sunxi-ng: sun6i-rtc: Add feature bit for IOSC calibration
clk: sunxi-ng: Extract common RTC CCU clock logic
clk: sunxi-ng: mux: Add mux read-only clock operations
rtc: sun6i: Add support for A733 RTC
clk: sunxi-ng: Add Allwinner A733 RTC CCU support
.../bindings/rtc/allwinner,sun6i-a31-rtc.yaml | 38 +++-
drivers/clk/sunxi-ng/Kconfig | 5 +
drivers/clk/sunxi-ng/Makefile | 5 +
drivers/clk/sunxi-ng/ccu-sun60i-a733-rtc.c | 204 +++++++++++++++++++++
drivers/clk/sunxi-ng/ccu-sun60i-a733-rtc.h | 18 ++
drivers/clk/sunxi-ng/ccu-sun6i-rtc.c | 184 +++----------------
drivers/clk/sunxi-ng/ccu_common.h | 1 +
drivers/clk/sunxi-ng/ccu_mux.c | 11 ++
drivers/clk/sunxi-ng/ccu_mux.h | 1 +
drivers/clk/sunxi-ng/ccu_rtc.c | 136 ++++++++++++++
drivers/clk/sunxi-ng/ccu_rtc.h | 44 +++++
drivers/rtc/rtc-sun6i.c | 38 +++-
include/dt-bindings/clock/sun60i-a733-rtc.h | 16 ++
include/linux/clk/sunxi-ng.h | 2 -
14 files changed, 533 insertions(+), 170 deletions(-)
---
base-commit: 24d479d26b25bce5faea3ddd9fa8f3a6c3129ea7
change-id: 20251226-a733-rtc-c5167df14e6e
Best regards,
--
Junhui Liu <junhui.liu@pigmoral.tech>
^ permalink raw reply
* Re: [PATCH v2 0/3] Samsung mfd/rtc driver alarm IRQ simplification
From: Lee Jones @ 2026-01-21 8:48 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: <916995f4-60e0-47dc-abdb-8819089d103c@sirena.org.uk>
On Tue, 20 Jan 2026, Mark Brown wrote:
> 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.
Not using shazam. This is my abbreviated workflow:
b4.sh am -3 -slt ${PATCHES} -o - ${id} > ${MBOX}
cat ${MBOX} | formail -ds ./scripts/checkpatch.pl || true
cat ${MBOX} | git am -3 --reject
kitty -o font_size=12 git rebase -i HEAD~${NOPATCHES}
b4.sh ty -aS --me-too --since=1.day
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v2 0/3] Samsung mfd/rtc driver alarm IRQ simplification
From: Lee Jones @ 2026-01-21 8:44 UTC (permalink / raw)
To: Konstantin Ryabitsev
Cc: Mark Brown, 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: <20260120-incredible-ladybug-of-psychology-605faf@lemur>
On Tue, 20 Jan 2026, Konstantin Ryabitsev wrote:
> On Tue, Jan 20, 2026 at 05:24:05PM +0000, Lee Jones 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?
>
> It doesn't actually know -- it just stores the retrieved series and then
> checks if it can find any of them in the tree in a commit with your
> authorship. Sometimes it breaks.
>
> My plan is to put in interactive mode where you can do a quick sanity check --
> currently it's all of nothing with "b4 ty -a".
Got it. Thanks for the explanation.
--
Lee Jones [李琼斯]
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: rtc: loongson: Correct Loongson-1C interrupts property
From: Binbin Zhou @ 2026-01-21 6:52 UTC (permalink / raw)
To: Conor Dooley
Cc: Alexandre Belloni, 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-proposal-retry-d0a1f3de10ea@spud>
Hi Conor & Alexandre:
Thanks for your reply.
On Wed, Jan 21, 2026 at 7:39 AM Conor Dooley <conor@kernel.org> wrote:
>
> On Tue, Jan 20, 2026 at 11:49:20PM +0100, Alexandre Belloni wrote:
> > 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.
>
> Right.. Perhaps Binbin can explain that then? If the interrupt is
> actually there then the dts should get fixed instead IMO.
I carefully reviewed the manual again and believe this patch is still necessary.
First, the Loongson-1C RTC does not define the timing interrupt
register (`TOY_MATCH0_REG`)[1], meaning it lacks hardware support for
alarms. Consequently, `interrupts` are also unnecessary.
The Loongson-2K0300 is different. It defines `TOY_MATCH0_REG`, but due
to a hardware design flaw, accessing this register causes system
crashes. Therefore, I must also classify it as lacking alarm support.
Additionally, in patch-3 [2], I rewrote the alarm logic to decouple
the `interrupts` property from the alarm feature: I defined
corresponding workaround bits in `loongson_rtc_config->flags`. This
should be considered a SoC-specific attribute.
Finally, two thoughts:
1. Retain this patch; it is correct for Loongson-1C.
2. For Patch-2, still add the `interrupts` property to the
Loongson-2K0300 RTC node (as it exists in hardware), combined with the
workaround bit setting in patch-3 to avoid the hardware flaw.
Would this approach be acceptable?
[1]: https://www.loongson.cn/uploads/images/2022051616223977135.%E9%BE%99%E8%8A%AF1C300%E5%A4%84%E7%90%86%E5%99%A8%E7%94%A8%E6%88%B7%E6%89%8B%E5%86%8C.pdf
(section 21.2.1)
[2]: https://lore.kernel.org/linux-rtc/abff68dda2fe6a6601a9e58b31e278d941297fce.1768616276.git.zhoubinbin@loongson.cn/
--
Thanks.
Binbin
^ permalink raw reply
* Re: [PATCH v2 0/3] Samsung mfd/rtc driver alarm IRQ simplification
From: Konstantin Ryabitsev @ 2026-01-21 3:23 UTC (permalink / raw)
To: Lee Jones
Cc: Mark Brown, 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>
On Tue, Jan 20, 2026 at 05:24:05PM +0000, Lee Jones 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?
It doesn't actually know -- it just stores the retrieved series and then
checks if it can find any of them in the tree in a commit with your
authorship. Sometimes it breaks.
My plan is to put in interactive mode where you can do a quick sanity check --
currently it's all of nothing with "b4 ty -a".
-K
^ permalink raw reply
* Re: [PATCH v3 1/3] dt-bindings: rtc: loongson: Correct Loongson-1C interrupts property
From: Conor Dooley @ 2026-01-20 23:39 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: <20260120224920df0cf2ac@mail.local>
[-- Attachment #1: Type: text/plain, Size: 1733 bytes --]
On Tue, Jan 20, 2026 at 11:49:20PM +0100, Alexandre Belloni wrote:
> 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.
Right.. Perhaps Binbin can explain that then? If the interrupt is
actually there then the dts should get fixed instead IMO.
[-- 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
* 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 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 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 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 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 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 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 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: [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 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: [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] 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: 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: 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 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
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