* [PATCH v2] clk: meson: align gxbb_32k_clk_sel number of parents with actual count
From: Martin Blumenstingl @ 2026-06-23 20:19 UTC (permalink / raw)
To: jbrunet, linux-amlogic
Cc: mturquette, sboyd, bmasney, linux-clk, linux-arm-kernel,
linux-kernel, Martin Blumenstingl, Christian Hewitt, stable
The following out-of-bounds read has been observed by Christian on a
GXBB WeTek Hub:
==================================================================
BUG: KASAN: global-out-of-bounds in __clk_register+0x1b70/0x2418
Read of size 8 at addr ffffd66320cf88e0 by task swapper/0/1
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5 #1 PREEMPT
Hardware name: WeTek Hub (DT)
Call trace:
show_stack+0x14/0x20 (C)
dump_stack_lvl+0x74/0x94
print_report+0x164/0x4b0
kasan_report+0x98/0xd8
__asan_report_load8_noabort+0x1c/0x24
__clk_register+0x1b70/0x2418
devm_clk_hw_register+0x74/0x15c
meson_clkc_init+0xd4/0x20c
meson_clkc_syscon_probe+0x5c/0x94
platform_probe+0xbc/0x17c
really_probe+0x184/0x844
__driver_probe_device+0x154/0x35c
driver_probe_device+0x60/0x188
__driver_attach+0x168/0x4a0
bus_for_each_dev+0xec/0x180
driver_attach+0x38/0x58
bus_add_driver+0x238/0x4c0
driver_register+0x150/0x388
__platform_driver_register+0x54/0x7c
gxbb_clkc_driver_init+0x18/0x20
do_one_initcall+0xb8/0x340
kernel_init_freeable+0x49c/0x52c
kernel_init+0x24/0x148
ret_from_fork+0x10/0x20
The buggy address belongs to the variable:
gxbb_32k_clk_parents+0x60/0x400
The buggy address belongs to a vmalloc virtual mapping
The buggy address belongs to the physical page:
Memory state around the buggy address:
ffffd66320cf8780: 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
ffffd66320cf8800: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9
>ffffd66320cf8880: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9
^
ffffd66320cf8900: 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9
ffffd66320cf8980: 00 00 02 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9
==================================================================
Commit 7915d7d5407c ("clk: amlogic: gxbb: drop non existing 32k clock
parent") dropped a non-existing clock parent from the gxbb_32k_clk_sel
mux but didn't adjust the hard-coded num_parents field. Fix the actual
number of parents of that mux by using ARRAY_SIZE instead (avoiding
similar problems in future).
Fixes: 7915d7d5407c ("clk: amlogic: gxbb: drop non existing 32k clock parent")
Reported-by: Christian Hewitt <christianshewitt@gmail.com>
Cc: stable@vger.kernel.org
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Signed-off-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
---
Changes since v1 at [0]:
- fix typo in my own email address (apologies for the noise)
[0] https://lore.kernel.org/linux-amlogic/20260623201522.1322463-1-martin.blumenstingl@googlemail.com/T/#u
drivers/clk/meson/gxbb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
index f9131d014ef4..d432e08d1777 100644
--- a/drivers/clk/meson/gxbb.c
+++ b/drivers/clk/meson/gxbb.c
@@ -1394,7 +1394,7 @@ static struct clk_regmap gxbb_32k_clk_sel = {
.name = "32k_clk_sel",
.ops = &clk_regmap_mux_ops,
.parent_data = gxbb_32k_clk_parents,
- .num_parents = 4,
+ .num_parents = ARRAY_SIZE(gxbb_32k_clk_parents),
.flags = CLK_SET_RATE_PARENT,
},
};
--
2.54.0
^ permalink raw reply related
* [PATCH] clk: meson: align gxbb_32k_clk_sel number of parents with actual count
From: Martin Blumenstingl @ 2026-06-23 20:15 UTC (permalink / raw)
To: jbrunet, linux-amlogic
Cc: mturquette, sboyd, bmasney, linux-clk, linux-arm-kernel,
linux-kernel, Martin Blumenstingl, Christian Hewitt, stable
From: Martin Blumenstingl <martin.blumentstingl@googlemail.com>
The following out-of-bounds read has been observed by Christian on a
GXBB WeTek Hub:
==================================================================
BUG: KASAN: global-out-of-bounds in __clk_register+0x1b70/0x2418
Read of size 8 at addr ffffd66320cf88e0 by task swapper/0/1
CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Not tainted 7.0.0-rc5 #1 PREEMPT
Hardware name: WeTek Hub (DT)
Call trace:
show_stack+0x14/0x20 (C)
dump_stack_lvl+0x74/0x94
print_report+0x164/0x4b0
kasan_report+0x98/0xd8
__asan_report_load8_noabort+0x1c/0x24
__clk_register+0x1b70/0x2418
devm_clk_hw_register+0x74/0x15c
meson_clkc_init+0xd4/0x20c
meson_clkc_syscon_probe+0x5c/0x94
platform_probe+0xbc/0x17c
really_probe+0x184/0x844
__driver_probe_device+0x154/0x35c
driver_probe_device+0x60/0x188
__driver_attach+0x168/0x4a0
bus_for_each_dev+0xec/0x180
driver_attach+0x38/0x58
bus_add_driver+0x238/0x4c0
driver_register+0x150/0x388
__platform_driver_register+0x54/0x7c
gxbb_clkc_driver_init+0x18/0x20
do_one_initcall+0xb8/0x340
kernel_init_freeable+0x49c/0x52c
kernel_init+0x24/0x148
ret_from_fork+0x10/0x20
The buggy address belongs to the variable:
gxbb_32k_clk_parents+0x60/0x400
The buggy address belongs to a vmalloc virtual mapping
The buggy address belongs to the physical page:
Memory state around the buggy address:
ffffd66320cf8780: 00 00 00 00 f9 f9 f9 f9 00 f9 f9 f9 f9 f9 f9 f9
ffffd66320cf8800: 00 04 f9 f9 f9 f9 f9 f9 00 04 f9 f9 f9 f9 f9 f9
>ffffd66320cf8880: 00 00 00 00 00 00 00 00 00 00 00 00 f9 f9 f9 f9
^
ffffd66320cf8900: 00 01 f9 f9 f9 f9 f9 f9 00 06 f9 f9 f9 f9 f9 f9
ffffd66320cf8980: 00 00 02 f9 f9 f9 f9 f9 00 00 02 f9 f9 f9 f9 f9
==================================================================
Commit 7915d7d5407c ("clk: amlogic: gxbb: drop non existing 32k clock
parent") dropped a non-existing clock parent from the gxbb_32k_clk_sel
mux but didn't adjust the hard-coded num_parents field. Fix the actual
number of parents of that mux by using ARRAY_SIZE instead (avoiding
similar problems in future).
Fixes: 7915d7d5407c ("clk: amlogic: gxbb: drop non existing 32k clock parent")
Reported-by: Christian Hewitt <christianshewitt@gmail.com>
Cc: stable@vger.kernel.org
Tested-by: Christian Hewitt <christianshewitt@gmail.com>
Signed-off-by: Martin Blumenstingl <martin.blumentstingl@googlemail.com>
---
drivers/clk/meson/gxbb.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/meson/gxbb.c b/drivers/clk/meson/gxbb.c
index f9131d014ef4..d432e08d1777 100644
--- a/drivers/clk/meson/gxbb.c
+++ b/drivers/clk/meson/gxbb.c
@@ -1394,7 +1394,7 @@ static struct clk_regmap gxbb_32k_clk_sel = {
.name = "32k_clk_sel",
.ops = &clk_regmap_mux_ops,
.parent_data = gxbb_32k_clk_parents,
- .num_parents = 4,
+ .num_parents = ARRAY_SIZE(gxbb_32k_clk_parents),
.flags = CLK_SET_RATE_PARENT,
},
};
--
2.54.0
^ permalink raw reply related
* Re: [PATCH v4 5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
From: Diederik de Haas @ 2026-06-23 17:42 UTC (permalink / raw)
To: Daniele Briguglio, Diederik de Haas, Heiko Stuebner,
Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nicolas Frattaroli, linux-clk, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Ricardo Pardini
In-Reply-To: <20260623140958.4181297-1-hello@superkali.me>
Hi,
On Tue Jun 23, 2026 at 4:10 PM CEST, Daniele Briguglio wrote:
>> So IIUC that means I'd be testing both variants.
>
> Right, that covers both: the mux path and the consumer path. Looking
> forward to the results.
Analog audio works on both. Plus with _TO_IO and LTS without in their
respective DTS's. So I guess CLK_IGNORE_UNUSED works.
Whether it's a good/right fix, I'll leave up to others.
Cheers,
Diederik
^ permalink raw reply
* Re: [PATCH] dt-bindings: clock: renesas,versaclock7: Update maintainer
From: Geert Uytterhoeven @ 2026-06-23 17:27 UTC (permalink / raw)
To: Biju
Cc: Alex Helms, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Biju Das,
Brian Masney, linux-renesas-soc, linux-clk, devicetree,
linux-kernel, Prabhakar Mahadev Lad
In-Reply-To: <20260623162039.153291-1-biju.das.jz@bp.renesas.com>
On Tue, 23 Jun 2026 at 18:20, Biju <biju.das.au@gmail.com> wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Alex's email is bouncing. Update the maintainers list with my contact
> details to take over the schema maintenance.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
i.e. will queue in renesas-clk for v7.3.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] dt-bindings: clock: renesas,versaclock7: Update maintainer
From: Brian Masney @ 2026-06-23 17:00 UTC (permalink / raw)
To: Biju
Cc: Geert Uytterhoeven, Alex Helms, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Magnus Damm,
Biju Das, linux-renesas-soc, linux-clk, devicetree, linux-kernel,
Prabhakar Mahadev Lad
In-Reply-To: <20260623162039.153291-1-biju.das.jz@bp.renesas.com>
On Tue, Jun 23, 2026 at 05:20:37PM +0100, Biju wrote:
> From: Biju Das <biju.das.jz@bp.renesas.com>
>
> Alex's email is bouncing. Update the maintainers list with my contact
> details to take over the schema maintenance.
>
> Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
> ---
> Ref [1]
> [1] https://lore.kernel.org/all/ajqWevofEJ3fv856@redhat.com/
Reviewed-by: Brian Masney <bmasney@redhat.com>
Thanks for submitting this quickly.
Brian
^ permalink raw reply
* Re: [PATCH 3/5] dt-bindings: clock: qcom: Add Maili global clock controller
From: Taniya Das @ 2026-06-23 16:22 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Vivek Aknurwar,
Ajit Pandey, Imran Shaik, Jagadeesh Kona, linux-arm-msm,
linux-clk, devicetree, linux-kernel
In-Reply-To: <20260622-complex-dashing-gopher-9f43a3@quoll>
On 6/22/2026 7:28 PM, Krzysztof Kozlowski wrote:
> I think this should be moved to its own header which will include the
> qcom,hawi-gcc.h. We already do it for
> include/dt-bindings/clock/qcom,sm8650-videocc.h.
Sure, Krzysztof let me take a look and update in the next patch.
--
Thanks,
Taniya Das
^ permalink raw reply
* [PATCH] dt-bindings: clock: renesas,versaclock7: Update maintainer
From: Biju @ 2026-06-23 16:20 UTC (permalink / raw)
To: Geert Uytterhoeven, Alex Helms, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Magnus Damm
Cc: Biju Das, Brian Masney, linux-renesas-soc, linux-clk, devicetree,
linux-kernel, Prabhakar Mahadev Lad, Biju Das
From: Biju Das <biju.das.jz@bp.renesas.com>
Alex's email is bouncing. Update the maintainers list with my contact
details to take over the schema maintenance.
Signed-off-by: Biju Das <biju.das.jz@bp.renesas.com>
---
Ref [1]
[1] https://lore.kernel.org/all/ajqWevofEJ3fv856@redhat.com/
---
.../devicetree/bindings/clock/renesas,versaclock7.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/clock/renesas,versaclock7.yaml b/Documentation/devicetree/bindings/clock/renesas,versaclock7.yaml
index b339f1f9f072..990d287d0a90 100644
--- a/Documentation/devicetree/bindings/clock/renesas,versaclock7.yaml
+++ b/Documentation/devicetree/bindings/clock/renesas,versaclock7.yaml
@@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas Versaclock7 Programmable Clock
maintainers:
- - Alex Helms <alexander.helms.jy@renesas.com>
+ - Biju Das <biju.das.jz@bp.renesas.com>
description: |
Renesas Versaclock7 is a family of configurable clock generator and
--
2.43.0
^ permalink raw reply related
* Re: [PATCH] clk: qcom: dispcc-eliza: Fix disp_cc_mdss_mdp_clk_src RCG stall on Eliza EVK
From: Taniya Das @ 2026-06-23 16:12 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Brian Masney, Konrad Dybcio, linux-arm-msm,
linux-clk, linux-kernel
In-Reply-To: <20260623115644.392477-2-krzysztof.kozlowski@oss.qualcomm.com>
On 6/23/2026 5:26 PM, Krzysztof Kozlowski wrote:
> ---
> drivers/clk/qcom/dispcc-eliza.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/qcom/dispcc-eliza.c b/drivers/clk/qcom/dispcc-eliza.c
> index 479f26e0dde2..e31c24125274 100644
> --- a/drivers/clk/qcom/dispcc-eliza.c
> +++ b/drivers/clk/qcom/dispcc-eliza.c
> @@ -757,7 +757,7 @@ static struct clk_rcg2 disp_cc_mdss_mdp_clk_src = {
> .parent_data = disp_cc_parent_data_11,
> .num_parents = ARRAY_SIZE(disp_cc_parent_data_11),
> .flags = CLK_SET_RATE_PARENT,
> - .ops = &clk_rcg2_shared_ops,
> + .ops = &clk_rcg2_shared_no_init_park_ops,
> },
> };
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
--
Thanks,
Taniya Das
^ permalink raw reply
* Re: [PATCH 1/8] clk: qcom: dispcc-sm8450: Fix mdss clocks
From: Konrad Dybcio @ 2026-06-23 15:50 UTC (permalink / raw)
To: esteuwu, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <20260622-sm8450-qol-v1-1-37e2ee8df9da@proton.me>
On 6/23/26 2:54 AM, Esteban Urrutia via B4 Relay wrote:
> From: Esteban Urrutia <esteuwu@proton.me>
>
> Both of these changes allow the framebuffer to show upon boot and let
> the mdss driver take over afterwards.
> Before, none of these actions were possible. Only mdss takeover was
> possible, but screen had to be turned off first.
>
> OLE configuration may have been a misinterpretation... that's not
> something that's done on the downstream driver.
>
> Changing disp_cc_mdss_mdp_clk_src from clk_rcg2_shared_ops to
> clk_rcg2_shared_no_init_park_ops fixes this warning as well:
[...]
> drivers/clk/qcom/dispcc-sm8450.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/clk/qcom/dispcc-sm8450.c b/drivers/clk/qcom/dispcc-sm8450.c
> index 2e91332dd92a..b99d3eb5e195 100644
> --- a/drivers/clk/qcom/dispcc-sm8450.c
> +++ b/drivers/clk/qcom/dispcc-sm8450.c
> @@ -614,7 +614,7 @@ static struct clk_rcg2 disp_cc_mdss_mdp_clk_src = {
> .parent_data = disp_cc_parent_data_5,
> .num_parents = ARRAY_SIZE(disp_cc_parent_data_5),
> .flags = CLK_SET_RATE_PARENT,
> - .ops = &clk_rcg2_shared_ops,
> + .ops = &clk_rcg2_shared_no_init_park_ops,
> },
> };
>
> @@ -1824,8 +1824,8 @@ static int disp_cc_sm8450_probe(struct platform_device *pdev)
> disp_cc_pll1.regs = clk_alpha_pll_regs[CLK_ALPHA_PLL_TYPE_LUCID_OLE];
> disp_cc_pll1.clkr.hw.init = &sm8475_disp_cc_pll1_init;
>
> - clk_lucid_ole_pll_configure(&disp_cc_pll0, regmap, &sm8475_disp_cc_pll0_config);
> - clk_lucid_ole_pll_configure(&disp_cc_pll1, regmap, &sm8475_disp_cc_pll1_config);
> + clk_lucid_evo_pll_configure(&disp_cc_pll0, regmap, &sm8475_disp_cc_pll0_config);
> + clk_lucid_evo_pll_configure(&disp_cc_pll1, regmap, &sm8475_disp_cc_pll1_config);
> } else {
> clk_lucid_evo_pll_configure(&disp_cc_pll0, regmap, &disp_cc_pll0_config);
> clk_lucid_evo_pll_configure(&disp_cc_pll1, regmap, &disp_cc_pll1_config);
This can also be fixed by migrating to use qcom_cc_driver_data,
which takes a list of alpha PLLs to be configured, and thenthere's
a switch-statement in clk-alpha-pll.c that always assigns the
correct function
Konrad
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: rtc: sun6i: Add Allwinner A733 support
From: Chen-Yu Tsai @ 2026-06-23 15:42 UTC (permalink / raw)
To: Jerome Brunet, Junhui Liu
Cc: Michael Turquette, Stephen Boyd, Jernej Skrabec, Samuel Holland,
Alexandre Belloni, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Maxime Ripard, linux-clk, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-rtc, devicetree
In-Reply-To: <1j1pe7elxm.fsf@starbuckisacylon.baylibre.com>
On Tue, Jun 16, 2026 at 1:46 AM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> On sam. 28 mars 2026 at 20:37, Chen-Yu Tsai <wens@kernel.org> wrote:
>
> > On Wed, Jan 21, 2026 at 7:03 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
> >>
> >> 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.
> >
> > No. The board device tree shall have the exact and correct frequency
> > defined in the external crystal device node. The operating system can
> > use the hardware-detected frequency to "fix" the in-system representation
> > if it is off.
> >
> >> 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
> >
> > No. There is only one input. As in there is only one set of pins for the
> > DCXO. The inputs are the same as on R329 / A523. Just use that list.
> >
> >> + - 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
> >
> > The DCXO enable control has been present since at least the H6. We just
> > never added it, as we would never disable it anyway.
> >
> > If you compare the RTC clock trees of the A733 and A523, the only addition
> > besides the new gates seems to be the LOSC auto selection. But even that
> > is just an illusion, as the A523 has the same registers for that.
> >
> > One could say the A733 RTC is almost backward compatible to the A523, if
> > not for the two fastboot registers the A523 has at 0x120 and 0x124.
> >
> > So I ask that you try to integrate the differences into the existing
> > driver and bindings. You can tweak and export internal clks if you
> > need.
>
> I'd like to help with that. I think it is doable but I have a question
> regarding the binding of the existing driver, more precisely their usage
> here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/sunxi-ng/ccu-sun6i-rtc.c?h=v7.1#n370
>
> Clock indexes are supposed to be stable in DT (AFAIK) but with the code
> linked the external 32k is at:
>
> * "ext-32k" - so index 3 - if "clock-names" is present
> * index 0 if clock names is not present
>
> ... but index 0 is supposed to be the bus clock according the binding
> doc, whether "clock-names" is there or not :/
>
> So what are those old r329 bindings ? is there a documentation defining
> them somewhere ?
You can look at
8487614a8a8a dt-bindings: rtc: sun6i: Add H616, R329, and D1 support
In hindsight maybe the two bindings should be separate. The old SoCs
did not have all these clock inputs from the main clock controller.
The only input it could possibly take was the external 32k crystal.
> Cleaning that part would help with A733 addition in the existing driver
> I think
Yeah. Also, we can treat the bindings and drivers separately. We could
have two bindings but one common driver, or vice versa. As you pointed
out, the bindings are a bit messed up, so we could consider separating
them.
If we end up with separate binding header files, maybe we could use
a different prefix for the new ones so they don't collide? That way
the driver could maybe still be shared?
As for whether to share the headers, I think they should be treated
as part of the binding, so if the bindings are shared, then they can
be shared as well; if the bindings are separate, then they should be
completely separate files as well.
And sorry for the late reply.
Thanks
ChenYu
> >
> >> +#define CLK_RTC_32K 3
> >
> > AFAICT besides being an internal clock, this is also fed to GPIO for
> > debounce? We probably need to expose this on the A523 as well.
> >
> >
> > Thanks
> > ChenYu
> >
> >
> >> +#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
> >>
> >>
>
> --
> Jerome
>
^ permalink raw reply
* Re: [PATCH 1/8] clk: qcom: dispcc-sm8450: Fix mdss clocks
From: Krzysztof Kozlowski @ 2026-06-23 15:39 UTC (permalink / raw)
To: esteuwu, Bjorn Andersson, Michael Turquette, Stephen Boyd,
Brian Masney, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Rob Clark, Will Deacon, Robin Murphy,
Joerg Roedel (AMD), Vinod Koul, Neil Armstrong
Cc: linux-arm-msm, linux-clk, linux-kernel, devicetree, iommu,
linux-arm-kernel, linux-phy
In-Reply-To: <20260622-sm8450-qol-v1-1-37e2ee8df9da@proton.me>
On 23/06/2026 02:54, Esteban Urrutia via B4 Relay wrote:
> From: Esteban Urrutia <esteuwu@proton.me>
>
> Both of these changes allow the framebuffer to show upon boot and let
> the mdss driver take over afterwards.
> Before, none of these actions were possible. Only mdss takeover was
> possible, but screen had to be turned off first.
>
> OLE configuration may have been a misinterpretation... that's not
> something that's done on the downstream driver.
>
> Changing disp_cc_mdss_mdp_clk_src from clk_rcg2_shared_ops to
> clk_rcg2_shared_no_init_park_ops fixes this warning as well:
These should be two separate commits, if I understand correctly.
Please use also Fixes tag.
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH] clk: renesas: r9a09g047: Add LVDS clocks and resets
From: Tommaso Merciai @ 2026-06-23 15:28 UTC (permalink / raw)
To: tomm.merciai
Cc: linux-renesas-soc, biju.das.jz, Tommaso Merciai,
Geert Uytterhoeven, Michael Turquette, Stephen Boyd, Brian Masney,
linux-clk, linux-kernel
Add LVDS clocks and resets entries to the r9a09g047 CPG driver.
Signed-off-by: Tommaso Merciai <tommaso.merciai.xr@bp.renesas.com>
---
drivers/clk/renesas/r9a09g047-cpg.c | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/drivers/clk/renesas/r9a09g047-cpg.c b/drivers/clk/renesas/r9a09g047-cpg.c
index 94158b6834e6..875c01eaa695 100644
--- a/drivers/clk/renesas/r9a09g047-cpg.c
+++ b/drivers/clk/renesas/r9a09g047-cpg.c
@@ -534,6 +534,16 @@ static const struct rzv2h_mod_clk r9a09g047_mod_clks[] __initconst = {
BUS_MSTOP(2, BIT(15))),
DEF_MOD("dsi_0_vclk2", CLK_SMUX2_DSI1_CLK, 25, 0, 10, 21,
BUS_MSTOP(9, BIT(15) | BIT(14))),
+ DEF_MOD("lvds_top_clk_ch0", CLK_PLLDSI0, 26, 0, 10, 22,
+ BUS_MSTOP(13, BIT(0))),
+ DEF_MOD("lvds_top_clk_ch1", CLK_PLLDSI1, 26, 1, 10, 23,
+ BUS_MSTOP(13, BIT(0))),
+ DEF_MOD("lvds_top_clk_dot_ch0", CLK_SMUX2_DSI0_CLK, 26, 2, 10, 24,
+ BUS_MSTOP(13, BIT(0))),
+ DEF_MOD("lvds_top_clk_dot_ch1", CLK_SMUX2_DSI1_CLK, 26, 3, 10, 25,
+ BUS_MSTOP(13, BIT(0))),
+ DEF_MOD("lvds_top_pclk", CLK_PLLDTY_DIV16, 26, 4, 10, 26,
+ BUS_MSTOP(13, BIT(0))),
DEF_MOD("lcdc_1_clk_a", CLK_PLLDTY_ACPU_DIV2, 26, 8, 10, 30,
BUS_MSTOP(13, BIT(5) | BIT(4) | BIT(3))),
DEF_MOD("lcdc_1_clk_p", CLK_PLLDTY_DIV16, 26, 9, 10, 31,
@@ -622,6 +632,7 @@ static const struct rzv2h_reset r9a09g047_resets[] __initconst = {
DEF_RST(13, 14, 6, 15), /* GE3D_AXI_RESETN */
DEF_RST(13, 15, 6, 16), /* GE3D_ACE_RESETN */
DEF_RST(15, 8, 7, 9), /* TSU_1_PRESETN */
+ DEF_RST(17, 10, 8, 11), /* LVDS_TOP_RESET_N */
DEF_RST(17, 14, 8, 15), /* LCDC_1_RESET_N */
};
--
2.54.0
^ permalink raw reply related
* Re: [PATCH 7/7] clk: sunxi-ng: Add Allwinner A733 RTC CCU support
From: Chen-Yu Tsai @ 2026-06-23 15:23 UTC (permalink / raw)
To: Jerome Brunet
Cc: Junhui Liu, Michael Turquette, Stephen Boyd, Jernej Skrabec,
Samuel Holland, Alexandre Belloni, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Maxime Ripard, linux-clk,
linux-arm-kernel, linux-sunxi, linux-kernel, linux-rtc,
devicetree, André Przywara
In-Reply-To: <1jv7bjd6wi.fsf@starbuckisacylon.baylibre.com>
On Tue, Jun 16, 2026 at 1:56 AM Jerome Brunet <jbrunet@baylibre.com> wrote:
>
> On sam. 28 mars 2026 at 22:41, Chen-Yu Tsai <wens@kernel.org> wrote:
>
> > On Wed, Jan 21, 2026 at 7:04 PM Junhui Liu <junhui.liu@pigmoral.tech> wrote:
> >>
> >> Add support for the internal CCU found in the RTC module of the Allwinner
> >> A733 SoC. While the basic 16MHz (IOSC) and 32kHz logic remains compatible
> >> with older SoCs like the sun6i, the A733 introduces several new features.
> >>
> >> The A733 RTC CCU supports choosing one of three external crystal
> >> frequencies: 19.2MHz, 24MHz, and 26MHz. It features hardware detection
> >> logic to automatically identify the frequency used on the board and
> >> exports this DCXO signal as the "hosc" clock.
> >>
> >> Furthermore, the driver implements logic to derive a 32kHz reference
> >> from the HOSC. This is achieved through a muxed clock path using fixed
> >> pre-dividers to normalize the different crystal frequencies to ~32kHz.
> >
> > Have you tested whether the actually normalizes the frequency, i.e.
> > selects a different divider based on the DCXO frequency? Otherwise
> > we're just lying about the frequency.
> >
> >> This path reuses the same hardware mux registers as the HOSC clock.
> >>
> >> Additionally, this CCU provides several gate clocks for specific
> >> peripherals, including SerDes, HDMI, and UFS. The driver is implemented
> >> as an auxiliary driver to be bound to the sun6i-rtc driver.
> >>
> >> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
> >> ---
>
> [...]
>
> >> +};
> >> +
> >> +static const struct clk_parent_data hosc_parents[] = {
> >> + { .fw_name = "osc24M" },
> >> + { .fw_name = "osc19M" },
> >> + { .fw_name = "osc26M" },
> >> + { .fw_name = "osc24M" },
> >> +};
> >
> > As mentioned in my reply to the binding, this is wrong. There is only
> > one input.
> >
> > The most you can do is check the rate of the parent clock against the
> > detected one, and _scream_ that the DT is wrong. And maybe override
> > the reported frequency.
> >
> > If you want to do the latter, you could add a new fixed rate gated
> > clock type to our library. You would fill in the rate before the
> > clocks get registered. I probably wouldn't go that far. We want people
> > to have correct hardware descriptions.
> >
> > Funnily enough Allwinner's BSP actually implements a fixed rate gate
> > for the next 24M-to-32k divider clock.
>
> What about implementing the register bellow as a read-only (and
> non-cached) divider using the factors provided by Junhui ? That would be
> an accurate description of the HW I think.
>
> The oscillator gets set in DT and if the output reported past the
> divider is not 32728Hz, you know you've got a problem (bad DT or HW gone
> bad)
>
> With a fixed-rate gate, you may actually end up lying about what
> actually happen, if the HW does not behave as expected.
>
> Do you prefer a fixed-rate gate still or should I try the RO divider
> approach ?
I think either one would work. The RO divider is probably more accurate.
Sorry for the late reply.
ChenYu
^ permalink raw reply
* Re: [PATCH] clk: si5351: fail prepare when PLL reset times out
From: Brian Masney @ 2026-06-23 14:50 UTC (permalink / raw)
To: Pengpeng Hou
Cc: Michael Turquette, Stephen Boyd, Sascha Hauer, linux-clk,
linux-kernel
In-Reply-To: <20260623135625.49610-1-pengpeng@iscas.ac.cn>
Hi Pengpeng,
Thanks for the patch.
On Tue, Jun 23, 2026 at 09:56:25PM +0800, Pengpeng Hou wrote:
> si5351_clkout_prepare() clears the output powerdown bit and, when
> requested, resets the parent PLL before enabling the output. The PLL
> reset helper logs when the reset bit does not clear, but returns void,
> so prepare still enables the output and reports success.
>
> Make the reset helper return the poll error and propagate it from
> .prepare. If the reset fails, restore the output powerdown bit before
> returning the error.
>
> Fixes: 5142cbcea324 ("clk: si5351: Wait for bit clear after PLL reset")
> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
> ---
> drivers/clk/clk-si5351.c | 22 +++++++++++++++++-----
> 1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
> index e755db545..4e60261da 100644
> --- a/drivers/clk/clk-si5351.c
> +++ b/drivers/clk/clk-si5351.c
> @@ -907,18 +907,18 @@ static int _si5351_clkout_set_disable_state(
> return 0;
> }
>
> -static void _si5351_clkout_reset_pll(struct si5351_driver_data *drvdata, int num)
> +static int _si5351_clkout_reset_pll(struct si5351_driver_data *drvdata, int num)
> {
> u8 val = si5351_reg_read(drvdata, SI5351_CLK0_CTRL + num);
> u8 mask = val & SI5351_CLK_PLL_SELECT ? SI5351_PLL_RESET_B :
> - SI5351_PLL_RESET_A;
> + SI5351_PLL_RESET_A;
Whitespace change can be dropped.
With this fixed in a new version, feel free to add:
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCH] clk: mediatek: mt6735: Unregister PLLs on probe failure
From: Brian Masney @ 2026-06-23 14:35 UTC (permalink / raw)
To: Myeonghun Pak
Cc: Yassine Oudjana, Michael Turquette, Stephen Boyd,
Matthias Brugger, AngeloGioacchino Del Regno, linux-clk,
linux-mediatek, linux-kernel, linux-arm-kernel, Ijae Kim
In-Reply-To: <20260623094125.95791-1-mhun512@gmail.com>
Hi Myeonghun,
On Tue, Jun 23, 2026 at 06:41:11PM +0900, Myeonghun Pak wrote:
> mtk_clk_register_plls() registers the apmixedsys PLL clocks manually, while
> clk_mt6735_apmixed_remove() unregisters them on driver removal.
>
> If devm_of_clk_add_hw_provider() fails after the PLL registration succeeds,
> probe returns the error directly and the remove callback is not run. This
> leaves the registered PLL clocks behind on the probe failure path.
>
> Add an unregister_plls error path so provider registration failures unwind the
> PLLs before returning the error.
Please run your patches through checkpatch.pl before sending.
>
> Fixes: 43c04ed79189 ("clk: mediatek: Add drivers for MediaTek MT6735 main clock and reset drivers")
> Co-developed-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
>
> ---
> drivers/clk/mediatek/clk-mt6735-apmixedsys.c | 9 ++++++++-
> 1 file changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/mediatek/clk-mt6735-apmixedsys.c b/drivers/clk/mediatek/clk-mt6735-apmixedsys.c
> index 9e30c089a2..04cf9665ec 100644
> --- a/drivers/clk/mediatek/clk-mt6735-apmixedsys.c
> +++ b/drivers/clk/mediatek/clk-mt6735-apmixedsys.c
> @@ -102,10 +102,17 @@ static int clk_mt6735_apmixed_probe(struct platform_device *pdev)
>
> ret = devm_of_clk_add_hw_provider(&pdev->dev, of_clk_hw_onecell_get,
> clk_data);
> - if (ret)
> + if (ret) {
> dev_err(&pdev->dev,
> "Failed to register clock provider: %d\n", ret);
> + goto unregister_plls;
> + }
> +
> + return 0;
>
> +unregister_plls:
> + mtk_clk_unregister_plls(apmixedsys_plls, ARRAY_SIZE(apmixedsys_plls),
> + clk_data);
> return ret;
> }
This fix is correct. Since only one path will encounter this, personally
I would just put the call to mtk_clk_unregister_plls() inside the if
statement above to simplify this further.
Brian
^ permalink raw reply
* Re: [PATCH v2] clk: versaclock7: Fix APLL clock leak on probe failure
From: Brian Masney @ 2026-06-23 14:15 UTC (permalink / raw)
To: Myeonghun Pak
Cc: Alex Helms, Michael Turquette, Stephen Boyd, linux-clk,
linux-kernel, Ijae Kim
In-Reply-To: <20260623094023.94231-1-mhun512@gmail.com>
On Tue, Jun 23, 2026 at 06:40:18PM +0900, Myeonghun Pak wrote:
> vc7_probe() registers the APLL with clk_register_fixed_rate(), which is
> not devm-managed and must be explicitly unregistered on probe failure.
>
> Most later errors already unwind through err_clk, but a failure from
> vc7_get_bank_clk() in the output registration loop returned directly.
> That skipped clk_unregister_fixed_rate() and leaked the APLL clock.
>
> Route that error through the existing err_clk label so the fixed-rate
> clock is released consistently with the other probe failure paths.
>
> This issue was identified during our ongoing static-analysis research while
> reviewing kernel code.
>
> Fixes: 48c5e98fedd9 ("clk: Renesas versaclock7 ccf device driver")
> Co-developed-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCH v4 5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
From: Daniele Briguglio @ 2026-06-23 14:09 UTC (permalink / raw)
To: Diederik de Haas, Heiko Stuebner, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Nicolas Frattaroli, linux-clk, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Ricardo Pardini
In-Reply-To: <DJGH34DVKL0W.3T6UB4G4WYYUJ@cknow-tech.com>
Hi Diederik,
> My suspicion that more RK3588 based boards would be broken is because NONE use
> I2S0_8CH_MCLKOUT_TO_IO; they all use I2S0_8CH_MCLKOUT.
These bits reset to open (SYS_GRF_SOC_CON6 = 0x4600, i2sN_mclk_ioe_ clear,
1'b0 = "Output enable"), so a board doesn't need to reference the gate to
get MCLK. They're RW, so firmware can go either way, but your 0x600 has
them clear, which is why audio works today.
The series made the gate a managed clock, so with no consumer
clk_disable_unused disables it at boot. CLK_IGNORE_UNUSED leaves an
already-open gate alone, so nothing changes for those boards. Only the ones
that come up disabled, like the YY3588 and Ricardo's R58X-Pro, need _TO_IO
for the kernel to turn it back on.
> So IIUC that means I'd be testing both variants.
Right, that covers both: the mux path and the consumer path. Looking
forward to the results.
Best regards,
Daniele
^ permalink raw reply
* Re: [PATCH] clk: palmas: unprepare clock on provider registration failure
From: Brian Masney @ 2026-06-23 13:59 UTC (permalink / raw)
To: Myeonghun Pak
Cc: Michael Turquette, Stephen Boyd, linux-clk, linux-kernel,
Ijae Kim
In-Reply-To: <20260623090738.13773-1-mhun512@gmail.com>
Hi Myeonghun,
Thanks for the patch!
On Tue, Jun 23, 2026 at 06:07:34PM +0900, Myeonghun Pak wrote:
> palmas_clks_init_configure() prepares the clock when an external control
> pin is configured. If the subsequent of_clk_add_hw_provider() call fails,
> palmas_clks_probe() returns the error without dropping that prepare
> reference.
>
> Unprepare the clock on that error path when external control is active, so
> the probe failure path balances the successful clk_prepare().
>
> This issue was identified during our ongoing static-analysis research while
> reviewing kernel code.
>
> Fixes: 942d1d674931 ("clk: Add driver for Palmas clk32kg and clk32kgaudio clocks")
> Co-developed-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Ijae Kim <ae878000@gmail.com>
> Signed-off-by: Myeonghun Pak <mhun512@gmail.com>
>
> ---
> drivers/clk/clk-palmas.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-palmas.c b/drivers/clk/clk-palmas.c
> index 39049f62db..ab9df2eedb 100644
> --- a/drivers/clk/clk-palmas.c
> +++ b/drivers/clk/clk-palmas.c
> @@ -265,8 +265,11 @@ static int palmas_clks_probe(struct platform_device *pdev)
> }
>
> ret = of_clk_add_hw_provider(node, of_clk_hw_simple_get, &cinfo->hw);
> - if (ret < 0)
> + if (ret < 0) {
> dev_err(&pdev->dev, "Fail to add clock driver, %d\n", ret);
> + if (cinfo->ext_control_pin)
> + clk_unprepare(cinfo->hw.clk);
> + }
The driver currently only calls clk_unprepare() on an error path in
palmas_clks_init_configure(). It leaks when the driver is removed.
I think the cleanest approach to fixing this is to convert over to use
devm_of_clk_add_hw_provider().
Brian
^ permalink raw reply
* [PATCH] clk: si5351: fail prepare when PLL reset times out
From: Pengpeng Hou @ 2026-06-23 13:56 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Sascha Hauer
Cc: Pengpeng Hou, linux-clk, linux-kernel
si5351_clkout_prepare() clears the output powerdown bit and, when
requested, resets the parent PLL before enabling the output. The PLL
reset helper logs when the reset bit does not clear, but returns void,
so prepare still enables the output and reports success.
Make the reset helper return the poll error and propagate it from
.prepare. If the reset fails, restore the output powerdown bit before
returning the error.
Fixes: 5142cbcea324 ("clk: si5351: Wait for bit clear after PLL reset")
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/clk/clk-si5351.c | 22 +++++++++++++++++-----
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/clk/clk-si5351.c b/drivers/clk/clk-si5351.c
index e755db545..4e60261da 100644
--- a/drivers/clk/clk-si5351.c
+++ b/drivers/clk/clk-si5351.c
@@ -907,18 +907,18 @@ static int _si5351_clkout_set_disable_state(
return 0;
}
-static void _si5351_clkout_reset_pll(struct si5351_driver_data *drvdata, int num)
+static int _si5351_clkout_reset_pll(struct si5351_driver_data *drvdata, int num)
{
u8 val = si5351_reg_read(drvdata, SI5351_CLK0_CTRL + num);
u8 mask = val & SI5351_CLK_PLL_SELECT ? SI5351_PLL_RESET_B :
- SI5351_PLL_RESET_A;
+ SI5351_PLL_RESET_A;
unsigned int v;
int err;
switch (val & SI5351_CLK_INPUT_MASK) {
case SI5351_CLK_INPUT_XTAL:
case SI5351_CLK_INPUT_CLKIN:
- return; /* pll not used, no need to reset */
+ return 0; /* pll not used, no need to reset */
}
si5351_reg_write(drvdata, SI5351_PLL_RESET, mask);
@@ -931,6 +931,8 @@ static void _si5351_clkout_reset_pll(struct si5351_driver_data *drvdata, int num
dev_dbg(&drvdata->client->dev, "%s - %s: pll = %d\n",
__func__, clk_hw_get_name(&drvdata->clkout[num].hw),
(val & SI5351_CLK_PLL_SELECT) ? 1 : 0);
+
+ return err;
}
static int si5351_clkout_prepare(struct clk_hw *hw)
@@ -947,8 +949,18 @@ static int si5351_clkout_prepare(struct clk_hw *hw)
* Do a pll soft reset on the parent pll -- needed to get a
* deterministic phase relationship between the output clocks.
*/
- if (pdata->clkout[hwdata->num].pll_reset)
- _si5351_clkout_reset_pll(hwdata->drvdata, hwdata->num);
+ if (pdata->clkout[hwdata->num].pll_reset) {
+ int ret;
+
+ ret = _si5351_clkout_reset_pll(hwdata->drvdata, hwdata->num);
+ if (ret) {
+ si5351_set_bits(hwdata->drvdata,
+ SI5351_CLK0_CTRL + hwdata->num,
+ SI5351_CLK_POWERDOWN,
+ SI5351_CLK_POWERDOWN);
+ return ret;
+ }
+ }
si5351_set_bits(hwdata->drvdata, SI5351_OUTPUT_ENABLE_CTRL,
(1 << hwdata->num), 0);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH v4 5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
From: Diederik de Haas @ 2026-06-23 13:45 UTC (permalink / raw)
To: Daniele Briguglio, Diederik de Haas, Heiko Stuebner,
Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nicolas Frattaroli, linux-clk, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Ricardo Pardini
In-Reply-To: <20260623132351.4144457-1-hello@superkali.me>
Hi Daniele,
On Tue Jun 23, 2026 at 3:23 PM CEST, Daniele Briguglio wrote:
>> md.l 0xfd58c318
>> fd58c318: 00000600
>
> Thanks. Bit 0 is clear there, so the I2S0 gate is open at the U-Boot
> prompt, after BL31 and before Linux. That matches the symptom: the
> firmware on your T6 leaves it open, and the kernel closes it once nothing
> references it.
>
> Given that, I think Heiko's suggestion makes sense here. Marking the four
> gates CLK_IGNORE_UNUSED keeps the kernel from disabling what the firmware
> already left open, and boards that reference _TO_IO still drive it through
> the consumer.
My suspicion that more RK3588 based boards would be broken is because NONE use
I2S0_8CH_MCLKOUT_TO_IO; they all use I2S0_8CH_MCLKOUT.
(And the testing was only done on not (yet?) upstreamed boards)
> Could you test that change if you get a chance? Just set the flag on the
> I2S0/1/2/3 _TO_IO gates in clk-rk3588.c and check your analog audio comes
> back. The series is already merged, so I'll send the fix as a separate
> follow-up patch, this evening if Heiko is fine with the approach.
I'm going to build a new kernel where I did ``s/0/CLK_IGNORE_UNUSED/`` 4 times
and I adjusted my NanoPC-T6 Plus board dts to use I2S0_8CH_MCLKOUT_TO_IO, while
I keep the LTS board dts to I2S0_8CH_MCLKOUT.
So IIUC that means I'd be testing both variants.
Cheers,
Diederik
^ permalink raw reply
* Re: [PATCH v1 0/3] clock-wizard fixups
From: Brian Masney @ 2026-06-23 13:40 UTC (permalink / raw)
To: Colin Foster
Cc: Datta, Shubhrajyoti, linux-kernel, linux-arm-kernel, linux-clk,
Shubhrajyoti Datta, Michal Simek, Stephen Boyd, Michael Turquette
In-Reply-To: <ajqEMXmTnpOA7tVs@colin-ia-desktop>
Hi Colin,
On Tue, Jun 23, 2026 at 08:03:45AM -0500, Colin Foster wrote:
> On Thu, May 07, 2026 at 05:29:41PM +0530, Datta, Shubhrajyoti wrote:
> > [You don't often get email from shubhraj@amd.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
> >
> > On 5/7/2026 1:35 AM, Colin Foster wrote:
> > > The clock-wizard driver had a hard-coded 20KHz minimum accuracy. This
> > > led to out-of-tree drivers silently failing to set clock rates instead
> > > of dealing with the best-effort.
> > >
> > > Remove this 20KHz restriction to match the Versal clock wizard driver.
> > > There also was a bug in the difference calculation that is addressed in
> > > the first patch.
> > >
> > > The second patch optimizes the search if an exact match is found.
> > >
> > > The third removes the restriction.
> >
> > LGTM
> >
> >
> > Reviewed-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
>
> Are there any actions required from me? Hoping this doesn't slip through
> the cracks.
No there is nothing else that you need to do. Stephen hasn't made the
clk pull to Linus yet. He should assemble it this week.
For the series:
Reviewed-by: Brian Masney <bmasney@redhat.com>
^ permalink raw reply
* Re: [PATCH v4 5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
From: Daniele Briguglio @ 2026-06-23 13:23 UTC (permalink / raw)
To: Diederik de Haas, Heiko Stuebner, Michael Turquette, Stephen Boyd,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Nicolas Frattaroli, linux-clk, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Ricardo Pardini
In-Reply-To: <DJGG8DEAKSPK.1GJ8FARAHXPXM@cknow-tech.com>
Hi Diederik,
> md.l 0xfd58c318
> fd58c318: 00000600
Thanks. Bit 0 is clear there, so the I2S0 gate is open at the U-Boot
prompt, after BL31 and before Linux. That matches the symptom: the
firmware on your T6 leaves it open, and the kernel closes it once nothing
references it.
Given that, I think Heiko's suggestion makes sense here. Marking the four
gates CLK_IGNORE_UNUSED keeps the kernel from disabling what the firmware
already left open, and boards that reference _TO_IO still drive it through
the consumer.
Could you test that change if you get a chance? Just set the flag on the
I2S0/1/2/3 _TO_IO gates in clk-rk3588.c and check your analog audio comes
back. The series is already merged, so I'll send the fix as a separate
follow-up patch, this evening if Heiko is fine with the approach.
Best regards,
Daniele
^ permalink raw reply
* Re: [PATCH v4 5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
From: Diederik de Haas @ 2026-06-23 13:08 UTC (permalink / raw)
To: Diederik de Haas, Daniele Briguglio, Heiko Stuebner,
Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley
Cc: Nicolas Frattaroli, linux-clk, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Ricardo Pardini
In-Reply-To: <DJGG8DEAKSPK.1GJ8FARAHXPXM@cknow-tech.com>
On Tue Jun 23, 2026 at 3:05 PM CEST, Diederik de Haas wrote:
> On Tue Jun 23, 2026 at 2:33 PM CEST, Daniele Briguglio wrote:
>> If that turns out to be the case, CLK_IGNORE_UNUSED on the gates is a
>> reasonable way to stop the kernel from closing a gate the firmware already
>> left open, for boards that would rather not switch their DTS to _TO_IO.
>
> I'm not so sure I agree that CLK_IGNORE_UNUSED is reasonable, but I'll leave
> judgement up to others. I'll do the test regardless, though.
Ah, just learned those should be added to your patch, in which case my
objection goes away.
^ permalink raw reply
* Re: [PATCH v4 5/5] clk: rockchip: rk3588: add GATE_GRF clocks for I2S MCLK output to IO
From: Diederik de Haas @ 2026-06-23 13:05 UTC (permalink / raw)
To: Daniele Briguglio, Heiko Stuebner, Michael Turquette,
Stephen Boyd, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Diederik de Haas
Cc: Nicolas Frattaroli, linux-clk, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Ricardo Pardini
In-Reply-To: <20260623123316.4111002-1-hello@superkali.me>
On Tue Jun 23, 2026 at 2:33 PM CEST, Daniele Briguglio wrote:
>> can you check if adding CLK_IGNORE_UNUSED changes the situation for you?
>> What I assume is happening is that when the clocks were not declared they were
>> just left running, while now the kernel turns off unused (but defined) clocks.
>
> That lines up with what I see. The gates are set-to-disable and reset to
> open, so before the series the bit just kept whatever the boot firmware
> left it at.
>
> Diederik, the cleanest way to confirm is to read SOC_CON6 before Linux
> touches it, e.g. md.l 0xfd58c318 at the U-Boot prompt (bit 0 is I2S0). If
> it comes up clear there, the gate is open, and if audio then breaks once
> the kernel is up, that points at clk_disable_unused turning it off because
> nothing references it.
NanoPC-T6 LTS
U-Boot: 2026.04-00003-g723f0da896bc
The 0003 comes from me adding patches for NanoPC-T6 Plus support, but
otherwise it's plain upstream U-Boot.
=> md.l 0xfd58c318
fd58c318: 00000600 00000a00 00000000 00000000 ................
fd58c328: 00000300 00092820 0fd58c338: 00000000 00000000 00000000 00000000 ................
fd58c348: 00000000 00000000 00000000 00000000 ................c358: 00000000 00000000 00000000 00000000 ................
fd58c368: 00000000 00000000 00000008: 00000000 00000000 00001000 00000240 ............@...
fd58c388: 0000003f 0000fefe 00000000 000000000 00000000 00000000 00000000 ................
fd58c3a8: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ................
fd58c3c8: 00000000 00000000 00000000 000000000 00000000 00000000 00000000 ................
fd58c3e8: 00000000 00000000 00000000 00000000 .0000000 00000000 00000000 ................
fd58c408: 00000000 00000000 00000000 00000000 ....
I'll let interpreting it up to you.
> If that turns out to be the case, CLK_IGNORE_UNUSED on the gates is a
> reasonable way to stop the kernel from closing a gate the firmware already
> left open, for boards that would rather not switch their DTS to _TO_IO.
I'm not so sure I agree that CLK_IGNORE_UNUSED is reasonable, but I'll leave
judgement up to others. I'll do the test regardless, though.
Cheers,
Diederik
> Where a board does reference _TO_IO the consumer holds it open anyway, so
> that path is unaffected either way.
>
> Best regards,
> Daniele
^ permalink raw reply
* Re: [PATCH v1 0/3] clock-wizard fixups
From: Colin Foster @ 2026-06-23 13:03 UTC (permalink / raw)
To: Datta, Shubhrajyoti
Cc: linux-kernel, linux-arm-kernel, linux-clk, Brian Masney,
Shubhrajyoti Datta, Michal Simek, Stephen Boyd, Michael Turquette
In-Reply-To: <65e8c879-fec5-4be9-8211-8e92cf1a0833@amd.com>
Hello,
On Thu, May 07, 2026 at 05:29:41PM +0530, Datta, Shubhrajyoti wrote:
> [You don't often get email from shubhraj@amd.com. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]
>
> On 5/7/2026 1:35 AM, Colin Foster wrote:
> > The clock-wizard driver had a hard-coded 20KHz minimum accuracy. This
> > led to out-of-tree drivers silently failing to set clock rates instead
> > of dealing with the best-effort.
> >
> > Remove this 20KHz restriction to match the Versal clock wizard driver.
> > There also was a bug in the difference calculation that is addressed in
> > the first patch.
> >
> > The second patch optimizes the search if an exact match is found.
> >
> > The third removes the restriction.
>
> LGTM
>
>
> Reviewed-by: Shubhrajyoti Datta <shubhrajyoti.datta@amd.com>
Are there any actions required from me? Hoping this doesn't slip through
the cracks.
Thanks,
Colin Foster
^ 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