* [PATCH v3 6/8] clk: sunxi-ng: div: add read-only operation support
From: Jerome Brunet @ 2026-07-02 8:10 UTC (permalink / raw)
To: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard
Cc: linux-rtc, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-clk, Jerome Brunet
In-Reply-To: <20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com>
Add support for sunxi-ng read-only dividers. This will be
useful to the a733 oscillator detection logic.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/sunxi-ng/ccu_div.c | 42 ++++++++++++++++++++++++++++++++++++++++++
drivers/clk/sunxi-ng/ccu_div.h | 1 +
drivers/clk/sunxi-ng/ccu_mux.c | 3 ++-
drivers/clk/sunxi-ng/ccu_mux.h | 4 ++++
4 files changed, 49 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/sunxi-ng/ccu_div.c b/drivers/clk/sunxi-ng/ccu_div.c
index 62d680ccb524..d1c8c7baa12d 100644
--- a/drivers/clk/sunxi-ng/ccu_div.c
+++ b/drivers/clk/sunxi-ng/ccu_div.c
@@ -84,6 +84,36 @@ static int ccu_div_determine_rate(struct clk_hw *hw,
req, ccu_div_determine_rate_helper, cd);
}
+static int ccu_rodiv_determine_rate(struct clk_hw *hw,
+ struct clk_rate_request *req)
+{
+ struct ccu_div *cd = hw_to_ccu_div(hw);
+ unsigned long val;
+ u32 reg;
+ int ret;
+
+ reg = readl(cd->common.base + cd->common.reg);
+ val = reg >> cd->div.shift;
+ val &= (1 << cd->div.width) - 1;
+
+ req->rate = ccu_mux_helper_unapply_prediv(&cd->common, &cd->mux, -1,
+ req->rate);
+
+ if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
+ req->rate *= cd->fixed_post_div;
+
+ ret = divider_ro_determine_rate(hw, req, cd->div.table,
+ cd->div.width, cd->div.flags, val);
+
+ if (cd->common.features & CCU_FEATURE_FIXED_POSTDIV)
+ req->rate /= cd->fixed_post_div;
+
+ req->rate = ccu_mux_helper_apply_prediv(&cd->common, &cd->mux, -1,
+ req->rate);
+
+ return ret;
+}
+
static int ccu_div_set_rate(struct clk_hw *hw, unsigned long rate,
unsigned long parent_rate)
{
@@ -143,3 +173,15 @@ const struct clk_ops ccu_div_ops = {
.set_rate = ccu_div_set_rate,
};
EXPORT_SYMBOL_NS_GPL(ccu_div_ops, "SUNXI_CCU");
+
+const struct clk_ops ccu_rodiv_ops = {
+ .disable = ccu_div_disable,
+ .enable = ccu_div_enable,
+ .is_enabled = ccu_div_is_enabled,
+
+ .get_parent = ccu_div_get_parent,
+
+ .determine_rate = ccu_rodiv_determine_rate,
+ .recalc_rate = ccu_div_recalc_rate,
+};
+EXPORT_SYMBOL_NS_GPL(ccu_rodiv_ops, "SUNXI_CCU");
diff --git a/drivers/clk/sunxi-ng/ccu_div.h b/drivers/clk/sunxi-ng/ccu_div.h
index be00b3277e97..a30a92780a05 100644
--- a/drivers/clk/sunxi-ng/ccu_div.h
+++ b/drivers/clk/sunxi-ng/ccu_div.h
@@ -300,5 +300,6 @@ static inline struct ccu_div *hw_to_ccu_div(struct clk_hw *hw)
}
extern const struct clk_ops ccu_div_ops;
+extern const struct clk_ops ccu_rodiv_ops;
#endif /* _CCU_DIV_H_ */
diff --git a/drivers/clk/sunxi-ng/ccu_mux.c b/drivers/clk/sunxi-ng/ccu_mux.c
index 766f27cff748..e2d6833a6d33 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.c
+++ b/drivers/clk/sunxi-ng/ccu_mux.c
@@ -68,13 +68,14 @@ unsigned long ccu_mux_helper_apply_prediv(struct ccu_common *common,
}
EXPORT_SYMBOL_NS_GPL(ccu_mux_helper_apply_prediv, "SUNXI_CCU");
-static unsigned long ccu_mux_helper_unapply_prediv(struct ccu_common *common,
+unsigned long ccu_mux_helper_unapply_prediv(struct ccu_common *common,
struct ccu_mux_internal *cm,
int parent_index,
unsigned long parent_rate)
{
return parent_rate * ccu_mux_get_prediv(common, cm, parent_index);
}
+EXPORT_SYMBOL_NS_GPL(ccu_mux_helper_unapply_prediv, "SUNXI_CCU");
int ccu_mux_helper_determine_rate(struct ccu_common *common,
struct ccu_mux_internal *cm,
diff --git a/drivers/clk/sunxi-ng/ccu_mux.h b/drivers/clk/sunxi-ng/ccu_mux.h
index c94a4bde5d01..272a2c36a8f2 100644
--- a/drivers/clk/sunxi-ng/ccu_mux.h
+++ b/drivers/clk/sunxi-ng/ccu_mux.h
@@ -134,6 +134,10 @@ unsigned long ccu_mux_helper_apply_prediv(struct ccu_common *common,
struct ccu_mux_internal *cm,
int parent_index,
unsigned long parent_rate);
+unsigned long ccu_mux_helper_unapply_prediv(struct ccu_common *common,
+ struct ccu_mux_internal *cm,
+ int parent_index,
+ unsigned long parent_rate);
int ccu_mux_helper_determine_rate(struct ccu_common *common,
struct ccu_mux_internal *cm,
struct clk_rate_request *req,
--
2.47.3
^ permalink raw reply related
* [PATCH v3 7/8] clk: sunxi-ng: sun6i-rtc: split main oscillator div and gate.
From: Jerome Brunet @ 2026-07-02 8:10 UTC (permalink / raw)
To: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard
Cc: linux-rtc, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-clk, Jerome Brunet
In-Reply-To: <20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com>
On the a733 the "osc24M-32k" clock has the same gate bits as the previously
supported SoC but a different divider implementation.
Instead of a fixed 750 divider, the divider is selected based on the
rate of the oscillator. It can be seen as a simple read-only divider.
To easily replace the divider part depending the SoC, split the divider
and gate into two separate clock entities.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/sunxi-ng/ccu-sun6i-rtc.c | 20 +++++++++++---------
drivers/clk/sunxi-ng/ccu-sun6i-rtc.h | 3 ++-
2 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
index b24c8b196e66..25dd87e78eb7 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
@@ -218,17 +218,18 @@ static const struct clk_parent_data osc24M[] = {
{ .fw_name = "hosc", .name = "osc24M" }
};
-static struct ccu_gate osc24M_32k_clk = {
- .enable = BIT(16),
- .common = {
- .reg = LOSC_OUT_GATING_REG,
- .prediv = 750,
- .features = CCU_FEATURE_ALL_PREDIV,
- .hw.init = CLK_HW_INIT_PARENTS_DATA("osc24M-32k", osc24M,
- &ccu_gate_ops, 0),
- },
+static struct clk_fixed_factor osc24M_32k_div_clk = {
+ .mult = 1,
+ .div = 750,
+ .hw.init = CLK_HW_INIT_PARENTS_DATA("osc24M-32k-div",
+ osc24M,
+ &clk_fixed_factor_ops,
+ 0),
};
+static SUNXI_CCU_GATE_HW(osc24M_32k_clk, "osc24M-32k", &osc24M_32k_div_clk.hw,
+ LOSC_OUT_GATING_REG, BIT(16), 0);
+
static const struct clk_hw *rtc_32k_parents[] = {
&osc32k_clk.common.hw,
&osc24M_32k_clk.common.hw
@@ -286,6 +287,7 @@ static struct clk_hw_onecell_data sun6i_rtc_ccu_hw_clks = {
[CLK_EXT_OSC32K_GATE] = &ext_osc32k_gate_clk.common.hw,
[CLK_OSC24M_32K] = &osc24M_32k_clk.common.hw,
[CLK_RTC_32K] = &rtc_32k_clk.common.hw,
+ [CLK_OSC24M_32K_DIV] = &osc24M_32k_div_clk.hw,
},
};
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
index 9ae821fc2599..ab7b92b47f59 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
@@ -9,7 +9,8 @@
#define CLK_EXT_OSC32K_GATE 4
#define CLK_OSC24M_32K 5
#define CLK_RTC_32K 6
+#define CLK_OSC24M_32K_DIV 7
-#define CLK_NUMBER (CLK_RTC_32K + 1)
+#define CLK_NUMBER (CLK_OSC24M_32K_DIV + 1)
#endif /* _CCU_SUN6I_RTC_H */
--
2.47.3
^ permalink raw reply related
* [PATCH v3 8/8] clk: sunxi-ng: sun6i-rtc: add a733 support
From: Jerome Brunet @ 2026-07-02 8:10 UTC (permalink / raw)
To: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard
Cc: linux-rtc, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-clk, Jerome Brunet
In-Reply-To: <20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com>
Add support for the sun60i a733 CCU RTC.
Compared to the a523, this SoC has a different input oscillator divider
which auto-detects the oscillator rate and select a divider to provide
a fixed 32768Hz clock. It also provides several phy reference clocks
with dedicated clock gates.
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
---
drivers/clk/sunxi-ng/ccu-sun6i-rtc.c | 73 ++++++++++++++++++++++++++++++++++--
drivers/clk/sunxi-ng/ccu-sun6i-rtc.h | 2 +-
2 files changed, 71 insertions(+), 4 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
index 25dd87e78eb7..6b71bbd80255 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c
@@ -44,9 +44,13 @@
#define DCXO_CTRL_REG 0x160
#define DCXO_CTRL_CLK16M_RC_EN BIT(0)
+#define DCXO_GATING_REG 0x16c
+
struct sun6i_rtc_match_data {
bool have_ext_osc32k : 1;
bool have_iosc_calibration : 1;
+ bool have_dcxo_status : 1;
+ bool have_phy_ref_gates : 1;
bool rtc_32k_single_parent : 1;
const struct clk_parent_data *osc32k_fanout_parents;
u8 osc32k_fanout_nparents;
@@ -213,7 +217,12 @@ static struct ccu_mux osc32k_clk = {
},
};
-/* This falls back to the global name for fwnodes without a named reference. */
+/*
+ * This falls back to the global name for fwnodes without a named reference.
+ * NOTE: osc24M name might be misleading the oscillator could also be a 26MHz
+ * or a 19.2MHz one starting with the a733. The original name is kept anyway
+ * in case anything is relying on it.
+ */
static const struct clk_parent_data osc24M[] = {
{ .fw_name = "hosc", .name = "osc24M" }
};
@@ -227,8 +236,28 @@ static struct clk_fixed_factor osc24M_32k_div_clk = {
0),
};
-static SUNXI_CCU_GATE_HW(osc24M_32k_clk, "osc24M-32k", &osc24M_32k_div_clk.hw,
- LOSC_OUT_GATING_REG, BIT(16), 0);
+static struct clk_div_table osc24M_32k_div_a733_table[] = {
+ { .val = 0, .div = 732 },
+ { .val = 1, .div = 586 },
+ { .val = 2, .div = 793 },
+ { .val = 3, .div = 732 },
+ { /* Sentinel */ },
+};
+
+static struct ccu_div osc24M_32k_div_a733_clk = {
+ .enable = BIT(1),
+ .div = _SUNXI_CCU_DIV_TABLE(14, 2, osc24M_32k_div_a733_table),
+ .common = {
+ .reg = DCXO_CTRL_REG,
+ .hw.init = CLK_HW_INIT_PARENTS_DATA("osc24M-32k-div",
+ osc24M,
+ &ccu_rodiv_ops,
+ 0),
+ },
+};
+
+static SUNXI_CCU_GATE(osc24M_32k_clk, "osc24M-32k", "osc24M-32k-div",
+ LOSC_OUT_GATING_REG, BIT(16), 0);
static const struct clk_hw *rtc_32k_parents[] = {
&osc32k_clk.common.hw,
@@ -267,6 +296,15 @@ static struct ccu_mux osc32k_fanout_clk = {
},
};
+static SUNXI_CCU_GATE_FW(hosc_serdes1_clk, "hosc-serdes1", "hosc",
+ DCXO_GATING_REG, BIT(5), 0);
+static SUNXI_CCU_GATE_FW(hosc_serdes0_clk, "hosc-serdes0", "hosc",
+ DCXO_GATING_REG, BIT(4), 0);
+static SUNXI_CCU_GATE_FW(hosc_hdmi_clk, "hosc-hdmi", "hosc",
+ DCXO_GATING_REG, BIT(1), 0);
+static SUNXI_CCU_GATE_FW(hosc_ufs_clk, "hosc-ufs", "hosc",
+ DCXO_GATING_REG, BIT(0), 0);
+
static struct ccu_common *sun6i_rtc_ccu_clks[] = {
&iosc_clk,
&iosc_32k_clk,
@@ -275,6 +313,11 @@ static struct ccu_common *sun6i_rtc_ccu_clks[] = {
&osc24M_32k_clk.common,
&rtc_32k_clk.common,
&osc32k_fanout_clk.common,
+ &osc24M_32k_div_a733_clk.common,
+ &hosc_serdes1_clk.common,
+ &hosc_serdes0_clk.common,
+ &hosc_hdmi_clk.common,
+ &hosc_ufs_clk.common,
};
static struct clk_hw_onecell_data sun6i_rtc_ccu_hw_clks = {
@@ -288,6 +331,10 @@ static struct clk_hw_onecell_data sun6i_rtc_ccu_hw_clks = {
[CLK_OSC24M_32K] = &osc24M_32k_clk.common.hw,
[CLK_RTC_32K] = &rtc_32k_clk.common.hw,
[CLK_OSC24M_32K_DIV] = &osc24M_32k_div_clk.hw,
+ [CLK_HOSC_UFS] = &hosc_ufs_clk.common.hw,
+ [CLK_HOSC_HDMI] = &hosc_hdmi_clk.common.hw,
+ [CLK_HOSC_SERDES0] = &hosc_serdes0_clk.common.hw,
+ [CLK_HOSC_SERDES1] = &hosc_serdes1_clk.common.hw,
},
};
@@ -330,6 +377,15 @@ static const struct sun6i_rtc_match_data sun55i_a523_rtc_ccu_data = {
.osc32k_fanout_nparents = ARRAY_SIZE(sun50i_r329_osc32k_fanout_parents),
};
+static const struct sun6i_rtc_match_data sun60i_a733_rtc_ccu_data = {
+ .have_ext_osc32k = true,
+ .have_iosc_calibration = true,
+ .have_dcxo_status = true,
+ .have_phy_ref_gates = true,
+ .osc32k_fanout_parents = sun50i_r329_osc32k_fanout_parents,
+ .osc32k_fanout_nparents = ARRAY_SIZE(sun50i_r329_osc32k_fanout_parents),
+};
+
static const struct of_device_id sun6i_rtc_ccu_match[] = {
{
.compatible = "allwinner,sun50i-h616-rtc",
@@ -343,6 +399,10 @@ static const struct of_device_id sun6i_rtc_ccu_match[] = {
.compatible = "allwinner,sun55i-a523-rtc",
.data = &sun55i_a523_rtc_ccu_data,
},
+ {
+ .compatible = "allwinner,sun60i-a733-rtc",
+ .data = &sun60i_a733_rtc_ccu_data,
+ },
{},
};
MODULE_DEVICE_TABLE(of, sun6i_rtc_ccu_match);
@@ -375,6 +435,13 @@ int sun6i_rtc_ccu_probe(struct device *dev, void __iomem *reg)
osc32k_fanout_init_data.parent_data = data->osc32k_fanout_parents;
osc32k_fanout_init_data.num_parents = data->osc32k_fanout_nparents;
+ if (data->have_dcxo_status)
+ sun6i_rtc_ccu_hw_clks.hws[CLK_OSC24M_32K_DIV] =
+ &osc24M_32k_div_a733_clk.common.hw;
+
+ if (!data->have_phy_ref_gates)
+ sun6i_rtc_ccu_hw_clks.num = CLK_OSC24M_32K_DIV + 1;
+
return devm_sunxi_ccu_probe(dev, reg, &sun6i_rtc_ccu_desc);
}
diff --git a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
index ab7b92b47f59..4f4f4cb00f1d 100644
--- a/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
+++ b/drivers/clk/sunxi-ng/ccu-sun6i-rtc.h
@@ -11,6 +11,6 @@
#define CLK_RTC_32K 6
#define CLK_OSC24M_32K_DIV 7
-#define CLK_NUMBER (CLK_OSC24M_32K_DIV + 1)
+#define CLK_NUMBER (CLK_HOSC_SERDES1 + 1)
#endif /* _CCU_SUN6I_RTC_H */
--
2.47.3
^ permalink raw reply related
* Re: [PATCH v3 3/8] clk: sunxi-ng: fix ccu probe clock unregister on error
From: sashiko-bot @ 2026-07-02 8:16 UTC (permalink / raw)
To: Jerome Brunet
Cc: robh, linux-sunxi, conor+dt, devicetree, linux-rtc,
Alexandre Belloni
In-Reply-To: <20260702-a733-rtc-v3-3-eb2580374de6@baylibre.com>
> When registering clocks with sunxi_ccu_probe(), the number of ccu_clocks
> and the number of hw clocks might be different, eventhough they usually are
> the same.
>
> If they are different, it could lead to out-of-bound access or registered
> clock left behind on error.
>
> Use a different variable when iterating on hw clocks so every registered
> clock, and only those, gets unregistered on error.
>
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/r/20260629131254.7E34C1F00A3A@smtp.kernel.org
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com?part=3
^ permalink raw reply
* Re: [PATCH v3 2/8] dt-bindings: rtc: sun6i: add sun60i-a733 support
From: sashiko-bot @ 2026-07-02 8:16 UTC (permalink / raw)
To: Jerome Brunet
Cc: linux-rtc, Alexandre Belloni, conor+dt, devicetree, linux-sunxi,
robh
In-Reply-To: <20260702-a733-rtc-v3-2-eb2580374de6@baylibre.com>
> Add a new rtc compatible for the sun60i-a733 SoC and new IDs for the
> peripheral oscillator clock gates of this SoC.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com?part=2
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: rtc: Add sii,wakealarm-output-pin property for S35390A
From: Alexandre Belloni @ 2026-07-02 8:17 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Markus Probst, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, linux-arm-kernel, linux-rtc, devicetree,
linux-kernel
In-Reply-To: <187099d0-5e09-49c2-b67d-8bd4366ff1a0@kernel.org>
On 02/07/2026 08:09:55+0200, Krzysztof Kozlowski wrote:
> >> Then you need proper wakeup-source support
> > Wouldn't that break existing devicetrees?
>
> How?
>
> >
> > The current driver allows to wake up the system, even without
> > having wakeup-source set.
>
> Anyway, wakeup-source is already there in rtc, so this would be done. I
> don't get though, why there is no benefit of routing it to interrupt
> controller (interrupt controllers do wake up the system). Additionally,
> if you do not connect it to any interrupt, then how does it wake up the
> system?
>
Some systems are routing the interrupt output of the RTC directly to the
PMIC and the PMIC is the one responsible for waking the rest of the
system, including the SoC.
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: rtc: sun6i: no clock-output-names on h616/r329
From: sashiko-bot @ 2026-07-02 8:17 UTC (permalink / raw)
To: Jerome Brunet
Cc: Alexandre Belloni, devicetree, linux-sunxi, linux-rtc, conor+dt,
robh
In-Reply-To: <20260702-a733-rtc-v3-1-eb2580374de6@baylibre.com>
> On h616 and r329 chips, clock output names are never defined through DT and
> are not meant to be. Just disallow the property for those chips.
>
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: http://lore.kernel.org/r/20260629125305.0DF981F000E9@smtp.kernel.org
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com?part=1
^ permalink raw reply
* Re: [PATCH v3 5/8] clk: sunxi-ng: sun6i-rtc: Add feature bit for IOSC calibration
From: sashiko-bot @ 2026-07-02 8:19 UTC (permalink / raw)
To: Jerome Brunet
Cc: linux-sunxi, robh, conor+dt, Alexandre Belloni, devicetree,
linux-rtc
In-Reply-To: <20260702-a733-rtc-v3-5-eb2580374de6@baylibre.com>
> From: Junhui Liu <junhui.liu@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>
> Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com?part=5
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: rtc: Add sii,wakealarm-output-pin property for S35390A
From: Krzysztof Kozlowski @ 2026-07-02 8:20 UTC (permalink / raw)
To: Alexandre Belloni
Cc: Markus Probst, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, linux-arm-kernel, linux-rtc, devicetree,
linux-kernel
In-Reply-To: <202607020817017cde494f@mail.local>
On 02/07/2026 10:17, Alexandre Belloni wrote:
> On 02/07/2026 08:09:55+0200, Krzysztof Kozlowski wrote:
>>>> Then you need proper wakeup-source support
>>> Wouldn't that break existing devicetrees?
>>
>> How?
>>
>>>
>>> The current driver allows to wake up the system, even without
>>> having wakeup-source set.
>>
>> Anyway, wakeup-source is already there in rtc, so this would be done. I
>> don't get though, why there is no benefit of routing it to interrupt
>> controller (interrupt controllers do wake up the system). Additionally,
>> if you do not connect it to any interrupt, then how does it wake up the
>> system?
>>
>
> Some systems are routing the interrupt output of the RTC directly to the
> PMIC and the PMIC is the one responsible for waking the rest of the
> system, including the SoC.
Yeah, then the PMIC has interrupt line to the SoC and the PMIC is the
wakeup-source, not RTC.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v3 4/8] clk: sunxi-ng: sun6i-rtc: clean up DT usage
From: sashiko-bot @ 2026-07-02 8:21 UTC (permalink / raw)
To: Jerome Brunet
Cc: Alexandre Belloni, devicetree, linux-sunxi, robh, linux-rtc,
conor+dt
In-Reply-To: <20260702-a733-rtc-v3-4-eb2580374de6@baylibre.com>
> With sun6i-rtc compatible devices, the "ext-osc32k" clock input
> is optional for the devices that support this input (r329 and onward).
>
> Probably preparing for older SoC support, the driver does something funny
> when parsing DT. It check if "ext-osc32k" is present in the clock-names and
> if it is not, it uses the first clock as "ext-osc32k". This clock will
> actually be the rtc bus clock so what the driver does is wrong.
>
> At the moment, the driver does not support the older SoCs that would have
> an external 32k clock provided on index #0 so just remove this quirk.
>
> Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com?part=4
^ permalink raw reply
* Re: [PATCH v3 7/8] clk: sunxi-ng: sun6i-rtc: split main oscillator div and gate.
From: sashiko-bot @ 2026-07-02 8:23 UTC (permalink / raw)
To: Jerome Brunet
Cc: linux-rtc, devicetree, robh, linux-sunxi, Alexandre Belloni,
conor+dt
In-Reply-To: <20260702-a733-rtc-v3-7-eb2580374de6@baylibre.com>
> On the a733 the "osc24M-32k" clock has the same gate bits as the previously
> supported SoC but a different divider implementation.
>
> Instead of a fixed 750 divider, the divider is selected based on the
> rate of the oscillator. It can be seen as a simple read-only divider.
>
> To easily replace the divider part depending the SoC, split the divider
> and gate into two separate clock entities.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com?part=7
^ permalink raw reply
* Re: [PATCH 2/8] dt-bindings: mfd: ROHM BD73800 PMIC
From: Matti Vaittinen @ 2026-07-02 8:25 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Matti Vaittinen, Matti Vaittinen, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Brian Masney, Linus Walleij,
Bartosz Golaszewski, Alexandre Belloni, devicetree, linux-kernel,
linux-clk, linux-gpio, linux-rtc
In-Reply-To: <20260702-refreshing-terrific-tarsier-f56ada@quoll>
Hi dee Ho Krzysztof!
Thanks for the review (again)!
On 02/07/2026 11:05, Krzysztof Kozlowski wrote:
> On Wed, Jul 01, 2026 at 03:41:34PM +0300, Matti Vaittinen wrote:
>> +description:
>> + BD73800GW is a single-chip power management IC for battery-powered
>> + portable devices. It integrates 8 buck converters, 4 LDOs and a current
>> + sense amplifier with ADC. Also included is a Real Time Clock (RTC) and a
>> + 32.768 kHz clock gate. Depending on the OTP configuration the BD73800
>> + may also have interrupt controller and GPIOs.
>> +
>> + There are also different variants called BD71851 and BD71885 which are
>> + almost identical from the software point of view.
>> +
>> +properties:
>> + compatible:
>> + oneOf:
>> + - const: rohm,bd73800
>> +
>> + - items:
>> + - const: rohm,bd71851
>> + - const: rohm,bd73800
>> +
>> + - items:
>> + - const: rohm,bd71885
>
> items:
> - enum:
> -
> -
> - const: rohm,bd73800
I suppose this will mean compatible is one of the enum values AND
rohm,bd73800 as a fallback, while accepting also the rohm,bd73800 alone.
(No need to reply, I will test it out). If so, then I'll do this for the
next version (which is probably out only at August).
>
>> + - const: rohm,bd73800
>> +
>> + reg:
>> + maxItems: 1
>> +
>> + interrupts:
>> + maxItems: 1
>> +
>> + # The GPIO1, CLKOUT (GPIO2), FAULT_B and EXTEN_OUT pins can be
>> + # configured to interrupt pins by OTP.
>> + interrupt-controller: true
>> +
>> + "#interrupt-cells":
>> + const: 1
>> + description:
>> + The IRQ number. 0 is GPIO1, 1 CLKOUT (GPIO2), 2 FAULT_B and 3 EXTEN_OUT.
>> + NOTE, A pin can operate as IRQ source only when the OTP
>> + configuration for it has been set to GPI.
>> +
>> + gpio-controller: true
>> +
>> + "#gpio-cells":
>> + const: 2
>> +
>> +# The GPIO1, CLKOUT, FAULT_B and EXTEN_OUT pins may be configured for a
>
> Missing two spaces (indent) before the comment, although this should be
> put into description. I understand it applies to each description - it
> is fine to add to the first one. Descriptions might be used to generate
> user-friendly representation of bindings (PDF). Comments won't, so
> comments are only to explain the binding/schema syntax choices.
This comment sounds like someone is crafting a tool which can convert
the bindings to human-readable spec? For someone as yaml-illiterate as
me, this really brings some hope :) Although, I would hope we saw some
"comment-key" which could be used to mark the comment to be included in
said human-readable format. Stuffing it in the 1.st description is Ok,
but still somewhat sub-optimal. Oh well, "Ok" will do - I'll add this to
the description when re-spinning.
I do appreciate your help and feedback (as always!).
Yours,
-- Matti
--
Matti Vaittinen
Linux kernel developer at ROHM Semiconductors
Oulu Finland
~~ When things go utterly wrong vim users can always type :help! ~~
^ permalink raw reply
* Re: [PATCH v3 6/8] clk: sunxi-ng: div: add read-only operation support
From: sashiko-bot @ 2026-07-02 8:26 UTC (permalink / raw)
To: Jerome Brunet
Cc: linux-rtc, Alexandre Belloni, conor+dt, linux-sunxi, devicetree,
robh
In-Reply-To: <20260702-a733-rtc-v3-6-eb2580374de6@baylibre.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
Pre-existing issues:
- [High] The existing ccu_div_determine_rate_helper incorrectly asks the hardware parent for a non-predivided rate when CLK_SET_RATE_PARENT is set, resulting in unvalidated parent rate requests.
--
commit 20e3c89e1fcae37e3eaf3a9be6d0c4e28094d07d
Author: Jerome Brunet <jbrunet@baylibre.com>
clk: sunxi-ng: div: add read-only operation support
This commit adds support for sunxi-ng read-only dividers to be used
by the a733 oscillator detection logic.
> diff --git a/drivers/clk/sunxi-ng/ccu_div.c b/drivers/clk/sunxi-ng/ccu_div.c
> index 62d680ccb524b..d1c8c7baa12dc 100644
> --- a/drivers/clk/sunxi-ng/ccu_div.c
> +++ b/drivers/clk/sunxi-ng/ccu_div.c
> @@ -84,6 +84,36 @@ static int ccu_div_determine_rate(struct clk_hw *hw,
> req, ccu_div_determine_rate_helper, cd);
> }
[Severity: High]
This is a pre-existing issue, but does ccu_div_determine_rate_helper
incorrectly ask the hardware parent for a non-predivided rate when
CLK_SET_RATE_PARENT is set?
When ccu_div_determine_rate is called on a clock with a pre-divider, it
delegates to ccu_mux_helper_determine_rate, which calls
ccu_div_determine_rate_helper. That helper then directly invokes
divider_determine_rate() which queries req->best_parent_hw for
req->rate * div.
Could this cause the clock core to query the upstream parent for a target
rate without accounting for the pre-divider? If the core subsequently sets
the parent rate to an unvalidated higher rate, it seems the parent PLL may
fail or clamp because it was asked for an achievable rate that it cannot
actually sustain when multiplied by the pre-divider.
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com?part=6
^ permalink raw reply
* Re: [PATCH v3 8/8] clk: sunxi-ng: sun6i-rtc: add a733 support
From: sashiko-bot @ 2026-07-02 8:29 UTC (permalink / raw)
To: Jerome Brunet
Cc: conor+dt, robh, linux-sunxi, Alexandre Belloni, linux-rtc,
devicetree
In-Reply-To: <20260702-a733-rtc-v3-8-eb2580374de6@baylibre.com>
> Add support for the sun60i a733 CCU RTC.
>
> Compared to the a523, this SoC has a different input oscillator divider
> which auto-detects the oscillator rate and select a divider to provide
> a fixed 32768Hz clock. It also provides several phy reference clocks
> with dedicated clock gates.
>
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com?part=8
^ permalink raw reply
* Re: [PATCH 1/3] dt-bindings: rtc: Add sii,wakealarm-output-pin property for S35390A
From: Alexandre Belloni @ 2026-07-02 8:35 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Markus Probst, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Uwe Kleine-König, Andrew Lunn, Gregory Clement,
Sebastian Hesselbarth, linux-arm-kernel, linux-rtc, devicetree,
linux-kernel
In-Reply-To: <887cb4e9-d60d-47b5-9110-e00d18e9e46c@kernel.org>
On 02/07/2026 10:20:20+0200, Krzysztof Kozlowski wrote:
> On 02/07/2026 10:17, Alexandre Belloni wrote:
> > On 02/07/2026 08:09:55+0200, Krzysztof Kozlowski wrote:
> >>>> Then you need proper wakeup-source support
> >>> Wouldn't that break existing devicetrees?
> >>
> >> How?
> >>
> >>>
> >>> The current driver allows to wake up the system, even without
> >>> having wakeup-source set.
> >>
> >> Anyway, wakeup-source is already there in rtc, so this would be done. I
> >> don't get though, why there is no benefit of routing it to interrupt
> >> controller (interrupt controllers do wake up the system). Additionally,
> >> if you do not connect it to any interrupt, then how does it wake up the
> >> system?
> >>
> >
> > Some systems are routing the interrupt output of the RTC directly to the
> > PMIC and the PMIC is the one responsible for waking the rest of the
> > system, including the SoC.
>
> Yeah, then the PMIC has interrupt line to the SoC and the PMIC is the
> wakeup-source, not RTC.
>
This would be case 3 of Documentation/devicetree/bindings/power/wakeup-source.txt
> Best regards,
> Krzysztof
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
^ permalink raw reply
* Re: [PATCH v3 3/8] clk: sunxi-ng: fix ccu probe clock unregister on error
From: Chen-Yu Tsai @ 2026-07-02 13:23 UTC (permalink / raw)
To: Jerome Brunet
Cc: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jernej Skrabec, Samuel Holland, Michael Turquette,
Stephen Boyd, Maxime Ripard, linux-rtc, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-clk, Sashiko
In-Reply-To: <20260702-a733-rtc-v3-3-eb2580374de6@baylibre.com>
On Thu, Jul 2, 2026 at 4:10 PM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> When registering clocks with sunxi_ccu_probe(), the number of ccu_clocks
> and the number of hw clocks might be different, eventhough they usually are
> the same.
>
> If they are different, it could lead to out-of-bound access or registered
> clock left behind on error.
>
> Use a different variable when iterating on hw clocks so every registered
> clock, and only those, gets unregistered on error.
>
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: https://lore.kernel.org/r/20260629131254.7E34C1F00A3A@smtp.kernel.org
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: rtc: sun6i: no clock-output-names on h616/r329
From: Chen-Yu Tsai @ 2026-07-02 13:23 UTC (permalink / raw)
To: Jerome Brunet
Cc: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Jernej Skrabec, Samuel Holland, Michael Turquette,
Stephen Boyd, Maxime Ripard, linux-rtc, devicetree,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-clk, Sashiko
In-Reply-To: <20260702-a733-rtc-v3-1-eb2580374de6@baylibre.com>
On Thu, Jul 2, 2026 at 4:10 PM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> On h616 and r329 chips, clock output names are never defined through DT and
> are not meant to be. Just disallow the property for those chips.
>
> Reported-by: Sashiko <sashiko-bot@kernel.org>
> Closes: http://lore.kernel.org/r/20260629125305.0DF981F000E9@smtp.kernel.org
> Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Reviewed-by: Chen-Yu Tsai <wens@kernel.org>
^ permalink raw reply
* Re: [PATCH v3 1/8] dt-bindings: rtc: sun6i: no clock-output-names on h616/r329
From: Conor Dooley @ 2026-07-02 18:44 UTC (permalink / raw)
To: Jerome Brunet
Cc: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard, linux-rtc,
devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-clk, Sashiko
In-Reply-To: <20260702-a733-rtc-v3-1-eb2580374de6@baylibre.com>
[-- 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 2/8] dt-bindings: rtc: sun6i: add sun60i-a733 support
From: Conor Dooley @ 2026-07-02 18:45 UTC (permalink / raw)
To: Jerome Brunet
Cc: Junhui Liu, Alexandre Belloni, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Chen-Yu Tsai, Jernej Skrabec, Samuel Holland,
Michael Turquette, Stephen Boyd, Maxime Ripard, linux-rtc,
devicetree, linux-arm-kernel, linux-sunxi, linux-kernel,
linux-clk
In-Reply-To: <20260702-a733-rtc-v3-2-eb2580374de6@baylibre.com>
[-- 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 0/8] clk: sun6i-rtc: Add support for Allwinner A733 SoC
From: Enzo Adriano @ 2026-07-02 23:59 UTC (permalink / raw)
To: Jerome Brunet
Cc: Brian Masney, Michael Turquette, Stephen Boyd, Chen-Yu Tsai,
Maxime Ripard, Junhui Liu, Alexandre Belloni, linux-clk,
linux-rtc, linux-arm-kernel, linux-sunxi, devicetree,
linux-kernel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Jernej Skrabec, Samuel Holland
In-Reply-To: <20260702-a733-rtc-v3-0-eb2580374de6@baylibre.com>
Hi Jerome,
I gave v3 a spin on a Radxa Cubie A7S here: it applied cleanly to my
local A733 stack, the RTC probes as rtc0, hwclock set and read-back
work, and the oscillator tree in clk_summary looks as expected. If
there are specific checks that would save you time for this or a
future revision, tell me what you would like exercised and I will
report back.
For transparency, the test harness is AI-assisted (Claude Code) and
results are verified against the captured serial logs.
Thanks,
Enzo
^ permalink raw reply
* [PATCH] dt-bindings: rtc: microchip,pic32mzda-rtc: Convert to DT schema
From: Udaya Kiran Challa @ 2026-07-03 11:04 UTC (permalink / raw)
To: alexandre.belloni, robh, krzk+dt, conor+dt
Cc: skhan, me, linux-rtc, devicetree, linux-kernel,
Udaya Kiran Challa
Convert Microchip PIC32 Real Time Clock and Calendar devicetree binding
from legacy text format to DT schema.
Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
---
.../bindings/rtc/microchip,pic32-rtc.txt | 21 --------
.../bindings/rtc/microchip,pic32mzda-rtc.yaml | 50 +++++++++++++++++++
2 files changed, 50 insertions(+), 21 deletions(-)
delete mode 100644 Documentation/devicetree/bindings/rtc/microchip,pic32-rtc.txt
create mode 100644 Documentation/devicetree/bindings/rtc/microchip,pic32mzda-rtc.yaml
diff --git a/Documentation/devicetree/bindings/rtc/microchip,pic32-rtc.txt b/Documentation/devicetree/bindings/rtc/microchip,pic32-rtc.txt
deleted file mode 100644
index 180b7144bfcc..000000000000
--- a/Documentation/devicetree/bindings/rtc/microchip,pic32-rtc.txt
+++ /dev/null
@@ -1,21 +0,0 @@
-* Microchip PIC32 Real Time Clock and Calendar
-
-The RTCC keeps time in hours, minutes, and seconds, and one half second. It
-provides a calendar in weekday, date, month, and year. It also provides a
-configurable alarm.
-
-Required properties:
-- compatible: should be: "microchip,pic32mzda-rtc"
-- reg: physical base address of the controller and length of memory mapped
- region.
-- interrupts: RTC alarm/event interrupt
-- clocks: clock phandle
-
-Example:
-
- rtc: rtc@1f8c0000 {
- compatible = "microchip,pic32mzda-rtc";
- reg = <0x1f8c0000 0x60>;
- interrupts = <166 IRQ_TYPE_EDGE_RISING>;
- clocks = <&PBCLK6>;
- };
diff --git a/Documentation/devicetree/bindings/rtc/microchip,pic32mzda-rtc.yaml b/Documentation/devicetree/bindings/rtc/microchip,pic32mzda-rtc.yaml
new file mode 100644
index 000000000000..481ee28c06e3
--- /dev/null
+++ b/Documentation/devicetree/bindings/rtc/microchip,pic32mzda-rtc.yaml
@@ -0,0 +1,50 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/rtc/microchip,pic32mzda-rtc.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Microchip PIC32 Real Time Clock and Calendar
+
+maintainers:
+ - Alexandre Belloni <alexandre.belloni@bootlin.com>
+
+description: |
+ The Microchip PIC32 Real Time Clock and Calendar (RTCC) keeps time in hours,
+ minutes, seconds, and one half second. It also provides a calendar with
+ weekday, date, month, and year, along with a configurable alarm.
+
+allOf:
+ - $ref: rtc.yaml#
+
+properties:
+ compatible:
+ const: microchip,pic32mzda-rtc
+
+ reg:
+ maxItems: 1
+
+ interrupts:
+ maxItems: 1
+
+ clocks:
+ maxItems: 1
+
+required:
+ - compatible
+ - reg
+ - interrupts
+ - clocks
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/interrupt-controller/irq.h>
+
+ rtc@1f8c0000 {
+ compatible = "microchip,pic32mzda-rtc";
+ reg = <0x1f8c0000 0x60>;
+ interrupts = <166 IRQ_TYPE_EDGE_RISING>;
+ clocks = <&PBCLK6>;
+ };
--
2.34.1
^ permalink raw reply related
* Re: [PATCH] dt-bindings: rtc: microchip,pic32mzda-rtc: Convert to DT schema
From: sashiko-bot @ 2026-07-03 11:14 UTC (permalink / raw)
To: Udaya Kiran Challa
Cc: linux-rtc, devicetree, robh, Alexandre Belloni, conor+dt
In-Reply-To: <20260703110442.205026-1-challauday369@gmail.com>
> Convert Microchip PIC32 Real Time Clock and Calendar devicetree binding
> from legacy text format to DT schema.
>
> Signed-off-by: Udaya Kiran Challa <challauday369@gmail.com>
Sashiko has reviewed this patch and found no issues. It looks great!
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260703110442.205026-1-challauday369@gmail.com?part=1
^ permalink raw reply
* Re: [PATCH 7/8] gpio: bd73800: Support ROHM BD73800 PMIC GPIOs
From: Bartosz Golaszewski @ 2026-07-03 13:11 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Matti Vaittinen, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown, Michael Turquette,
Stephen Boyd, Brian Masney, Linus Walleij, Bartosz Golaszewski,
Alexandre Belloni, devicetree, linux-kernel, linux-clk,
linux-gpio, linux-rtc, Matti Vaittinen
In-Reply-To: <27fb93d0e61704d495e3adf4ed614edac1642267.1782909323.git.mazziesaccount@gmail.com>
On Wed, 1 Jul 2026 14:43:25 +0200, Matti Vaittinen
<matti.vaittinen@linux.dev> said:
> From: Matti Vaittinen <mazziesaccount@gmail.com>
>
> The ROHM BD73800 PMIC has 4 pins (named GPIO1, CLKOUT, FAULT_B and
> EXTEN_OUT) which might have been set to operate as a GPI or GPO when OTP
> (One Time Programmable memory) is written at device manufacturing.
> Support the GPI/GPO use-case via GPIO framework.
>
> The default OTP for these pins is to not use any of them as GPI or GPO.
> (The GPIO1 defaults as an ADC input regardless the naming). Hence the
> driver assumes none of these pins is a GPI/GPO unless explicitly pointed
> as GPI or GPO via device tree.
>
> Furthermore, pin's direction can't be changed after OTP configuration is
> done. Also the default drive type for a GPO (CMOS / Open Drain) is set
> by the OTP configuration. The BD73800 has a set of undocumented test
> registers which should allow changing the drive type. Access to the test
> register area or the test registers aren't documented and so this driver
> does not support configuring the drive type even though it might be
> doable.
>
> Signed-off-by: Matti Vaittinen <mazziesaccount@gmail.com>
> ---
> drivers/gpio/Kconfig | 11 ++
> drivers/gpio/Makefile | 1 +
> drivers/gpio/gpio-bd73800.c | 234 ++++++++++++++++++++++++++++++++++++
> 3 files changed, 246 insertions(+)
> create mode 100644 drivers/gpio/gpio-bd73800.c
>
> diff --git a/drivers/gpio/Kconfig b/drivers/gpio/Kconfig
> index 28cf6d2e83c2..09d87c3b756f 100644
> --- a/drivers/gpio/Kconfig
> +++ b/drivers/gpio/Kconfig
> @@ -1363,6 +1363,17 @@ config GPIO_BD72720
> be configured to GPO on the ROHM PMIC. The pin configuration is done
> on OTP at manufacturing.
>
> +config GPIO_BD73800
> + tristate "ROHM BD73800 GPIO support"
> + depends on MFD_ROHM_BD71828
> + help
> + Support for GPIOs on ROHM BD73800 PMIC. There can be up to 4
> + GPI or GPO pins available on the PMIC in total. The purpose of
> + the pins is decided at the device manufacturing by OTP
> + configuration and can't be reconfigured later. Enable this
> + if your PMIC has pins set as GPIs or GPOs and if you wish to
> + control the pins via the GPIO framework.
> +
> config GPIO_BD9571MWV
> tristate "ROHM BD9571 GPIO support"
> depends on MFD_BD9571MWV
> diff --git a/drivers/gpio/Makefile b/drivers/gpio/Makefile
> index 4d0e900402fc..3041c06aa933 100644
> --- a/drivers/gpio/Makefile
> +++ b/drivers/gpio/Makefile
> @@ -45,6 +45,7 @@ obj-$(CONFIG_GPIO_BCM_XGS_IPROC) += gpio-xgs-iproc.o
> obj-$(CONFIG_GPIO_BD71815) += gpio-bd71815.o
> obj-$(CONFIG_GPIO_BD71828) += gpio-bd71828.o
> obj-$(CONFIG_GPIO_BD72720) += gpio-bd72720.o
> +obj-$(CONFIG_GPIO_BD73800) += gpio-bd73800.o
> obj-$(CONFIG_GPIO_BD9571MWV) += gpio-bd9571mwv.o
> obj-$(CONFIG_GPIO_BLZP1600) += gpio-blzp1600.o
> obj-$(CONFIG_GPIO_BRCMSTB) += gpio-brcmstb.o
> diff --git a/drivers/gpio/gpio-bd73800.c b/drivers/gpio/gpio-bd73800.c
> new file mode 100644
> index 000000000000..3fe4b7f167b8
> --- /dev/null
> +++ b/drivers/gpio/gpio-bd73800.c
> @@ -0,0 +1,234 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Support to GPIOs on ROHM BD73800
> + * Copyright 2024 ROHM Semiconductors.
> + * Author: Matti Vaittinen <mazziesaccount@gmail.com>
> + */
> +
> +#include <linux/gpio/driver.h>
> +#include <linux/init.h>
> +#include <linux/irq.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/platform_device.h>
> +#include <linux/mfd/rohm-bd73800.h>
> +
> +#define BD73800_GPIO_MAX_PINS 4
> +/*
> + * The BD73800 has several "one time programmable" (OTP) configurations which
> + * can be set at manufacturing phase. Some of these options allow using
> + * individual pins as GPI or GPO (not both at the same time). The OTP
> + * configuration can't be read at run-time, so drivers rely on device-tree to
> + * advertise the OTP programmed in manufacturing.
> + *
> + * The pins which can be used as GPIO are:
> + * GPIO1, CLKOUT (GPIO2), FAULT_B, EXTEN_OUT.
> + *
> + * The OTP options 2 and 3 state for all the pins:
> + * - OTP2: GPI (also IRQ source)
> + * - OTP3: GPO (NOTE: This is actually 2 different OTP options. Either a
> + * register controllable output or a power-sequence controlled output.
> + * The "gpo" referred here means only the register controllable output.
> + * The datasheet refers to this as: "<pin> output is controlled by
> + * GPIO<N>_OUT or power on/off sequencer to control external VRs. ON/OFF
> + * sequence timing is configurable."
> + *
> + * The data-sheet further says that the GPI/GPO is not a default OTP
> + * configuration for any of the pins. Hence the GPIO driver defaults to a pin
> + * not being a GPI or GPO, but requires the pin to be explicitly marked as a
> + * GPI or GPO in the device-tree.
> + *
> + * DT properties:
> + * "rohm,pin-gpio1", "rohm,pin-clkout", "rohm,pin-fault-b", "rohm,pin-exten"
> + * can be set to one of the values "gpi" or "gpo" to enable them to be used as
> + * GPIO.
> + */
> +
> +enum bd73800_gpio_state {
> + BD73800_PIN_UNKNOWN,
> + BD73800_PIN_GPI,
> + BD73800_PIN_GPO,
> +};
> +
> +struct bd73800_gpio_pin_cfg {
> + enum bd73800_gpio_state state;
> + int mask; /* GPIO_OUT and INT_SRC have same bit offsets for GPIO */
> +};
> +
> +struct bd73800_gpio {
> + /* chip.parent points the MFD which provides DT node and regmap */
> + struct gpio_chip chip;
> + struct bd73800_gpio_pin_cfg pin[BD73800_GPIO_MAX_PINS];
> + int num_pins;
> + /* dev points to the platform device for devm and prints */
> + struct device *dev;
> + struct regmap *regmap;
> +};
> +
> +static int bd73800_gpio_get_pins(struct bd73800_gpio *g)
> +{
> + static const char * const properties[] = {"rohm,pin-gpio1",
> + "rohm,pin-clkout", "rohm,pin-fault-b", "rohm,pin-exten"};
> + const char *val;
> + int i, ret;
> +
> + for (i = 0; i < ARRAY_SIZE(properties); i++) {
> + ret = fwnode_property_read_string(dev_fwnode(g->dev->parent),
It would be cleaner with device_property_read_string(g->dev->parent, ...)
> + properties[i], &val);
> +
> + if (ret) {
> + if (ret == -EINVAL)
> + continue;
> +
> + return dev_err_probe(g->dev, ret,
> + "pin %d (%s), bad configuration\n", i,
> + properties[i]);
> + }
> +
> + if (strcmp(val, "gpi") == 0) {
> + g->pin[g->num_pins].state = BD73800_PIN_GPI;
> + g->pin[g->num_pins].mask = BIT(i);
> + g->num_pins++;
> + } else if (strcmp(val, "gpo") == 0) {
> + g->pin[g->num_pins].state = BD73800_PIN_GPO;
> + g->pin[g->num_pins].mask = BIT(i);
> + g->num_pins++;
> + }
> + }
> +
> + return 0;
> +}
> +
> +static int bd73800gpio_get(struct gpio_chip *chip, unsigned int offset)
> +{
> + struct bd73800_gpio *bdgpio = gpiochip_get_data(chip);
> + struct bd73800_gpio_pin_cfg *pin = &bdgpio->pin[offset];
> + int ret, val;
> +
> + /* Only pins configured as GPI via OTP can have their status read */
> + if (pin->state != BD73800_PIN_GPI) {
> + dev_dbg(bdgpio->dev, "pin %d (%x) not input. State %d\n",
> + offset, pin->mask, pin->state);
> + return -EINVAL;
> + }
> +
> + ret = regmap_read(bdgpio->regmap, BD73800_REG_INT_5_SRC, &val);
> + if (ret)
> + return ret;
> +
> + return val & pin->mask;
> +}
> +
> +static int bd73800gpo_set(struct gpio_chip *chip, unsigned int offset,
> + int value)
> +{
> + struct bd73800_gpio *bdgpio = gpiochip_get_data(chip);
> + struct bd73800_gpio_pin_cfg *pin = &bdgpio->pin[offset];
> +
> + if (pin->state != BD73800_PIN_GPO) {
> + dev_dbg(bdgpio->dev, "pin %d (%d) not output. State %d\n",
> + offset, pin->mask, pin->state);
> +
> + return -EINVAL;
> + }
> +
> + if (value)
> + return regmap_set_bits(bdgpio->regmap, BD73800_REG_GPO_OUT,
> + pin->mask);
> +
> + return regmap_clear_bits(bdgpio->regmap, BD73800_REG_GPO_OUT, pin->mask);
> +}
> +
> +static int bd73800gpio_direction_get(struct gpio_chip *chip,
> + unsigned int offset)
> +{
> + struct bd73800_gpio *bdgpio = gpiochip_get_data(chip);
> +
> + if (bdgpio->pin[offset].state == BD73800_PIN_GPO)
> + return GPIO_LINE_DIRECTION_OUT;
> +
> + return GPIO_LINE_DIRECTION_IN;
> +}
> +
> +/*
> + * Template for GPIO chip. The BD73800 GPO supports both CMOS and open drain
> + * configurations. The default however depends on the OTP. The runtime config
> + * can be done via undocumented test registers - but at the moment there is no
> + * support for this.
> + *
> + * NOTE: When the BD73800 GPIO pins are used as IRQ source, the users are
> + * expected to request them directly from the regmap_irq IRQ-chip (implemented
> + * in the MFD driver). This way we don't need to populate another IRQ-chip
> + * here.
> + */
> +static const struct gpio_chip bd73800gpio_chip = {
> + .label = "bd73800",
> + .owner = THIS_MODULE,
> + .get = bd73800gpio_get,
> + .get_direction = bd73800gpio_direction_get,
> + .set = bd73800gpo_set,
> + .can_sleep = true,
> +};
> +
> +static int gpo_bd73800_probe(struct platform_device *pdev)
> +{
> + struct bd73800_gpio *g;
May I suggest a slightly more descriptive name for driver data? Maybe at the
very least... "data"? :)
> + struct device *parent, *dev;
> + int ret;
> +
> + /*
> + * Bind devm lifetime to this platform device => use dev for devm.
> + * also the prints should originate from this device.
> + */
Why would you need to comment on it though? It's very much the standard
approach, isn't it?
> + dev = &pdev->dev;
> + /* The device-tree and regmap come from MFD => use parent for that */
> + parent = dev->parent;
> +
> + g = devm_kzalloc(dev, sizeof(*g), GFP_KERNEL);
> + if (!g)
> + return -ENOMEM;
> +
> + g->chip = bd73800gpio_chip;
> + g->chip.base = -1;
> + g->chip.parent = parent;
> + g->regmap = dev_get_regmap(parent, NULL);
> + g->dev = dev;
> +
> + ret = bd73800_gpio_get_pins(g);
> + if (ret)
> + return ret;
> +
> + if (!g->num_pins) {
> + /*
> + * The BD73800 may or may not have pins allocated for GPIO
> + * depending on the OTP used at manufacturing. Free the memory
> + * and go out if there is no pins as then we have nothing to do
> + */
> + dev_dbg(dev, "no GPIO pins\n");
> + devm_kfree(dev, g);
No need for that, because...
> + return 0;
... this will still leave a bound device in the system, I'm not sure we want
it? The correct error code in this case is -ENODEV.
> + }
> + g->chip.ngpio = g->num_pins;
> +
> + return devm_gpiochip_add_data(dev, &g->chip, g);
> +}
> +
> +static const struct platform_device_id bd73800_gpio_id[] = {
> + { "bd73800-gpio" },
> + { },
> +};
> +MODULE_DEVICE_TABLE(platform, bd73800_gpio_id);
> +
> +static struct platform_driver gpo_bd73800_driver = {
> + .driver = {
> + .name = "bd73800-gpio",
> + .probe_type = PROBE_PREFER_ASYNCHRONOUS,
> + },
> + .probe = gpo_bd73800_probe,
> + .id_table = bd73800_gpio_id,
> +};
> +module_platform_driver(gpo_bd73800_driver);
> +
> +MODULE_AUTHOR("Matti Vaittinen <mazziesaccount@gmail.com>");
> +MODULE_DESCRIPTION("GPIO interface for BD73800");
> +MODULE_LICENSE("GPL");
> --
> 2.54.0
>
>
Bart
^ permalink raw reply
* Re: [PATCH] dt-bindings: rtc: microchip,pic32mzda-rtc: Convert to DT schema
From: Conor Dooley @ 2026-07-03 16:20 UTC (permalink / raw)
To: Udaya Kiran Challa
Cc: alexandre.belloni, robh, krzk+dt, conor+dt, skhan, me, linux-rtc,
devicetree, linux-kernel
In-Reply-To: <20260703110442.205026-1-challauday369@gmail.com>
[-- 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 2/8] dt-bindings: mfd: ROHM BD73800 PMIC
From: Linus Walleij @ 2026-07-03 20:46 UTC (permalink / raw)
To: Matti Vaittinen
Cc: Matti Vaittinen, Matti Vaittinen, Lee Jones, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Liam Girdwood, Mark Brown,
Michael Turquette, Stephen Boyd, Brian Masney,
Bartosz Golaszewski, Alexandre Belloni, devicetree, linux-kernel,
linux-clk, linux-gpio, linux-rtc
In-Reply-To: <3e700a3fa7872a96257ff25a77670ec05cfd239c.1782909323.git.mazziesaccount@gmail.com>
Hi Matti,
thanks for your patch!
I have some inevitable pin control nitpicks!
On Wed, Jul 1, 2026 at 2:41 PM Matti Vaittinen
<matti.vaittinen@linux.dev> wrote:
> + # The GPIO1, CLKOUT (GPIO2), FAULT_B and EXTEN_OUT pins can be
> + # configured to interrupt pins by OTP.
Maybe move this helpful comment into the top description: instead?
It's kind of generic helpful info.
> +# The GPIO1, CLKOUT, FAULT_B and EXTEN_OUT pins may be configured for a
> +# specific purpose (like ADC input, 32.768 clk output, fault indicator or
> +# delivering power sequence to a companion PMIC when multiple PMICs are
> +# used) - but also to be either a GPO or GPI. (When used as a GPI the pin
> +# can also be used as an IRQ source). The pin purpose is determined by
> +# OTP (One Time Programmable memory), typically during device manufacturing.
> +# The OTP can't be read at runtime so device-tree should describe the pins.
> + rohm,pin-gpio1:
> + $ref: /schemas/types.yaml#/definitions/string
> + description:
> + Indicate if the GPIO1 pin has been set to GPI or GPO at manufacturing.
> + enum: [gpi, gpo]
> +
> + rohm,pin-clkout:
> + $ref: /schemas/types.yaml#/definitions/string
> + description:
> + Indicate if the CLKOUT pin has been set to GPI or GPO at manufacturing.
> + enum: [gpi, gpo]
> +
> + rohm,pin-fault-b:
> + $ref: /schemas/types.yaml#/definitions/string
> + description:
> + Indicate if the FAULT_B pin has been set to GPI or GPO at manufacturing.
> + enum: [gpi, gpo]
> +
> + rohm,pin-exten:
> + $ref: /schemas/types.yaml#/definitions/string
> + description:
> + Indicate if the EXTEN_OUT pin has been set to GPI or GPO at
> + manufacturing.
> + enum: [gpi, gpo]
Can we explain what "GPI" and "GPO" means in this context?
I read it as "general purpose input" and "general purpose output", but...
you just describe the exact purpose? So what is "general purpose"
about them in that case?
I would re-use "input-enable" and "output-enable" from:
Documentation/devicetree/bindings/pinctrl/pincfg-node.yaml
(I mean don't $rf that, just use these strings).
I suppose:
enum: [input-enable, output-enable]
> + rohm,clkout-open-drain:
> + description: clk32kout mode. Set to 1 for "open-drain" or 0 for "cmos".
> + $ref: /schemas/types.yaml#/definitions/uint32
> + minimum: 0
> + maximum: 1
Here I would also reuse the generic pinconf properties,
something like;
rohm,clkout-drive-type:
enum: [drive-push-pull, drive-open-drain]
(Push-pull is what is colloquially referred to as "cmos".)
> + rohm,pin-gpio1 = "gpo";
> + rohm,pin-exten = "gpi";
If you instead use nodes with properties you can do this:
rohm,pin-clkout {
output-enable;
drive-push-pull;
};
This collects the clkout config in one place and make
it obvious what is going on. But I don't know what the DT
maintainers think about this idea.
Yours,
Linus Walleij
^ 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