* [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
* Re: [PATCH v2 1/2] dt-bindings: clock: Drop incorrect usage of double '::'
From: Andi Shyti @ 2026-06-23 20:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-clk, dri-devel, freedreno, linux-i2c,
linux-pm, linux-leds, linux-media, linux-mmc, linux-phy,
linux-gpio, linux-renesas-soc, linux-serial, linux-sound,
linux-usb
In-Reply-To: <20260623054842.21831-3-krzysztof.kozlowski@oss.qualcomm.com>
Hi Krzysztof,
On Tue, Jun 23, 2026 at 07:48:43AM +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: Andi Shyti <andi.shyti@kernel.org>
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH v2 2/2] dt-bindings: Drop incorrect usage of double '::'
From: Andi Shyti @ 2026-06-23 20:26 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: linux-arm-msm, devicetree, linux-kernel, linux-arm-kernel,
linux-samsung-soc, linux-clk, dri-devel, freedreno, linux-i2c,
linux-pm, linux-leds, linux-media, linux-mmc, linux-phy,
linux-gpio, linux-renesas-soc, linux-serial, linux-sound,
linux-usb
In-Reply-To: <20260623054842.21831-4-krzysztof.kozlowski@oss.qualcomm.com>
Hi Krzysztof,
On Tue, Jun 23, 2026 at 07:48:44AM +0200, Krzysztof Kozlowski wrote:
> There is no use of double colon '::' in YAML. OTOH, the literal style
> block, e.g. using '|' treats all characters as content [1] therefore
> single use of ':' in descriptions is perfectly fine, whenever '|' is
> used.
>
> Cleanup existing code, so the confusing style won't be re-used in new
> contributions.
>
> Link: https://yaml.org/spec/1.2.2/#literal-style [1]
> Acked-by: Conor Dooley <conor.dooley@microchip.com>
> Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
> Acked-by: Sebastian Reichel <sebastian.reichel@collabora.com>
> Acked-by: Niklas Söderlund <niklas.soderlund+renesas@ragnatech.se>
> Acked-by: Mark Brown <broonie@kernel.org>
> Acked-by: Geert Uytterhoeven <geert+renesas@glider.be> # renesas
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Acked-by: Andi Shyti <andi.shyti@kernel.org>
Thanks,
Andi
^ permalink raw reply
* Re: [PATCH RFC 5/8] clk: sunxi-ng: a733: Add bus clocks support
From: Andre Przywara @ 2026-06-23 22:35 UTC (permalink / raw)
To: Junhui Liu, Michael Turquette, Stephen Boyd, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Philipp Zabel, Paul Walmsley, Palmer Dabbelt,
Albert Ou, Alexandre Ghiti, Richard Cochran
Cc: linux-clk, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel, linux-riscv, netdev
In-Reply-To: <20260310-a733-clk-v1-5-36b4e9b24457@pigmoral.tech>
Hi,
On 3/10/26 08:33, Junhui Liu wrote:
> Add the essential bus clocks in the Allwinner A733 CCU, including AHB,
> APB0, APB1, APB_UART, NSI, and MBUS. These buses are necessary for many
> other functional modules. Additionally clocks such as trace, gic and
> cpu_peri are also added as they fall within the register address range
> of the bus clocks, even though they are not strictly bus clocks.
>
> The MBUS clock is marked as critical to ensure the memory bus remains
> operational at all times. For the NSI and MBUS clocks, the hardware
> requires an update bit (bit 27) to be set so that the configuration
> takes effect and the updated parameters can be correctly read back.
>
> Signed-off-by: Junhui Liu <junhui.liu@pigmoral.tech>
> ---
> drivers/clk/sunxi-ng/ccu-sun60i-a733.c | 131 +++++++++++++++++++++++++++++++++
> 1 file changed, 131 insertions(+)
>
> diff --git a/drivers/clk/sunxi-ng/ccu-sun60i-a733.c b/drivers/clk/sunxi-ng/ccu-sun60i-a733.c
> index cf819504c51f..68457813dbbb 100644
> --- a/drivers/clk/sunxi-ng/ccu-sun60i-a733.c
> +++ b/drivers/clk/sunxi-ng/ccu-sun60i-a733.c
> @@ -19,6 +19,7 @@
> #include "ccu_common.h"
>
> #include "ccu_div.h"
> +#include "ccu_mp.h"
> #include "ccu_mult.h"
> #include "ccu_nkmp.h"
> #include "ccu_nm.h"
> @@ -65,6 +66,16 @@ static const struct clk_hw *pll_ref_hws[] = {
> &pll_ref_clk.common.hw
> };
>
> +/*
> + * There is a non-software-configurable mux selecting between the DCXO and the
> + * PLL_REF in hardware, whose output is fed to the sys-24M clock. Although both
> + * sys-24M and pll-ref are fixed at 24 MHz, define a 1:1 fixed factor clock to
> + * provide logical separation:
> + * - pll-ref is dedicated to feeding other PLLs
> + * - sys-24M serves as reference clock for downstream functional modules
> + */
> +static CLK_FIXED_FACTOR_HWS(sys_24M_clk, "sys-24M", pll_ref_hws, 1, 1, 0);
> +
> #define SUN60I_A733_PLL_DDR_REG 0x020
> static struct ccu_nkmp pll_ddr_clk = {
> .enable = BIT(27),
> @@ -371,6 +382,107 @@ static SUNXI_CCU_M_HWS(pll_de_4x_clk, "pll-de-4x", pll_de_hws,
> static SUNXI_CCU_M_HWS(pll_de_3x_clk, "pll-de-3x", pll_de_hws,
> SUN60I_A733_PLL_DE_REG, 16, 3, 0);
>
> +/**************************************************************************
> + * bus clocks *
> + **************************************************************************/
> +
> +static const struct clk_parent_data ahb_apb_parents[] = {
> + { .hw = &sys_24M_clk.hw },
> + { .fw_name = "losc" },
> + { .fw_name = "iosc" },
> + { .hw = &pll_periph0_600M_clk.hw },
> +};
> +
> +static SUNXI_CCU_M_DATA_WITH_MUX(ahb_clk, "ahb", ahb_apb_parents, 0x500,
> + 0, 5, /* M */
> + 24, 2, /* mux */
> + 0);
> +
> +static SUNXI_CCU_M_DATA_WITH_MUX(apb0_clk, "apb0", ahb_apb_parents, 0x510,
> + 0, 5, /* M */
> + 24, 2, /* mux */
> + 0);
> +
> +static SUNXI_CCU_M_DATA_WITH_MUX(apb1_clk, "apb1", ahb_apb_parents, 0x518,
> + 0, 5, /* M */
> + 24, 2, /* mux */
> + 0);
> +
> +static const struct clk_parent_data apb_uart_parents[] = {
> + { .hw = &sys_24M_clk.hw },
> + { .fw_name = "losc" },
> + { .fw_name = "iosc" },
> + { .hw = &pll_periph0_600M_clk.hw },
> + { .hw = &pll_periph0_480M_clk.common.hw },
> +};
> +static SUNXI_CCU_M_DATA_WITH_MUX(apb_uart_clk, "apb-uart", apb_uart_parents, 0x538,
> + 0, 5, /* M */
> + 24, 3, /* mux */
> + 0);
> +
> +static const struct clk_parent_data trace_parents[] = {
> + { .hw = &sys_24M_clk.hw },
> + { .fw_name = "losc" },
> + { .fw_name = "iosc" },
> + { .hw = &pll_periph0_300M_clk.hw },
> + { .hw = &pll_periph0_400M_clk.hw },
> +};
> +static SUNXI_CCU_M_DATA_WITH_MUX_GATE(trace_clk, "trace", trace_parents, 0x540,
> + 0, 5, /* M */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0);
> +
> +static const struct clk_parent_data gic_cpu_peri_parents[] = {
> + { .hw = &sys_24M_clk.hw },
> + { .fw_name = "losc" },
> + { .hw = &pll_periph0_600M_clk.hw },
> + { .hw = &pll_periph0_480M_clk.common.hw },
> + { .hw = &pll_periph0_400M_clk.hw },
> +};
> +static SUNXI_CCU_M_DATA_WITH_MUX_GATE(gic_clk, "gic", gic_cpu_peri_parents, 0x560,
Do we really want to model the GIC clock? The A523 has one as well, as
we don't describe it there. And while the GICv3 binding describes a
clock property, the Linux driver completely ignores that.
So if I see this correctly, this clock would become unused, and would be
turned off, killing the GIC? So we would at least need a CLK_IS_CRITICAL
flag?
But it's a good reminder to lift this clock to something PLL based, in
U-Boot's SPL, because I guess the 24MHz are rather slow.
> + 0, 5, /* M */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0);
> +
> +static SUNXI_CCU_M_DATA_WITH_MUX_GATE(cpu_peri_clk, "cpu-peri", gic_cpu_peri_parents, 0x568,
What is this clock about? I don't see it referenced by any peripheral in
the manual.
> + 0, 5, /* M */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0);
> +
> +static const struct clk_parent_data nsi_parents[] = {
> + { .hw = &sys_24M_clk.hw },
> + { .hw = &pll_ddr_clk.common.hw },
> + { .hw = &pll_periph0_800M_clk.common.hw },
> + { .hw = &pll_periph0_600M_clk.hw },
> + { .hw = &pll_periph0_480M_clk.common.hw },
> + { .hw = &pll_de_3x_clk.common.hw },
> +};
> +static SUNXI_CCU_MP_DATA_WITH_MUX_GATE_FEAT(nsi_clk, "nsi", nsi_parents, 0x580,
Similar question like for the GIC: do we need this in the kernel, and do
we need to prevent this from being turned off?
> + 0, 5, /* M */
> + 0, 0, /* no P */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + 0, CCU_FEATURE_UPDATE_BIT);
> +
> +static const struct clk_parent_data mbus_parents[] = {
> + { .hw = &sys_24M_clk.hw },
> + { .hw = &pll_periph1_600M_clk.hw },
> + { .hw = &pll_ddr_clk.common.hw },
> + { .hw = &pll_periph1_480M_clk.common.hw },
> + { .hw = &pll_periph1_400M_clk.hw },
> + { .hw = &pll_npu_clk.common.hw },
> +};
> +static SUNXI_CCU_MP_DATA_WITH_MUX_GATE_FEAT(mbus_clk, "mbus", mbus_parents, 0x588,
> + 0, 5, /* M */
> + 0, 0, /* no P */
> + 24, 3, /* mux */
> + BIT(31), /* gate */
> + CLK_IS_CRITICAL,
> + CCU_FEATURE_UPDATE_BIT);
> +
> /*
> * Contains all clocks that are controlled by a hardware register. They
> * have a (sunxi) .common member, which needs to be initialised by the common
> @@ -407,11 +519,21 @@ static struct ccu_common *sun60i_a733_ccu_clks[] = {
> &pll_de_clk.common,
> &pll_de_4x_clk.common,
> &pll_de_3x_clk.common,
> + &ahb_clk.common,
> + &apb0_clk.common,
> + &apb1_clk.common,
> + &apb_uart_clk.common,
> + &trace_clk.common,
> + &gic_clk.common,
> + &cpu_peri_clk.common,
> + &nsi_clk.common,
> + &mbus_clk.common,
> };
>
> static struct clk_hw_onecell_data sun60i_a733_hw_clks = {
> .hws = {
> [CLK_PLL_REF] = &pll_ref_clk.common.hw,
> + [CLK_SYS_24M] = &sys_24M_clk.hw,
> [CLK_PLL_DDR] = &pll_ddr_clk.common.hw,
> [CLK_PLL_PERIPH0_4X] = &pll_periph0_4x_clk.common.hw,
> [CLK_PLL_PERIPH0_2X] = &pll_periph0_2x_clk.common.hw,
> @@ -453,6 +575,15 @@ static struct clk_hw_onecell_data sun60i_a733_hw_clks = {
> [CLK_PLL_DE] = &pll_de_clk.common.hw,
> [CLK_PLL_DE_4X] = &pll_de_4x_clk.common.hw,
> [CLK_PLL_DE_3X] = &pll_de_3x_clk.common.hw,
> + [CLK_AHB] = &ahb_clk.common.hw,
> + [CLK_APB0] = &apb0_clk.common.hw,
> + [CLK_APB1] = &apb1_clk.common.hw,
> + [CLK_APB_UART] = &apb_uart_clk.common.hw,
> + [CLK_TRACE] = &trace_clk.common.hw,
> + [CLK_GIC] = &gic_clk.common.hw,
> + [CLK_CPU_PERI] = &cpu_peri_clk.common.hw,
> + [CLK_NSI] = &nsi_clk.common.hw,
> + [CLK_MBUS] = &mbus_clk.common.hw,
> },
> .num = CLK_FANOUT3 + 1,
> };
>
^ permalink raw reply
* Re: [RFC PATCH] clk: qcom: hfpll: return lock timeout from enable paths
From: Antony Kurniawan Soemardi @ 2026-06-24 1:57 UTC (permalink / raw)
To: Konrad Dybcio, Pengpeng Hou, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Brian Masney, linux-arm-msm, linux-clk,
linux-kernel, Herman van Hazendonk, Dmitry Baryshkov
In-Reply-To: <8e7a4cd1-ff17-4052-938b-5cb2ee8576f0@oss.qualcomm.com>
On 6/23/2026 4:43 PM, Konrad Dybcio wrote:
> On 6/23/26 8:05 AM, Pengpeng Hou wrote:
>> The HFPLL enable helper waits for the lock bit but ignores the
>> regmap_read_poll_timeout() result. The polling condition is also
>> inconsistent with clk_hfpll_init(), which treats the lock bit being set
>> as the locked state.
>>
>> Wait for the lock bit to become set, return timeout errors from the
>> helper, and propagate those errors through clk_hfpll_enable() and
>> clk_hfpll_set_rate() instead of enabling the output unconditionally.
>>
>> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
>> ---
>
> This looks good on the surface..
>
> +Herman, Anthony, Dmitry could you please give this a spin on 8x60?
>
> Konrad
Just to clarify, this patch impacts cpufreq and gpufreq for Qualcomm
Krait era, is that correct?
I could try this over the weekend on top of Rudraksha Gupta's cpufreq
patch for msm8960 [1]. We don't have a gpu patch for msm8960 on LKML
yet...
(also my name doesn't have an "h" :D )
[1]
https://lore.kernel.org/all/20260527-expressatt_cpufreq-v2-0-b9b7726ccb6d@gmail.com/
--
Thanks,
Antony K. S.
^ permalink raw reply
* Re: [PATCH 4/6] clk: qcom: Add Nord display clock controller support
From: Shawn Guo @ 2026-06-24 2:42 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Bartosz Golaszewski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Konrad Dybcio, Ajit Pandey,
Imran Shaik, Jagadeesh Kona, linux-arm-msm, linux-clk,
linux-kernel, devicetree
In-Reply-To: <20260623-nords_mm_v1-v1-4-860c84539804@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 04:24:07PM +0530, Taniya Das wrote:
> Add support for the display clock controllers (DISPCC) on the
> Qualcomm Nord platform.
>
> The platform includes two display clock controller instances,
> display0 and display1. Register support for both controllers.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> drivers/clk/qcom/Kconfig | 11 +
> drivers/clk/qcom/Makefile | 1 +
> drivers/clk/qcom/dispcc0-nord.c | 2006 +++++++++++++++++++++++++++++++++++++++
> drivers/clk/qcom/dispcc1-nord.c | 2006 +++++++++++++++++++++++++++++++++++++++
> 4 files changed, 4024 insertions(+)
>
> diff --git a/drivers/clk/qcom/Kconfig b/drivers/clk/qcom/Kconfig
> index 7d84c2f1d911a35430bba7670409f59972dcca0f..874136a2ad9aaa117df2c7ad5c8abc5280b76339 100644
> --- a/drivers/clk/qcom/Kconfig
> +++ b/drivers/clk/qcom/Kconfig
> @@ -145,6 +145,17 @@ config CLK_KAANAPALI_VIDEOCC
> Say Y if you want to support video devices and functionality such as
> video encode/decode.
>
> +config CLK_NORD_DISPCC
> + tristate "Nord Display Clock Controller"
> + depends on ARM64 || COMPILE_TEST
> + select CLK_NORD_GCC
> + default m if ARCH_QCOM
> + help
> + Support for the display clock controllers on Qualcomm Technologies, Inc
> + Nord devices. There are two display clock controllers on Nord SoC.
> + Say Y if you want to support display devices and functionality such as
> + splash screen.
> +
> config CLK_NORD_GCC
> tristate "Nord Global Clock Controller"
> depends on ARM64 || COMPILE_TEST
> diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
> index 58f9a5eb6fd7fc457607a179d8bab5623fedf706..4282f43e7078f1fe0dde6f942040eb6bd122d7ce 100644
> --- a/drivers/clk/qcom/Makefile
> +++ b/drivers/clk/qcom/Makefile
> @@ -37,6 +37,7 @@ obj-$(CONFIG_CLK_KAANAPALI_GCC) += gcc-kaanapali.o
> obj-$(CONFIG_CLK_KAANAPALI_GPUCC) += gpucc-kaanapali.o gxclkctl-kaanapali.o
> obj-$(CONFIG_CLK_KAANAPALI_TCSRCC) += tcsrcc-kaanapali.o
> obj-$(CONFIG_CLK_KAANAPALI_VIDEOCC) += videocc-kaanapali.o
> +obj-$(CONFIG_CLK_NORD_DISPCC) += dispcc0-nord.o dispcc1-nord.o
> obj-$(CONFIG_CLK_NORD_GCC) += gcc-nord.o negcc-nord.o nwgcc-nord.o segcc-nord.o
> obj-$(CONFIG_CLK_NORD_TCSRCC) += tcsrcc-nord.o
> obj-$(CONFIG_CLK_X1E80100_CAMCC) += camcc-x1e80100.o
> diff --git a/drivers/clk/qcom/dispcc0-nord.c b/drivers/clk/qcom/dispcc0-nord.c
> new file mode 100644
> index 0000000000000000000000000000000000000000..c0097482a1a94a99a05767726b5a7405cf014fea
> --- /dev/null
> +++ b/drivers/clk/qcom/dispcc0-nord.c
> @@ -0,0 +1,2006 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/clk-provider.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
This include shouldn't be needed.
Shawn
> +#include <linux/platform_device.h>
> +#include <linux/regmap.h>
^ permalink raw reply
* Re: [PATCH 5/6] dt-bindings: clock: qcom: Document Nord GPU clock controllers
From: Shawn Guo @ 2026-06-24 2:52 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Bartosz Golaszewski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Konrad Dybcio, Ajit Pandey,
Imran Shaik, Jagadeesh Kona, linux-arm-msm, linux-clk,
linux-kernel, devicetree
In-Reply-To: <20260623-nords_mm_v1-v1-5-860c84539804@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 04:24:08PM +0530, Taniya Das wrote:
> Add Device Tree binding documentation for the GPU clock controllers
> on the Qualcomm Nord platform.
>
> The platform includes two GPU clock controller instances, GPUCC and
> GPUCC2. Document the compatible strings for both controllers.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
> ---
> .../bindings/clock/qcom,sm8450-gpucc.yaml | 3 ++
> include/dt-bindings/clock/qcom,nord-gpucc.h | 51 ++++++++++++++++++++++
> 2 files changed, 54 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml
> index fdbdf605ee695637512ce4f98c9b6fcfacb9154f..ba85692240e07a4ed8e69c6b61847c5601b32fa0 100644
> --- a/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml
> +++ b/Documentation/devicetree/bindings/clock/qcom,sm8450-gpucc.yaml
> @@ -18,6 +18,7 @@ description: |
> include/dt-bindings/clock/qcom,glymur-gpucc.h
> include/dt-bindings/clock/qcom,kaanapali-gpucc.h
> include/dt-bindings/clock/qcom,milos-gpucc.h
> + include/dt-bindings/clock/qcom,nord-gpucc.h
> include/dt-bindings/clock/qcom,sar2130p-gpucc.h
> include/dt-bindings/clock/qcom,sm4450-gpucc.h
> include/dt-bindings/clock/qcom,sm8450-gpucc.h
> @@ -33,6 +34,8 @@ properties:
> - qcom,glymur-gpucc
> - qcom,kaanapali-gpucc
> - qcom,milos-gpucc
> + - qcom,nord-gpu2cc
> + - qcom,nord-gpucc
I see inconsistency in naming between dispcc0/dispcc1 and gpucc/gpu2cc.
Shawn
^ permalink raw reply
* Re: [PATCH v7 0/3] Add driver support for ESWIN EIC7700 HSP clock and reset generator
From: Xuyang Dong @ 2026-06-24 3:01 UTC (permalink / raw)
To: mturquette, sboyd, bmasney, benoit.monin
Cc: robh, krzk+dt, conor+dt, linux-clk, devicetree, linux-kernel,
p.zabel, huangyifeng, ningyu, linmin, pinkesh.vaghela
In-Reply-To: <20260605060730.1605-1-dongxuyang@eswincomputing.com>
>
> From: Xuyang Dong <dongxuyang@eswincomputing.com>
>
> Add support for the ESWIN EIC7700 HSP (high-speed peripherals). The drivers
> provide basic functionality to manage and control the clock and reset
> signals for EIC7700 HSP, including mmc, USB, ethernet, SATA and DMAC.
>
> The clock and reset registers are mapped to overlapping I/O address ranges.
> This causes a resource conflict when two drivers attempt to request the
> same region. Use the auxiliary device framework: the main driver
> allocates the shared register region and passes it to auxiliary
> devices, avoiding resource contention and duplicate remapping.
>
> Features:
> Implements support for the ESWIN EIC7700 HSP clock and reset controller.
> Provide API to manage clock and reset signals for the EIC7700 HSP.
>
> Supported chips:
> ESWIN EIC7700 series SoC.
>
> Test:
> Test this patch on the Sifive HiFive Premier P550 (which used the EIC7700
> SoC), include USB and other peripherals. All the drivers of these modules
> use the clock module and reset module.
>
Hi Stephen and Michael,
Just a gentle ping on this thread.
v7 now has Reviewed-by tags from Brian for the clock part, and from
Philipp for the reset part. Do you have any further comments on v7?
Best regards,
Xuyang Dong
> Updates:
> Changes in v7:
> - Clock driver:
> - Add the 'CLK_IGNORE_UNUSED' flag to all gate clocks; otherwise,
> board bring-up fails unless 'clk_ignore_unused' is passed on the
> kernel command line.
> - Sashiko's comments: not addressed in this version
> (see email for explanation)
>
> - Link to v6: https://lore.kernel.org/all/20260519081431.1424-1-dongxuyang@eswincomputing.com/
>
> Changes in v6:
> - Clock driver:
> - Add 'select REGMAP_MMIO' for Kconfig entry (Sashiko review of v5).
> - Reset driver:
> - Add <linux/module.h> (Sashiko review of v5).
>
> - Link to v5: https://lore.kernel.org/all/20260514114212.903-1-dongxuyang@eswincomputing.com/
>
> Changes in v5:
> - Clock driver:
> - Add check for regmap_read().
> - Add "Reviewed-by: Brian Masney <bmasney@redhat.com>".
>
> - Link to v4: https://lore.kernel.org/all/20260512020432.671-1-dongxuyang@eswincomputing.com/
>
> Changes in v4:
> - Clock driver:
> - Remove "Reviewed-by: Benoît Monin <benoit.monin@bootlin.com>" and
> "Reviewed-by: Brian Masney <bmasney@redhat.com>", because the clock
> driver has been updated.
> - Remove inclusion of io.h.
> - Add struct regmap to eic7700_hsp_clk_gate.
> Replace 'void __iomem *reg' with 'unsigned int reg'.
> Replace 'void __iomem *ref_reg' with 'unsigned int ref_reg'.
> Replace long with int for 'offset' and 'ref_offset'.
> Remove 'spinlock_t *lock'.
> Apply the same changes to hsp_clk_register_gate().
> - Remove the structure eic7700_hsp_regmap_lock, and the functions
> eic7700_hsp_regmap_lock() and eic7700_hsp_regmap_unlock().
> - Remove the 'guard(spinlock_irqsave)(gate->lock)' in
> hsp_clk_gate_endisable().
> - Replace readl() and writel() with regmap_assign_bits() in
> hsp_clk_gate_endisable().
> - Change the parameter enable from int to bool.
> - Replace readl() with regmap_read() in hsp_clk_gate_is_enabled().
> - Remove the lock_ctx variable.
> - Move eic7700_hsp_regmap_config from inside the probe function to global
> scope.
> Remove '.lock', '.unlock' and 'lock_arg'.
> Add '.fast_io = true' and '.use_raw_spinlock = true'.
> - Reset driver:
> - Add "Reviewed-by: Philipp Zabel <p.zabel@pengutronix.de>" for reset.
> - Drop the temporary variable, just return regmap_assign_bits(...) directly.
> - Replace -EINVAL with -ENODEV for dev_get_regmap() check.
> - Drop the '_dt'.
>
> - Link to v3: https://lore.kernel.org/all/20260423090904.2108-1-dongxuyang@eswincomputing.com/
>
> Changes in v3:
> - Bindings:
> - Added "Acked-by: Conor Dooley <conor.dooley@microchip.com>" for bindings.
> - Clock driver:
> - Remove 'gate_flags'.
> - Add __acquires for eic7700_hsp_regmap_lock() and add __releases for
> eic7700_hsp_regmap_unlock().
> - Move writel(USB_REF_XTAL24M, gate->ref_reg) into enable. Because this
> is only used for USB gate clock on the enable path. And modify the
> comments.
> - Simplify to: 'return !!(readl(gate->reg) & BIT(gate->bit_idx));'.
> - Drop const from eic7700_hsp_regmap_config.
> - Declare eic7700_hsp_regmap_config as a regular variable at the top.
>
> - Link to v2: https://lore.kernel.org/all/20260420093929.1895-1-dongxuyang@eswincomputing.com/
>
> Changes in v2:
> - Bindings:
> - Remove "hsp_" from clock-names.
> - Replace "eswin,eic7700-clock.yaml" and "eswin,eic7700-hspcrg.yaml" with
> "eswin,eic7700*".
> - Replace "eswin,eic7700-clock.h" and "eswin,eic7700-hspcrg.h" with
> "eswin,eic7700*".
> - Clock driver:
> - Use guard(spinlock_irqsave)(gate->lock) instead of spin_lock_irqsave()
> and remove spin_unlock_irqrestore().
> - Remove the newline in function hsp_clk_gate_is_enabled().
> - Use struct clk_init_data init = {}.
> - Replace 'static struct clk_parent_data' with
> 'static const struct clk_parent_data'.
> - Change '.fw_name' to '.index', because the function
> eswin_clk_register_fixed_factor() uses .index.
> - The structures of clocks should use static struct. When registering a clock,
> the 'hw' field in the structure will be assigned.
> - Remove __force.
> - Create the regmap in the clock driver and remove (__force void*)data->base.
> The reset driver uses dev_get_regmap() to get the regmap from the clock.
> - Move 'const struct regmap_config eic7700_hsp_regmap_config' from reset
> driver to clock driver.
> - The USB clock gate (hsp_clk_gate_endisable) and the reset driver both
> perform read-modify-write cycles on registers 0x800 and 0x900. Use
> custom regmap lock callbacks so that regmap operations hold data->lock
> with IRQs disabled, the same lock the clock gate path uses, preventing
> concurrent RMW races on those shared registers.
> - Change to 'ret = eswin_clk_register_fixed_factor(dev, eic7700_hsp_factor_clks,'.
> The next line will be over 80 characters and under 100 characters.
> - Reset driver:
> - Remove 'depends on COMMON_CLK_EIC7700_HSP' and 'default COMMON_CLK_EIC7700_HSP'.
> - Use regmap_assign_bits() in assert and deassert functions.
> - Remove eic7700_hsp_reset_reset().
> - The clock driver creates the regmap, and the reset driver uses dev_get_regmap().
> - Remove of_reset_n_cells.
>
> - Link to v1: https://lore.kernel.org/all/20260403093459.612-1-dongxuyang@eswincomputing.com/
>
> Xuyang Dong (3):
> dt-bindings: clock: Add ESWIN eic7700 HSP clock and reset generator
> clk: eswin: Add eic7700 HSP clock driver
> reset: eswin: Add eic7700 HSP reset driver
>
> .../bindings/clock/eswin,eic7700-hspcrg.yaml | 63 ++++
> MAINTAINERS | 5 +-
> drivers/clk/eswin/Kconfig | 13 +
> drivers/clk/eswin/Makefile | 1 +
> drivers/clk/eswin/clk-eic7700-hsp.c | 345 ++++++++++++++++++
> drivers/reset/Kconfig | 11 +
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-eic7700-hsp.c | 113 ++++++
> .../dt-bindings/clock/eswin,eic7700-hspcrg.h | 33 ++
> .../dt-bindings/reset/eswin,eic7700-hspcrg.h | 21 ++
> 10 files changed, 604 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/devicetree/bindings/clock/eswin,eic7700-hspcrg.yaml
> create mode 100644 drivers/clk/eswin/clk-eic7700-hsp.c
> create mode 100644 drivers/reset/reset-eic7700-hsp.c
> create mode 100644 include/dt-bindings/clock/eswin,eic7700-hspcrg.h
> create mode 100644 include/dt-bindings/reset/eswin,eic7700-hspcrg.h
>
> --
> 2.34.1
^ permalink raw reply
* [PATCH 0/2] Add AST2700 PECI clock support
From: Ryan Chen @ 2026-06-24 5:44 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery
Cc: linux-clk, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen
Add the PECI clock for the AST2700 SoC1. The PECI clock is a mux
controlled by SCU1_CLK_SEL2 bit 16, selecting between the 25MHz CLKIN
and HPLL/4.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
Ryan Chen (2):
dt-bindings: clock: ast2700: add PECI clock
clk: aspeed: add AST2700 PECI clock
drivers/clk/aspeed/clk-ast2700.c | 10 ++++++++++
include/dt-bindings/clock/aspeed,ast2700-scu.h | 2 ++
2 files changed, 12 insertions(+)
---
base-commit: 948efecf22e49aa4bf55bb73ec79a0ddcfd38571
change-id: 20260623-peci_clk-ba87e043ee5f
Best regards,
--
Ryan Chen <ryan_chen@aspeedtech.com>
^ permalink raw reply
* [PATCH 1/2] dt-bindings: clock: ast2700: add PECI clock
From: Ryan Chen @ 2026-06-24 5:44 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery
Cc: linux-clk, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen
In-Reply-To: <20260624-peci_clk-v1-0-ee28b92e22e9@aspeedtech.com>
Add SCU1_CLK_PECI for the SoC1 PECI controller clock source, and
SCU1_CLK_HPLL_DIV4 which serves as one of the PECI clock mux parents.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
include/dt-bindings/clock/aspeed,ast2700-scu.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/dt-bindings/clock/aspeed,ast2700-scu.h b/include/dt-bindings/clock/aspeed,ast2700-scu.h
index bacf712e8e04..138f78ce5f07 100644
--- a/include/dt-bindings/clock/aspeed,ast2700-scu.h
+++ b/include/dt-bindings/clock/aspeed,ast2700-scu.h
@@ -163,5 +163,7 @@
#define SCU1_CLK_GATE_PORTDUSB2CLK 85
#define SCU1_CLK_GATE_LTPI1TXCLK 86
#define SCU1_CLK_I3C 87
+#define SCU1_CLK_HPLL_DIV4 88
+#define SCU1_CLK_PECI 89
#endif
--
2.34.1
^ permalink raw reply related
* [PATCH 2/2] clk: aspeed: add AST2700 PECI clock
From: Ryan Chen @ 2026-06-24 5:45 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd, Brian Masney, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery
Cc: linux-clk, devicetree, linux-arm-kernel, linux-aspeed,
linux-kernel, Ryan Chen
In-Reply-To: <20260624-peci_clk-v1-0-ee28b92e22e9@aspeedtech.com>
Register the SoC1 PECI clock as a mux selected by SCU1_CLK_SEL2 bit 16,
choosing between the 25MHz CLKIN and HPLL/4. Add the HPLL/4 fixed factor
clock to serve as the second mux parent.
Signed-off-by: Ryan Chen <ryan_chen@aspeedtech.com>
---
drivers/clk/aspeed/clk-ast2700.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/drivers/clk/aspeed/clk-ast2700.c b/drivers/clk/aspeed/clk-ast2700.c
index 8b7b382f6f3e..5f499ec0e1d1 100644
--- a/drivers/clk/aspeed/clk-ast2700.c
+++ b/drivers/clk/aspeed/clk-ast2700.c
@@ -273,6 +273,13 @@ static const unsigned int sdclk_parent_ids[] = {
static const struct clk_hw *sdclk_parent_hws[ARRAY_SIZE(sdclk_parent_ids)];
+static const unsigned int peciclk_parent_ids[] = {
+ SCU1_CLKIN,
+ SCU1_CLK_HPLL_DIV4
+};
+
+static const struct clk_hw *peciclk_parent_hws[ARRAY_SIZE(peciclk_parent_ids)];
+
#define FIXED_CLK(_id, _name, _rate) \
{ \
.id = _id, \
@@ -458,6 +465,7 @@ static const struct ast2700_clk_info ast2700_scu1_clk_info[] __initconst = {
PLL_CLK(SCU1_CLK_HPLL, CLK_PLL, "soc1-hpll", SCU1_CLKIN, SCU1_HPLL_PARAM),
PLL_CLK(SCU1_CLK_APLL, CLK_PLL, "soc1-apll", SCU1_CLKIN, SCU1_APLL_PARAM),
PLL_CLK(SCU1_CLK_DPLL, CLK_PLL, "soc1-dpll", SCU1_CLKIN, SCU1_DPLL_PARAM),
+ FIXED_FACTOR_CLK(SCU1_CLK_HPLL_DIV4, "soc1-hpll_div4", SCU1_CLK_HPLL, 1, 4),
FIXED_FACTOR_CLK(SCU1_CLK_APLL_DIV2, "soc1-apll_div2", SCU1_CLK_APLL, 1, 2),
FIXED_FACTOR_CLK(SCU1_CLK_APLL_DIV4, "soc1-apll_div4", SCU1_CLK_APLL, 1, 4),
FIXED_FACTOR_CLK(SCU1_CLK_CAN, "canclk", SCU1_CLK_APLL, 1, 10),
@@ -481,6 +489,8 @@ static const struct ast2700_clk_info ast2700_scu1_clk_info[] __initconst = {
uxclk_parent_hws, SCU1_CLK_SEL2, 0, 2),
MUX_CLK(SCU1_CLK_HUXCLK, "huxclk", uxclk_parent_ids, ARRAY_SIZE(uxclk_parent_ids),
uxclk_parent_hws, SCU1_CLK_SEL2, 3, 2),
+ MUX_CLK(SCU1_CLK_PECI, "peciclk", peciclk_parent_ids, ARRAY_SIZE(peciclk_parent_ids),
+ peciclk_parent_hws, SCU1_CLK_SEL2, 16, 1),
DIVIDER_CLK(SCU1_CLK_SDCLK, "sdclk", SCU1_CLK_SDMUX,
SCU1_CLK_SEL1, 14, 3, ast2700_clk_div_table),
PLL_CLK(SCU1_CLK_UARTX, CLK_UART_PLL, "uartxclk", SCU1_CLK_UXCLK, SCU1_UXCLK_CTRL),
--
2.34.1
^ permalink raw reply related
* [RFC PATCH] clk: si521xx: Align si52147 OF data with the I2C id table
From: Pengpeng Hou @ 2026-06-24 5:58 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd; +Cc: linux-clk, linux-kernel, Pengpeng Hou
The si52147 match data is used to derive the number and mapping of
registered DIFF clock providers. The I2C id table uses
SI521XX_OE_MAP(0x17, 0xf8), while the OF compatible for the same chip
currently uses SI521XX_OE_MAP(0x15, 0xf8).
Use the same provider topology for the OF match as for the I2C id match
so the same chip identity does not expose a different clock provider set
depending on the match path.
Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
---
drivers/clk/clk-si521xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/clk/clk-si521xx.c b/drivers/clk/clk-si521xx.c
index 4ed4e1a5f4f2..f167fd63c504 100644
--- a/drivers/clk/clk-si521xx.c
+++ b/drivers/clk/clk-si521xx.c
@@ -375,7 +375,7 @@ MODULE_DEVICE_TABLE(i2c, si521xx_id);
static const struct of_device_id clk_si521xx_of_match[] = {
{ .compatible = "skyworks,si52144", .data = (void *)SI521XX_OE_MAP(0x5, 0xc0) },
{ .compatible = "skyworks,si52146", .data = (void *)SI521XX_OE_MAP(0x15, 0xe0) },
- { .compatible = "skyworks,si52147", .data = (void *)SI521XX_OE_MAP(0x15, 0xf8) },
+ { .compatible = "skyworks,si52147", .data = (void *)SI521XX_OE_MAP(0x17, 0xf8) },
{ }
};
MODULE_DEVICE_TABLE(of, clk_si521xx_of_match);
--
2.50.1 (Apple Git-155)
^ permalink raw reply related
* Re: [PATCH] clk: mediatek: mt6735: Unregister PLLs on probe failure
From: Myeonghun Pak @ 2026-06-24 6:21 UTC (permalink / raw)
To: Brian Masney
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: <ajqZoOv-TvmOMLCh@redhat.com>
Hi,
Thanks for the review.
I will send a v2 with mtk_clk_unregister_plls() moved directly into the
devm_of_clk_add_hw_provider() failure branch, and I will make sure it passes
checkpatch before sending.
Best regards,
Myeonghun
2026년 6월 23일 (화) 오후 11:35, Brian Masney <bmasney@redhat.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
* [PATCH v2] clk: mediatek: mt6735: Unregister PLLs on probe failure
From: Myeonghun Pak @ 2026-06-24 6:23 UTC (permalink / raw)
To: Yassine Oudjana, Michael Turquette, Stephen Boyd
Cc: Matthias Brugger, AngeloGioacchino Del Regno, linux-clk,
linux-mediatek, linux-kernel, linux-arm-kernel, Myeonghun Pak,
Ijae Kim
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.
Unregister the PLLs in that failure branch before returning the error.
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>
---
Changes in v2:
- Unregister PLLs directly in the provider-registration failure branch.
- Wrap the commit message line flagged by checkpatch.
drivers/clk/mediatek/clk-mt6735-apmixedsys.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/clk/mediatek/clk-mt6735-apmixedsys.c b/drivers/clk/mediatek/clk-mt6735-apmixedsys.c
index 9e30c089a2..69d9ce1210 100644
--- a/drivers/clk/mediatek/clk-mt6735-apmixedsys.c
+++ b/drivers/clk/mediatek/clk-mt6735-apmixedsys.c
@@ -102,9 +102,12 @@ 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);
+ mtk_clk_unregister_plls(apmixedsys_plls, ARRAY_SIZE(apmixedsys_plls),
+ clk_data);
+ }
return ret;
}
--
2.47.1
^ permalink raw reply related
* Re: [PATCH v6 1/4] dt-bindings: soc: cix: add sky1 audss cru controller
From: Krzysztof Kozlowski @ 2026-06-24 6:49 UTC (permalink / raw)
To: joakim.zhang
Cc: mturquette, sboyd, bmasney, robh, krzk+dt, conor+dt, p.zabel,
gary.yang, cix-kernel-upstream, linux-clk, devicetree,
linux-kernel, linux-arm-kernel
In-Reply-To: <20260623070805.211019-2-joakim.zhang@cixtech.com>
On Tue, Jun 23, 2026 at 03:08:02PM +0800, joakim.zhang@cixtech.com wrote:
> From: Joakim Zhang <joakim.zhang@cixtech.com>
>
> The Cix Sky1 Audio Subsystem (AUDSS) Clock and Reset Unit (CRU)
> groups clock muxing, gating and block-level software reset control
> in a single register block.
>
> Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
> ---
> .../bindings/soc/cix/cix,sky1-audss-cru.yaml | 92 +++++++++++++++++++
> .../dt-bindings/clock/cix,sky1-audss-cru.h | 60 ++++++++++++
> .../dt-bindings/reset/cix,sky1-audss-cru.h | 25 +++++
> 3 files changed, 177 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/soc/cix/cix,sky1-audss-cru.yaml
> create mode 100644 include/dt-bindings/clock/cix,sky1-audss-cru.h
> create mode 100644 include/dt-bindings/reset/cix,sky1-audss-cru.h
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH] clk: palmas: unprepare clock on provider registration failure
From: Myeonghun Pak @ 2026-06-24 7:02 UTC (permalink / raw)
To: Brian Masney
Cc: Michael Turquette, Stephen Boyd, linux-clk, linux-kernel,
Ijae Kim
In-Reply-To: <ajqROjYdv28Yrqo5@redhat.com>
Hi Brian,
Thanks for the review.
Agreed, v1 only handled the provider registration failure path and missed the
driver remove path. I will send a v2 converting the provider registration to
devm_of_clk_add_hw_provider() and making the external-control clk_prepare()
reference device-managed as well.
Best regards,
Myeonghun
2026년 6월 23일 (화) 오후 10:59, Brian Masney <bmasney@redhat.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 v2] clk: palmas: Balance external-control clock prepare
From: Myeonghun Pak @ 2026-06-24 7:05 UTC (permalink / raw)
To: Michael Turquette, Stephen Boyd
Cc: linux-clk, linux-kernel, Myeonghun Pak, Ijae Kim
palmas_clks_init_configure() prepares the clock when an external control
pin is configured. The current driver only drops that prepare reference
when external control configuration fails.
If provider registration fails after that point, or if the driver is later
removed, the prepare reference remains held.
Use devm_add_action_or_reset() to manage the prepare reference. Use
devm_of_clk_add_hw_provider() to manage provider registration. This
balances the prepare reference on probe failure and driver removal.
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>
---
Changes in v2:
- Use devm_of_clk_add_hw_provider() for provider cleanup.
- Manage the external-control clk_prepare() with devm_add_action_or_reset().
- Remove the manual provider remove callback.
drivers/clk/clk-palmas.c | 24 +++++++++++++++---------
1 file changed, 15 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/clk-palmas.c b/drivers/clk/clk-palmas.c
index 39049f62db..fdbf8445eb 100644
--- a/drivers/clk/clk-palmas.c
+++ b/drivers/clk/clk-palmas.c
@@ -194,6 +194,13 @@ static void palmas_clks_get_clk_data(struct platform_device *pdev,
cinfo->ext_control_pin = prop;
}
+static void palmas_clks_unprepare_ext_control(void *data)
+{
+ struct palmas_clock_info *cinfo = data;
+
+ clk_unprepare(cinfo->hw.clk);
+}
+
static int palmas_clks_init_configure(struct palmas_clock_info *cinfo)
{
int ret;
@@ -214,13 +221,18 @@ static int palmas_clks_init_configure(struct palmas_clock_info *cinfo)
return ret;
}
+ ret = devm_add_action_or_reset(cinfo->dev,
+ palmas_clks_unprepare_ext_control,
+ cinfo);
+ if (ret)
+ return ret;
+
ret = palmas_ext_control_req_config(cinfo->palmas,
cinfo->clk_desc->sleep_reqstr_id,
cinfo->ext_control_pin, true);
if (ret < 0) {
dev_err(cinfo->dev, "Ext config for %s failed, %d\n",
cinfo->clk_desc->clk_name, ret);
- clk_unprepare(cinfo->hw.clk);
return ret;
}
}
@@ -230,7 +242,6 @@ static int palmas_clks_init_configure(struct palmas_clock_info *cinfo)
static int palmas_clks_probe(struct platform_device *pdev)
{
struct palmas *palmas = dev_get_drvdata(pdev->dev.parent);
- struct device_node *node = pdev->dev.of_node;
const struct palmas_clks_of_match_data *match_data;
struct palmas_clock_info *cinfo;
int ret;
@@ -264,24 +275,19 @@ static int palmas_clks_probe(struct platform_device *pdev)
return ret;
}
- ret = of_clk_add_hw_provider(node, of_clk_hw_simple_get, &cinfo->hw);
+ ret = devm_of_clk_add_hw_provider(&pdev->dev, of_clk_hw_simple_get,
+ &cinfo->hw);
if (ret < 0)
dev_err(&pdev->dev, "Fail to add clock driver, %d\n", ret);
return ret;
}
-static void palmas_clks_remove(struct platform_device *pdev)
-{
- of_clk_del_provider(pdev->dev.of_node);
-}
-
static struct platform_driver palmas_clks_driver = {
.driver = {
.name = "palmas-clk",
.of_match_table = palmas_clks_of_match,
},
.probe = palmas_clks_probe,
- .remove = palmas_clks_remove,
};
module_platform_driver(palmas_clks_driver);
--
2.47.1
^ permalink raw reply related
* Re: [PATCH v2] dt-bindings: clock: Replace bouncing emails
From: Krzysztof Kozlowski @ 2026-06-24 7:31 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Sylwester Nawrocki, Chanwoo Choi, Peter Griffin, Alim Akhtar,
Barnabas Czeman, Tomasz Figa, linux-arm-msm, linux-clk,
devicetree, linux-kernel, linux-samsung-soc, linux-arm-kernel
In-Reply-To: <20260623073050.36262-2-krzysztof.kozlowski@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 09:30:51AM +0200, Krzysztof Kozlowski wrote:
> Replace permanently bouncing email addresses (550 5.1.1 Recipient address
> rejected) of Adam Skladowski, Chanho Park, Anusha Rao and Sireesh
> Kodali. There are no new messages from them via other email addresses,
> so drop them permanently. Add Alim Akhtar to Samsung ExynosAutov9 SoC
> clocks, because he looks at other Samsung clock hardware and drivers.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
I missed here:
Acked-by: Alim Akhtar <alim.akhtar@samsung.com>
Best regards,
Krzysztof
^ permalink raw reply
* Re: [RFC PATCH] clk: qcom: hfpll: return lock timeout from enable paths
From: Konrad Dybcio @ 2026-06-24 7:39 UTC (permalink / raw)
To: Antony Kurniawan Soemardi, Pengpeng Hou, Bjorn Andersson,
Michael Turquette, Stephen Boyd, Brian Masney, linux-arm-msm,
linux-clk, linux-kernel, Herman van Hazendonk, Dmitry Baryshkov
In-Reply-To: <36f37fa0-94f3-498b-86ca-b431436750e1@smankusors.com>
On 6/24/26 3:57 AM, Antony Kurniawan Soemardi wrote:
> On 6/23/2026 4:43 PM, Konrad Dybcio wrote:
>> On 6/23/26 8:05 AM, Pengpeng Hou wrote:
>>> The HFPLL enable helper waits for the lock bit but ignores the
>>> regmap_read_poll_timeout() result. The polling condition is also
>>> inconsistent with clk_hfpll_init(), which treats the lock bit being set
>>> as the locked state.
>>>
>>> Wait for the lock bit to become set, return timeout errors from the
>>> helper, and propagate those errors through clk_hfpll_enable() and
>>> clk_hfpll_set_rate() instead of enabling the output unconditionally.
>>>
>>> Signed-off-by: Pengpeng Hou <pengpeng@iscas.ac.cn>
>>> ---
>>
>> This looks good on the surface..
>>
>> +Herman, Anthony, Dmitry could you please give this a spin on 8x60?
>>
>> Konrad
>
> Just to clarify, this patch impacts cpufreq and gpufreq for Qualcomm
> Krait era, is that correct?
Seems that way - cpu, L2, and GPU, maybe others
> I could try this over the weekend on top of Rudraksha Gupta's cpufreq
> patch for msm8960 [1]. We don't have a gpu patch for msm8960 on LKML
> yet...
That's fine
> (also my name doesn't have an "h" :D )
My mistake!
Konrad
>
> [1] https://lore.kernel.org/all/20260527-expressatt_cpufreq-v2-0-b9b7726ccb6d@gmail.com/
>
^ permalink raw reply
* Re: [PATCH net] net: ethernet: qualcomm: ppe: Demote from supported and fix maintainer addresses
From: Krzysztof Kozlowski @ 2026-06-24 7:47 UTC (permalink / raw)
To: Andrew Lunn
Cc: Krzysztof Kozlowski, Jie Luo, Bjorn Andersson, Michael Turquette,
Stephen Boyd, Brian Masney, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Andrew Lunn, David S. Miller, Eric Dumazet,
Jakub Kicinski, Paolo Abeni, Lei Wei, Suruchi Agarwal, Pavithra R,
linux-kernel, linux-arm-msm, linux-clk, devicetree, netdev
In-Reply-To: <0c1be662-3c6a-41be-bc19-081d0299ceae@lunn.ch>
On Tue, Jun 23, 2026 at 01:33:05PM +0200, Andrew Lunn wrote:
> > If address did not work for half a year, I really doubt that you commit
> > to above.
>
> I tend to agree. Maybe we should set it to Orphaned, and then decide
> in 6 months time if it can be set back to Maintained?
That would be a bit stronger than I intended and actual responses from
Jie did happen, thus the driver actually might be maintained. I also
think that Qualcomm is committed to maintain it, I only doubt about
supported.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 3/6] dt-bindings: clock: qcom: Document Nord display clock controller
From: Krzysztof Kozlowski @ 2026-06-24 7:53 UTC (permalink / raw)
To: Taniya Das
Cc: Bjorn Andersson, Michael Turquette, Stephen Boyd, Brian Masney,
Shawn Guo, Bartosz Golaszewski, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Neil Armstrong, Konrad Dybcio, Ajit Pandey,
Imran Shaik, Jagadeesh Kona, linux-arm-msm, linux-clk,
linux-kernel, devicetree
In-Reply-To: <20260623-nords_mm_v1-v1-3-860c84539804@oss.qualcomm.com>
On Tue, Jun 23, 2026 at 04:24:06PM +0530, Taniya Das wrote:
> Add Device Tree binding documentation for the display clock controller
> on the Qualcomm Nord SoC.
>
> The Nord platform contains two instances of the display clock controller,
> DISPCC_0 and DISPCC_1. Update the bindings to include compatible strings
> for both instances.
>
> Signed-off-by: Taniya Das <taniya.das@oss.qualcomm.com>
...
> diff --git a/include/dt-bindings/clock/qcom,nord-dispcc.h b/include/dt-bindings/clock/qcom,nord-dispcc.h
> new file mode 100644
> index 0000000000000000000000000000000000000000..9f6c9979e0f358678f28a992af6083b0ae6c97e1
> --- /dev/null
> +++ b/include/dt-bindings/clock/qcom,nord-dispcc.h
> @@ -0,0 +1,115 @@
> +/* SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) */
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#ifndef _DT_BINDINGS_CLK_QCOM_DISP_CC_NORD_H
> +#define _DT_BINDINGS_CLK_QCOM_DISP_CC_NORD_H
> +
> +/* DISP_CC_0 clocks */
Where are clocks/resets/power domains for DISP_CC_1?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH v6 3/4] reset: cix: add sky1 audss auxiliary reset driver
From: Philipp Zabel @ 2026-06-24 8:30 UTC (permalink / raw)
To: joakim.zhang, mturquette, sboyd, bmasney, robh, krzk+dt, conor+dt,
gary.yang
Cc: cix-kernel-upstream, linux-clk, devicetree, linux-kernel,
linux-arm-kernel
In-Reply-To: <20260623070805.211019-4-joakim.zhang@cixtech.com>
On Di, 2026-06-23 at 15:08 +0800, joakim.zhang@cixtech.com wrote:
> From: Joakim Zhang <joakim.zhang@cixtech.com>
>
> Add an auxiliary reset controller driver for the AUDSS CRU. Sixteen
> software reset lines for audio subsystem peripherals are controlled
> through one register in the CRU register map.
>
> The driver is created by the AUDSS clock platform driver and registers
> the reset controller on the CRU device node.
>
> Signed-off-by: Joakim Zhang <joakim.zhang@cixtech.com>
> ---
> drivers/reset/Kconfig | 14 +++
> drivers/reset/Makefile | 1 +
> drivers/reset/reset-sky1-audss.c | 192 +++++++++++++++++++++++++++++++
> 3 files changed, 207 insertions(+)
> create mode 100644 drivers/reset/reset-sky1-audss.c
>
> diff --git a/drivers/reset/Kconfig b/drivers/reset/Kconfig
> index d009eb0849a3..f74859b292ae 100644
> --- a/drivers/reset/Kconfig
> +++ b/drivers/reset/Kconfig
> @@ -300,6 +300,20 @@ config RESET_SKY1
> help
> This enables the reset controller for Cix Sky1.
>
> +config RESET_SKY1_AUDSS
> + tristate "Cix Sky1 Audio Subsystem reset controller"
> + depends on ARCH_CIX || COMPILE_TEST
> + select AUXILIARY_BUS
> + select REGMAP_MMIO
> + default CLK_SKY1_AUDSS
> + help
> + Support for block-level software reset lines in the Cix Sky1
> + Audio Subsystem (AUDSS) Clock and Reset Unit. Sixteen reset
> + outputs for audio peripherals are controlled through the CRU
> + register map. The driver binds as an auxiliary device from
> + the AUDSS clock driver. Say M or Y here if you want to build
> + this driver.
> +
> config RESET_SOCFPGA
> bool "SoCFPGA Reset Driver" if COMPILE_TEST && (!ARM || !ARCH_INTEL_SOCFPGA)
> default ARM && ARCH_INTEL_SOCFPGA
> diff --git a/drivers/reset/Makefile b/drivers/reset/Makefile
> index 3e52569bd276..e81407ea3e29 100644
> --- a/drivers/reset/Makefile
> +++ b/drivers/reset/Makefile
> @@ -39,6 +39,7 @@ obj-$(CONFIG_RESET_RZV2H_USB2PHY) += reset-rzv2h-usb2phy.o
> obj-$(CONFIG_RESET_SCMI) += reset-scmi.o
> obj-$(CONFIG_RESET_SIMPLE) += reset-simple.o
> obj-$(CONFIG_RESET_SKY1) += reset-sky1.o
> +obj-$(CONFIG_RESET_SKY1_AUDSS) += reset-sky1-audss.o
> obj-$(CONFIG_RESET_SOCFPGA) += reset-socfpga.o
> obj-$(CONFIG_RESET_SUNPLUS) += reset-sunplus.o
> obj-$(CONFIG_RESET_SUNXI) += reset-sunxi.o
> diff --git a/drivers/reset/reset-sky1-audss.c b/drivers/reset/reset-sky1-audss.c
> new file mode 100644
> index 000000000000..20870f37d7d7
> --- /dev/null
> +++ b/drivers/reset/reset-sky1-audss.c
> @@ -0,0 +1,192 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Cix Sky1 Audio Subsystem reset controller driver
> + *
> + * Copyright 2026 Cix Technology Group Co., Ltd.
> + */
> +
> +#include <dt-bindings/reset/cix,sky1-audss-cru.h>
> +
> +#include <linux/auxiliary_bus.h>
> +#include <linux/delay.h>
> +#include <linux/device.h>
> +#include <linux/io.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/of_address.h>
> +#include <linux/regmap.h>
> +#include <linux/reset-controller.h>
> +
> +#define SKY1_RESET_SLEEP_MIN_US 50
> +#define SKY1_RESET_SLEEP_MAX_US 100
> +
> +#define AUDSS_SW_RST 0x78
> +
> +struct sky1_audss_reset_map {
> + unsigned int offset;
> + unsigned int mask;
> +};
> +
> +struct sky1_audss_reset {
> + struct reset_controller_dev rcdev;
> + struct regmap *regmap;
> + const struct sky1_audss_reset_map *map;
> +};
> +
> +static const struct sky1_audss_reset_map sky1_audss_reset_map[] = {
> + [AUDSS_I2S0_SW_RST] = { AUDSS_SW_RST, BIT(0) },
> + [AUDSS_I2S1_SW_RST] = { AUDSS_SW_RST, BIT(1) },
> + [AUDSS_I2S2_SW_RST] = { AUDSS_SW_RST, BIT(2) },
> + [AUDSS_I2S3_SW_RST] = { AUDSS_SW_RST, BIT(3) },
> + [AUDSS_I2S4_SW_RST] = { AUDSS_SW_RST, BIT(4) },
> + [AUDSS_I2S5_SW_RST] = { AUDSS_SW_RST, BIT(5) },
> + [AUDSS_I2S6_SW_RST] = { AUDSS_SW_RST, BIT(6) },
> + [AUDSS_I2S7_SW_RST] = { AUDSS_SW_RST, BIT(7) },
> + [AUDSS_I2S8_SW_RST] = { AUDSS_SW_RST, BIT(8) },
> + [AUDSS_I2S9_SW_RST] = { AUDSS_SW_RST, BIT(9) },
> + [AUDSS_WDT_SW_RST] = { AUDSS_SW_RST, BIT(10) },
> + [AUDSS_TIMER_SW_RST] = { AUDSS_SW_RST, BIT(11) },
> + [AUDSS_MB0_SW_RST] = { AUDSS_SW_RST, BIT(12) },
> + [AUDSS_MB1_SW_RST] = { AUDSS_SW_RST, BIT(13) },
> + [AUDSS_HDA_SW_RST] = { AUDSS_SW_RST, BIT(14) },
> + [AUDSS_DMAC_SW_RST] = { AUDSS_SW_RST, BIT(15) },
> +};
> +
> +static struct sky1_audss_reset *to_sky1_audss_reset(struct reset_controller_dev *rcdev)
> +{
> + return container_of(rcdev, struct sky1_audss_reset, rcdev);
> +}
> +
> +static int sky1_audss_reset_set(struct reset_controller_dev *rcdev,
> + unsigned long id, bool assert)
> +{
> + struct sky1_audss_reset *priv = to_sky1_audss_reset(rcdev);
> + const struct sky1_audss_reset_map *signal = &priv->map[id];
> + unsigned int value = assert ? 0 : signal->mask;
> +
> + return regmap_update_bits(priv->regmap, signal->offset, signal->mask, value);
Why does this propagate the return value ...
> +}
> +
> +static int sky1_audss_reset_assert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + sky1_audss_reset_set(rcdev, id, true);
... only to be ignored? It'd be better to pass it on.
> + usleep_range(SKY1_RESET_SLEEP_MIN_US, SKY1_RESET_SLEEP_MAX_US);
> + return 0;
> +}
> +
> +static int sky1_audss_reset_deassert(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + sky1_audss_reset_set(rcdev, id, false);
> + usleep_range(SKY1_RESET_SLEEP_MIN_US, SKY1_RESET_SLEEP_MAX_US);
> + return 0;
> +}
> +
> +static int sky1_audss_reset(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + sky1_audss_reset_assert(rcdev, id);
> + sky1_audss_reset_deassert(rcdev, id);
> + return 0;
> +}
Will any AUDSS reset consumer use the reset_control_reset() API?
If not, no need to implement this.
> +
> +static int sky1_audss_reset_status(struct reset_controller_dev *rcdev,
> + unsigned long id)
> +{
> + struct sky1_audss_reset *priv = to_sky1_audss_reset(rcdev);
> + const struct sky1_audss_reset_map *signal = &priv->map[id];
> + unsigned int value;
> +
> + regmap_read(priv->regmap, signal->offset, &value);
> + return !!(value & signal->mask);
> +}
> +
> +static const struct reset_control_ops sky1_audss_reset_ops = {
> + .reset = sky1_audss_reset,
> + .assert = sky1_audss_reset_assert,
> + .deassert = sky1_audss_reset_deassert,
> + .status = sky1_audss_reset_status,
> +};
> +
> +static const struct regmap_config sky1_audss_regmap_config = {
> + .reg_bits = 32,
> + .val_bits = 32,
> + .reg_stride = 4,
> +};
> +
> +static void sky1_audss_reset_iounmap(void *data)
> +{
> + iounmap(data);
> +}
> +
> +static int sky1_audss_reset_get_regmap(struct sky1_audss_reset *priv)
> +{
> + struct device *dev = priv->rcdev.dev;
> + void __iomem *base;
> + int ret;
> +
> + priv->regmap = dev_get_regmap(dev->parent, NULL);
> + if (priv->regmap)
> + return 0;
> +
> + base = of_iomap(dev->parent->of_node, 0);
> + if (!base)
> + return dev_err_probe(dev, -ENOMEM, "failed to iomap address space\n");
> +
> + ret = devm_add_action_or_reset(dev, sky1_audss_reset_iounmap, base);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to register iounmap action\n");
> +
> + priv->regmap = devm_regmap_init_mmio(dev, base, &sky1_audss_regmap_config);
> + if (IS_ERR(priv->regmap))
> + return dev_err_probe(dev, PTR_ERR(priv->regmap),
> + "failed to initialize regmap\n");
Why is there a fallback path? The clock driver creates the regmap
before creating the reset aux device, so dev_get_regmap() can never
fail.
> +
> + return 0;
> +}
> +
> +static int sky1_audss_reset_probe(struct auxiliary_device *adev,
> + const struct auxiliary_device_id *id)
> +{
> + struct sky1_audss_reset *priv;
> + struct device *dev = &adev->dev;
> + int ret;
> +
> + priv = devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL);
> + if (!priv)
> + return -ENOMEM;
> +
> + priv->map = sky1_audss_reset_map;
> + priv->rcdev.owner = THIS_MODULE;
> + priv->rcdev.nr_resets = ARRAY_SIZE(sky1_audss_reset_map);
> + priv->rcdev.ops = &sky1_audss_reset_ops;
> + priv->rcdev.of_node = dev->parent->of_node;
auxiliary_device_create() uses device_set_of_node_from_dev() to inherit
the parent of_node, so you can use dev->of_node here.
> + priv->rcdev.dev = dev;
> + priv->rcdev.of_reset_n_cells = 1;
No need to set of_reset_n_cells.
> +
> + dev_set_drvdata(dev, priv);
This seems unnecessary as well.
> +
> + ret = sky1_audss_reset_get_regmap(priv);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to get regmap\n");
> +
> + return devm_reset_controller_register(dev, &priv->rcdev);
> +}
> +
> +static const struct auxiliary_device_id sky1_audss_reset_ids[] = {
> + { .name = "clk_sky1_audss.reset" },
> + { }
> +};
> +MODULE_DEVICE_TABLE(auxiliary, sky1_audss_reset_ids);
> +
> +static struct auxiliary_driver sky1_audss_reset_driver = {
> + .probe = sky1_audss_reset_probe,
> + .id_table = sky1_audss_reset_ids,
> +};
> +
Drop this empty line.
> +module_auxiliary_driver(sky1_audss_reset_driver);
> +
> +MODULE_AUTHOR("Joakim Zhang <joakim.zhang@cixtech.com>");
> +MODULE_DESCRIPTION("Cix Sky1 Audio Subsystem reset driver");
> +MODULE_LICENSE("GPL");
regards
Philipp
^ permalink raw reply
* Re: [PATCH 0/3] clk: Add __clk_disable_unprepare_counts_only() and use this in simple[fb|drm]
From: Maxime Ripard @ 2026-06-24 8:53 UTC (permalink / raw)
To: Hans de Goede
Cc: Brian Masney, Michael Turquette, Stephen Boyd, Thomas Zimmermann,
Javier Martinez Canillas, Maarten Lankhorst, Helge Deller,
Bjorn Andersson, Konrad Dybcio, Dmitry Baryshkov, Rob Clark,
linux-clk, dri-devel, ~postmarketos/upstreaming
In-Reply-To: <4b09bd91-9a08-407a-9b01-216dd4d7aae0@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 3860 bytes --]
On Thu, May 28, 2026 at 03:02:09PM +0200, Hans de Goede wrote:
> On 28-May-26 2:08 PM, Maxime Ripard wrote:
> > On Thu, May 28, 2026 at 12:12:10PM +0200, Hans de Goede wrote:
> >> Hi Brian,
> >>
> >> On 28-May-26 1:03 AM, Brian Masney wrote:
> >>> Hi Hans,
> >>>
> >>> On Wed, May 27, 2026 at 11:48:08AM +0200, Hans de Goede wrote:
> >>>> 2) One option considered was detaching the simple-framebuffer driver later,
> >>>> after the real display driver has had a chance to claim the clocks. But
> >>>> this won't work in cases where the real display driver picks different
> >>>> parent clocks then the boot firmware did and needs to reparent clocks.
> >>>
> >>> Why won't that work in the case where different parent clocks are selected?
> >>> I'll describe a scenario below.
> >>>
> >>>>
> >>>> Basically the goal is for things to behave as if the simple-framebuffer
> >>>> driver was not there at all, because that leaves the hw in the state
> >>>> the real display driver expects.
> >>>
> >>> I think the deferred unbinding could have some potential here where
> >>> there is some kind of notification mechanism between simple-framebuffer
> >>> and the real drm driver. So:
> >>>
> >>> - simple-framebuffer driver takes reference(s) to the clk(s).
> >>>
> >>> - real drm driver eventually loads, takes reference(s) to the necessary
> >>> clk(s).
> >>>
> >>> - real drm driver sends a notification to simple-framebuffer that it's
> >>> done, and has control.
> >>>
> >>> - simple-framebuffer can unbind and release its references to the clks.
> >>>
> >>> No clks will be shutdown prematurely in this scenario.
> >>>
> >>> If the real drm driver needs a different parent, then presumably things
> >>> should be setup correctly, and simple-framebuffer can have the clocks
> >>> shut down when it calls clk_disable_unprepare().
> >>
> >> If the real drm driver needs a different parent, then how does it
> >> do the reparenting while the simple-framebuffer driver is holding
> >> a reference to the clock ? In that case the clock might have
> >> a protected_count of non 0 (depends on the core-clk flags) and
> >> reparenting won't work.
> >
> > The only case where it should reparent you listed was that you might
> > need to pick up a different resolution. However, that can only be
> > enforced by an ioctl or a client.
> >
> > simplefb/drm is removed in msm_drm_kms_init. The device is published
> > drm_dev_register called right after msm_drm_kms_init, and the clients
> > are registered in msm_drm_kms_post_init, called after drm_dev_register.
> >
> > There's no way in the current msm architecture to have a modeset happen
> > while the simpledrm driver is still active.
>
> Ok, new plan, please let me know what you think about this:
>
> 1. Add a new "disable" callback argument to
> devm_aperture_acquire_for_platform_device() and store this in
> struct aperture_range
>
> 2. Add a new aperture_disable_conflicting_devices() which
> calls the disable callback for matching devices.
>
> 3. Have the simple[fd|drm] drivers implement a disable callback
> which unregisters the drm dev and releases any claims on the
> aperture mem-region, while keeping clks, regulators, etc.
> enabled. And have them check if disable was called on remove()
> and if not do the disable() things on remove(0
>
> 4. Have msm call aperture_disable_conflicting_devices() where it
> now call aperture_remove_conflicting_devices() and call
> aperture_remove_conflicting_devices() at the point where it has
> claimed any clks it needs.
>
> Does this sound like something which would be acceptable ?
Generally speaking, yes, but I'd also like to understand what you're
trying to fix exactly, because I don't see how it can be what you hinted
at before.
Maxime
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 273 bytes --]
^ permalink raw reply
* Re: [PATCH 0/3] clk: Add __clk_disable_unprepare_counts_only() and use this in simple[fb|drm]
From: Hans de Goede @ 2026-06-24 9:06 UTC (permalink / raw)
To: Maxime Ripard
Cc: Brian Masney, Michael Turquette, Stephen Boyd, Thomas Zimmermann,
Javier Martinez Canillas, Maarten Lankhorst, Helge Deller,
Bjorn Andersson, Konrad Dybcio, Dmitry Baryshkov, Rob Clark,
linux-clk, dri-devel, ~postmarketos/upstreaming
In-Reply-To: <20260624-ultramarine-beetle-of-vastness-acd51e@houat>
Hi,
On 24-Jun-26 10:53, Maxime Ripard wrote:
> On Thu, May 28, 2026 at 03:02:09PM +0200, Hans de Goede wrote:
>> On 28-May-26 2:08 PM, Maxime Ripard wrote:
>>> On Thu, May 28, 2026 at 12:12:10PM +0200, Hans de Goede wrote:
>>>> Hi Brian,
>>>>
>>>> On 28-May-26 1:03 AM, Brian Masney wrote:
>>>>> Hi Hans,
>>>>>
>>>>> On Wed, May 27, 2026 at 11:48:08AM +0200, Hans de Goede wrote:
>>>>>> 2) One option considered was detaching the simple-framebuffer driver later,
>>>>>> after the real display driver has had a chance to claim the clocks. But
>>>>>> this won't work in cases where the real display driver picks different
>>>>>> parent clocks then the boot firmware did and needs to reparent clocks.
>>>>>
>>>>> Why won't that work in the case where different parent clocks are selected?
>>>>> I'll describe a scenario below.
>>>>>
>>>>>>
>>>>>> Basically the goal is for things to behave as if the simple-framebuffer
>>>>>> driver was not there at all, because that leaves the hw in the state
>>>>>> the real display driver expects.
>>>>>
>>>>> I think the deferred unbinding could have some potential here where
>>>>> there is some kind of notification mechanism between simple-framebuffer
>>>>> and the real drm driver. So:
>>>>>
>>>>> - simple-framebuffer driver takes reference(s) to the clk(s).
>>>>>
>>>>> - real drm driver eventually loads, takes reference(s) to the necessary
>>>>> clk(s).
>>>>>
>>>>> - real drm driver sends a notification to simple-framebuffer that it's
>>>>> done, and has control.
>>>>>
>>>>> - simple-framebuffer can unbind and release its references to the clks.
>>>>>
>>>>> No clks will be shutdown prematurely in this scenario.
>>>>>
>>>>> If the real drm driver needs a different parent, then presumably things
>>>>> should be setup correctly, and simple-framebuffer can have the clocks
>>>>> shut down when it calls clk_disable_unprepare().
>>>>
>>>> If the real drm driver needs a different parent, then how does it
>>>> do the reparenting while the simple-framebuffer driver is holding
>>>> a reference to the clock ? In that case the clock might have
>>>> a protected_count of non 0 (depends on the core-clk flags) and
>>>> reparenting won't work.
>>>
>>> The only case where it should reparent you listed was that you might
>>> need to pick up a different resolution. However, that can only be
>>> enforced by an ioctl or a client.
>>>
>>> simplefb/drm is removed in msm_drm_kms_init. The device is published
>>> drm_dev_register called right after msm_drm_kms_init, and the clients
>>> are registered in msm_drm_kms_post_init, called after drm_dev_register.
>>>
>>> There's no way in the current msm architecture to have a modeset happen
>>> while the simpledrm driver is still active.
>>
>> Ok, new plan, please let me know what you think about this:
>>
>> 1. Add a new "disable" callback argument to
>> devm_aperture_acquire_for_platform_device() and store this in
>> struct aperture_range
>>
>> 2. Add a new aperture_disable_conflicting_devices() which
>> calls the disable callback for matching devices.
>>
>> 3. Have the simple[fd|drm] drivers implement a disable callback
>> which unregisters the drm dev and releases any claims on the
>> aperture mem-region, while keeping clks, regulators, etc.
>> enabled. And have them check if disable was called on remove()
>> and if not do the disable() things on remove(0
>>
>> 4. Have msm call aperture_disable_conflicting_devices() where it
>> now call aperture_remove_conflicting_devices() and call
>> aperture_remove_conflicting_devices() at the point where it has
>> claimed any clks it needs.
>>
>> Does this sound like something which would be acceptable ?
>
> Generally speaking, yes, but I'd also like to understand what you're
> trying to fix exactly, because I don't see how it can be what you hinted
> at before.
The basic problem is that on handover from simpledrm -> msm
the clocks get turned off, without fully shutting down the
display pipeline first (since simpledrm does not know how).
Then when msm later tries to re-enable things, the hw is
in a confused state and we hit this error:
[ 2.980181] disp_cc_mdss_dptx3_pixel0_clk_src: rcg didn't update its configuration.
[ 2.980272] WARNING: drivers/clk/qcom/clk-rcg2.c:136 at update_config+0xdc/0x100
So we need a way to handover things to the msm driver
without anything getting disabled by simpledrm in an
uncontrolled (not following proper pwr-down seq) manner.
The idea behind the 2 step simpledrm removal process is
that on the first step drm_dev_unplug() gets called for
the simpledrm device and any struct resource claim on
the aperture gets released. While keeping all the clocks,
regulators, etc. claims.
Then msm can take things over and call the second step
when it has taken everything over. On the second step
simpeldrm will release its enable count ref on the clocks,
etc. in question.
In the mean time I've actually already prototyped this, see:
https://github.com/jwrdegoede/linux-sunxi/commits/main
Note this is my main wip branch with all kinda stuff
in there and this gets forced pushes regularly.
Regards,
Hans
p.s.
I've not posted this upstream yet because unlike
the __clk_disable_unprepare_counts_only() approach this
does not work atm, because it seems the msm driver only
claims some DP related clocks on the first modeset
from userspace rather then during probe().
This msm issue is something which we need to fix regardless,
also for when the clock framework gets moved to using
sync-state handling for turning off unused clocks, since
any clocks consumed by the msm dt-node will then also get
turned off directly after probe().
^ permalink raw reply
* Re: [PATCH] dt-bindings: clock: renesas,versaclock7: Update maintainer
From: Krzysztof Kozlowski @ 2026-06-24 9:41 UTC (permalink / raw)
To: Biju
Cc: Geert Uytterhoeven, 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, 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/
> ---
> .../devicetree/bindings/clock/renesas,versaclock7.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Please also update MAINTAINERS file.
Best regards,
Krzysztof
^ 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