linux-toradex.git/drivers/clk/qcom, branch master Linux kernel for Apalis and Colibri modules Merge tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux 2026-10-30T16:18:43+00:00 Linus Torvalds torvalds@linux-foundation.org 2026-10-30T16:18:43+00:00 4517b5a6c8745f244d89971dc34ec69f5a9eb3d5 Pull clk updates from Stephen Boyd: "Here's the clk changes for the merge window which is dominated in the diffstat by Qualcomm churning out new SoCs that need clk drivers. Looking beyond the sheer amount of lines of mostly data there we have a clk nexus DT binding change in the core clk framework and a driver core patch to add a subsys driver macro. The clock nexus support is useful for devices that map clks internally or for connectors on a board that route clock signals to another board. I suspect the use of this will expand in the future, so we have unit tests to make sure it doesn't break. The driver core change adds subsys_driver() and subsys_platform_driver() so we can register early drivers without open-coding that all (module_platform_driver() is at device initcall level so it isn't be used). Beyond the core framework bits we have lots of changes all over the tree to initialize 'struct clk_init_data'. The potential risk here is that someone forgets to initialize all the members of that structure and either the clk flags cause weird behavior later on or the parents are pointing at junk and the clk is orphaned forever. The patches just initialize the thing with zeroes to be safe. Longer term we should probably move this struct out of 'struct clk_hw' and pass it during clk registration time. That's a much bigger change and would require restructuring entire drivers that rely on the pointer being there. Finally, we have the usual fixes like calculation updates for dividers, handling error paths during clk registration, or fixing clk data now that drivers are using them. Those patches are dwarfed by the amount of new SoC support and only affect those SoCs and the consumers of those clks. Overall I'm more concerned the clk_init_data patches are going to expose some latent bugs that we didn't notice before because something was relying on clks being orphaned and now they're not. Core: - subsys_driver() / subsys_platform_driver() macros - Clock nexus DT binding support (with KUnit tests) - Spread-spectrum configuration validation - Fully initialize struct clk_init_data across many drivers New Drivers: - Anlogic DR1V90 CRU - ZTE zx297520v3 top, matrix, and LSP clocks - Samsung Exynos5515 and ACPM driver extended to Exynos850. - Qualcomm Eliza camera, camera-BIST, GPU, and video clks - Qualcomm Hawi / Maili camera and GPU controllers - Qualcomm Kuno global, RPMh - Qualcomm MSM8952 global, RPM - Qualcomm Nord camera/video clocks, EMAC interconnect, PHY resets - Qualcomm IPQ5210 / IPQ9650 network clocks - i.MX93 350 MHz fractional-N GP-PLL for display - i.MX pll14xx spread-spectrum clock generation - Amlogic A9 SCMI clock controller - Allwinner single-divider "update bit" support - EN7523 Serdes port selection" * tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (316 commits) clk: imx: pll14xx: support spread spectrum clock generation clk: cdce925: Size the PLL child name buffer for any int clk: stm32: fix clock array size for STM32MP21 dt-bindings: clock: Convert HiSilicon clocks to DT schema clk: lmk04832: Handle reset GPIO lookup errors dt-bindings: clock: anlogic,dr1v90-cru: make external clocks optional clk: tegra: bpmp: remove kcalloc clk: mmp2-audio: add missing PM_CLK dependency clk: zte: Introduce a driver for zx297520v3 LSP clocks clk: zte: Introduce a driver for zx297520v3 matrix clocks clk: zte: Introduce a driver for zx297520v3 top clocks clk: zte: Add zx PLL support infrastructure clk: zte: Add regmap-based clocks clk: zte: Add Clock registration infrastructure dt-bindings: clk: zte: Add zx297520v3 LSP clock and reset controller dt-bindings: clk: zte: Add zx297520v3 matrix clock and reset controller dt-bindings: clk: zte: Add zx297520v3 top clock and reset controller clk: nuvoton: ma35d1: Add missing WDT/WWDT parent clocks dt-bindings: clock: ma35d1: Add missing WDT/WWDT parent clocks dt-bindings: clock: ma35d1: Drop CLK_MAX_IDX define ... 
Pull clk updates from Stephen Boyd:
 "Here's the clk changes for the merge window which is dominated in the
  diffstat by Qualcomm churning out new SoCs that need clk drivers.

  Looking beyond the sheer amount of lines of mostly data there we have
  a clk nexus DT binding change in the core clk framework and a driver
  core patch to add a subsys driver macro.

  The clock nexus support is useful for devices that map clks internally
  or for connectors on a board that route clock signals to another
  board. I suspect the use of this will expand in the future, so we have
  unit tests to make sure it doesn't break.

  The driver core change adds subsys_driver() and
  subsys_platform_driver() so we can register early drivers without
  open-coding that all (module_platform_driver() is at device initcall
  level so it isn't be used).

  Beyond the core framework bits we have lots of changes all over the
  tree to initialize 'struct clk_init_data'. The potential risk here is
  that someone forgets to initialize all the members of that structure
  and either the clk flags cause weird behavior later on or the parents
  are pointing at junk and the clk is orphaned forever. The patches just
  initialize the thing with zeroes to be safe. Longer term we should
  probably move this struct out of 'struct clk_hw' and pass it during
  clk registration time. That's a much bigger change and would require
  restructuring entire drivers that rely on the pointer being there.

  Finally, we have the usual fixes like calculation updates for
  dividers, handling error paths during clk registration, or fixing clk
  data now that drivers are using them. Those patches are dwarfed by the
  amount of new SoC support and only affect those SoCs and the consumers
  of those clks. Overall I'm more concerned the clk_init_data patches
  are going to expose some latent bugs that we didn't notice before
  because something was relying on clks being orphaned and now they're
  not.

  Core:
   - subsys_driver() / subsys_platform_driver() macros
   - Clock nexus DT binding support (with KUnit tests)
   - Spread-spectrum configuration validation
   - Fully initialize struct clk_init_data across many drivers

  New Drivers:
   - Anlogic DR1V90 CRU
   - ZTE zx297520v3 top, matrix, and LSP clocks
   - Samsung Exynos5515 and ACPM driver extended to Exynos850.
   - Qualcomm Eliza camera, camera-BIST, GPU, and video clks
   - Qualcomm Hawi / Maili camera and GPU controllers
   - Qualcomm Kuno global, RPMh
   - Qualcomm MSM8952 global, RPM
   - Qualcomm Nord camera/video clocks, EMAC interconnect, PHY resets
   - Qualcomm IPQ5210 / IPQ9650 network clocks
   - i.MX93 350 MHz fractional-N GP-PLL for display
   - i.MX pll14xx spread-spectrum clock generation
   - Amlogic A9 SCMI clock controller
   - Allwinner single-divider "update bit" support
   - EN7523 Serdes port selection"

* tag 'clk-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux: (316 commits)
  clk: imx: pll14xx: support spread spectrum clock generation
  clk: cdce925: Size the PLL child name buffer for any int
  clk: stm32: fix clock array size for STM32MP21
  dt-bindings: clock: Convert HiSilicon clocks to DT schema
  clk: lmk04832: Handle reset GPIO lookup errors
  dt-bindings: clock: anlogic,dr1v90-cru: make external clocks optional
  clk: tegra: bpmp: remove kcalloc
  clk: mmp2-audio: add missing PM_CLK dependency
  clk: zte: Introduce a driver for zx297520v3 LSP clocks
  clk: zte: Introduce a driver for zx297520v3 matrix clocks
  clk: zte: Introduce a driver for zx297520v3 top clocks
  clk: zte: Add zx PLL support infrastructure
  clk: zte: Add regmap-based clocks
  clk: zte: Add Clock registration infrastructure
  dt-bindings: clk: zte: Add zx297520v3 LSP clock and reset controller
  dt-bindings: clk: zte: Add zx297520v3 matrix clock and reset controller
  dt-bindings: clk: zte: Add zx297520v3 top clock and reset controller
  clk: nuvoton: ma35d1: Add missing WDT/WWDT parent clocks
  dt-bindings: clock: ma35d1: Add missing WDT/WWDT parent clocks
  dt-bindings: clock: ma35d1: Drop CLK_MAX_IDX define
  ...
clk: qcom: Add support for camera clock controller on Maili 2026-10-13T14:49:59+00:00 Jagadeesh Kona jagadeesh.kona@oss.qualcomm.com 2026-09-22T03:56:38+00:00 5c32769895e75914e03031b3483775dabcfac264 Maili camcc is mostly identical to Hawi camcc, with a few clocks removed, frequency table updates for a few other clocks, and PLL configuration changes. Hence, reuse the Hawi camera clock controller driver and extend it for the Qualcomm Maili SoC. Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com> Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://patch.msgid.link/20260922-maili_camcc-v4-2-87704b664dde@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> 
Maili camcc is mostly identical to Hawi camcc, with a few clocks
removed, frequency table updates for a few other clocks, and PLL
configuration changes. Hence, reuse the Hawi camera clock controller
driver and extend it for the Qualcomm Maili SoC.

Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260922-maili_camcc-v4-2-87704b664dde@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
clk: qcom: ipq9650: Use icc-clk for enabling NoC related clocks 2026-10-13T14:49:44+00:00 Kathiravan Thirumoorthy kathiravan.thirumoorthy@oss.qualcomm.com 2026-08-11T15:53:09+00:00 c91ba2e1b7df08af950de391e59208356ecf3ed7 Register NoC clocks for PCIe and USB interconnect paths using the icc-clk framework. Without this, the clocks required to create interconnect paths and access peripherals connected to these NoCs are not properly managed. Also add icc_sync_state to ensure clock states are synchronized after all consumers have probed. Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Link: https://patch.msgid.link/20260811-ipq9650_icc-v2-2-55b8efbd62c6@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> 
Register NoC clocks for PCIe and USB interconnect paths using the
icc-clk framework. Without this, the clocks required to create
interconnect paths and access peripherals connected to these NoCs are
not properly managed.

Also add icc_sync_state to ensure clock states are synchronized after all
consumers have probed.

Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Link: https://patch.msgid.link/20260811-ipq9650_icc-v2-2-55b8efbd62c6@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
clk: qcom: ipq5210: add 24MHz rate for USB UTMI clock 2026-10-13T14:49:43+00:00 Kathiravan Thirumoorthy kathiravan.thirumoorthy@oss.qualcomm.com 2026-09-21T06:19:36+00:00 4d61492b5fa910ed59c4cbc699d2e5a03a5777d3 The USB UTMI reference clock must operate at 24 MHz, as recommended by the hardware team, for reliable USB operation. Validation showed that USB 3.2 hub enumeration with USB 2.0 devices fails when the UTMI reference clock is not configured to the required 24 MHz rate. Configuring the UTMI reference clock to 24 MHz to resolve the enumeration failure and ensure successful device detection. Cc: stable@vger.kernel.org Fixes: 844be6e24afd ("clk: qcom: add Global Clock controller (GCC) driver for IPQ5210 SoC") Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://patch.msgid.link/20260921-ipq_clk_changes-v1-3-d242e3d49648@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> 
The USB UTMI reference clock must operate at 24 MHz, as recommended
by the hardware team, for reliable USB operation.

Validation showed that USB 3.2 hub enumeration with USB 2.0 devices
fails when the UTMI reference clock is not configured to the required
24 MHz rate. Configuring the UTMI reference clock to 24 MHz to resolve
the enumeration failure and ensure successful device detection.

Cc: stable@vger.kernel.org
Fixes: 844be6e24afd ("clk: qcom: add Global Clock controller (GCC) driver for IPQ5210 SoC")
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260921-ipq_clk_changes-v1-3-d242e3d49648@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
clk: qcom: ipq5332: add 24MHz rate for USB UTMI clock 2026-10-13T14:49:43+00:00 Kathiravan Thirumoorthy kathiravan.thirumoorthy@oss.qualcomm.com 2026-09-21T06:19:35+00:00 19b62f31e15ef70dc927aab91b1576ea6c37f992 The USB UTMI reference clock must operate at 24 MHz, as recommended by the hardware team, for reliable USB operation. Validation showed that USB 3.2 hub enumeration with USB 2.0 devices fails when the UTMI reference clock is not configured to the required 24 MHz rate. Configuring the UTMI reference clock to 24 MHz to resolve the enumeration failure and ensure successful device detection. Cc: stable@vger.kernel.org Fixes: 3d89d52970fd ("clk: qcom: add Global Clock controller (GCC) driver for IPQ5332 SoC") Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://patch.msgid.link/20260921-ipq_clk_changes-v1-2-d242e3d49648@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> 
The USB UTMI reference clock must operate at 24 MHz, as recommended
by the hardware team, for reliable USB operation.

Validation showed that USB 3.2 hub enumeration with USB 2.0 devices
fails when the UTMI reference clock is not configured to the required
24 MHz rate. Configuring the UTMI reference clock to 24 MHz to resolve
the enumeration failure and ensure successful device detection.

Cc: stable@vger.kernel.org
Fixes: 3d89d52970fd ("clk: qcom: add Global Clock controller (GCC) driver for IPQ5332 SoC")
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260921-ipq_clk_changes-v1-2-d242e3d49648@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
clk: qcom: ipq5018: add 24MHz rate for USB UTMI clock 2026-10-13T14:49:43+00:00 Kathiravan Thirumoorthy kathiravan.thirumoorthy@oss.qualcomm.com 2026-09-21T06:19:34+00:00 75e893169fc5c9ec28d5f9dffde40ce29b59a5de The USB UTMI reference clock must operate at 24 MHz, as recommended by the hardware team, for reliable USB operation. Validation showed that USB 3.2 hub enumeration with USB 2.0 devices fails when the UTMI reference clock is not configured to the required 24 MHz rate. Configuring the UTMI reference clock to 24 MHz to resolve the enumeration failure and ensure successful device detection. Cc: stable@vger.kernel.org Fixes: e3fdbef1bab8 ("clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018") Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com> Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://patch.msgid.link/20260921-ipq_clk_changes-v1-1-d242e3d49648@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> 
The USB UTMI reference clock must operate at 24 MHz, as recommended
by the hardware team, for reliable USB operation.

Validation showed that USB 3.2 hub enumeration with USB 2.0 devices
fails when the UTMI reference clock is not configured to the required
24 MHz rate. Configuring the UTMI reference clock to 24 MHz to resolve
the enumeration failure and ensure successful device detection.

Cc: stable@vger.kernel.org
Fixes: e3fdbef1bab8 ("clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018")
Signed-off-by: Kathiravan Thirumoorthy <kathiravan.thirumoorthy@oss.qualcomm.com>
Reviewed-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260921-ipq_clk_changes-v1-1-d242e3d49648@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
clk: qcom: Fix camera rivian PLL configuration settings 2026-10-13T14:49:43+00:00 Jagadeesh Kona jagadeesh.kona@oss.qualcomm.com 2026-07-31T19:45:07+00:00 6666c03f2348886774d6441350fbe0e7a782f471 clk_alpha_pll_write_config() in the PLL configure function skips writes to PLL registers when the configured value is 0. However, hardware requires USER_CTL_U and CONFIG_CTL_U2 to be explicitly programmed to 0 for a few rivian PLLs. Add a clk_regs_configure() callback to ensure these rivian PLL registers are correctly initialized on Glymur, SM8750, and Kaanapali platforms. Fixes: 97255eedd690 ("clk: qcom: camcc-glymur: Add camera clock controller driver") Fixes: f9580bafd39c ("clk: qcom: camcc: Add camera clock controller driver for SM8750 SoC") Fixes: 92aae35f667c ("clk: qcom: camcc: Add support for camera clock controller for Kaanapali") Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com> Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://patch.msgid.link/20260801-cam-rivian-pll-config-fix-v1-1-6918d58cd823@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> 
clk_alpha_pll_write_config() in the PLL configure function skips writes
to PLL registers when the configured value is 0. However, hardware
requires USER_CTL_U and CONFIG_CTL_U2 to be explicitly programmed to 0
for a few rivian PLLs.

Add a clk_regs_configure() callback to ensure these rivian PLL registers
are correctly initialized on Glymur, SM8750, and Kaanapali platforms.

Fixes: 97255eedd690 ("clk: qcom: camcc-glymur: Add camera clock controller driver")
Fixes: f9580bafd39c ("clk: qcom: camcc: Add camera clock controller driver for SM8750 SoC")
Fixes: 92aae35f667c ("clk: qcom: camcc: Add support for camera clock controller for Kaanapali")
Signed-off-by: Jagadeesh Kona <jagadeesh.kona@oss.qualcomm.com>
Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com>
Link: https://patch.msgid.link/20260801-cam-rivian-pll-config-fix-v1-1-6918d58cd823@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
clk: qcom: videocc-sm8350: Use common probe handling for always-on clocks 2026-10-13T14:49:43+00:00 Abel Vesa abel.vesa@oss.qualcomm.com 2026-09-24T12:07:00+00:00 4baa772ecd41dfc45af27f3557e394d679a96d5a Describe the always-on branches in a critical_cbcrs array and reference it through qcom_cc_driver_data. Let qcom_cc_really_probe() enable these branches instead of programming them directly in the driver's probe. Keep separate CBCR arrays for SM8350 and SC8280XP to preserve their different XO clock register offsets. Assisted-by: LLM Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://patch.msgid.link/20260924-clk-qcom-rework-legacy-always-on-clocks-v2-48-1479443ee016@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> 
Describe the always-on branches in a critical_cbcrs array and reference
it through qcom_cc_driver_data. Let qcom_cc_really_probe() enable these
branches instead of programming them directly in the driver's probe.

Keep separate CBCR arrays for SM8350 and SC8280XP to preserve their
different XO clock register offsets.

Assisted-by: LLM
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260924-clk-qcom-rework-legacy-always-on-clocks-v2-48-1479443ee016@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
clk: qcom: videocc-sm8250: Use common probe handling for always-on clocks 2026-10-13T14:49:43+00:00 Abel Vesa abel.vesa@oss.qualcomm.com 2026-09-24T12:06:59+00:00 0bbc2402d82d050aca4297186aac3ea941fd53a4 Describe the always-on branches in a critical_cbcrs array and reference it through qcom_cc_driver_data. Let qcom_cc_really_probe() enable these branches instead of programming them directly in the driver's probe. Assisted-by: LLM Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://patch.msgid.link/20260924-clk-qcom-rework-legacy-always-on-clocks-v2-47-1479443ee016@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> 
Describe the always-on branches in a critical_cbcrs array and reference
it through qcom_cc_driver_data. Let qcom_cc_really_probe() enable these
branches instead of programming them directly in the driver's probe.

Assisted-by: LLM
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260924-clk-qcom-rework-legacy-always-on-clocks-v2-47-1479443ee016@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
clk: qcom: videocc-sm7150: Use common probe handling for always-on clocks 2026-10-13T14:49:43+00:00 Abel Vesa abel.vesa@oss.qualcomm.com 2026-09-24T12:06:58+00:00 7cd427f13a099f35ff96cd00f0ebabbf8e7eee7e Describe the always-on branches in a critical_cbcrs array and reference it through qcom_cc_driver_data. Let qcom_cc_really_probe() enable these branches instead of programming them directly in the driver's probe. Assisted-by: LLM Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com> Link: https://patch.msgid.link/20260924-clk-qcom-rework-legacy-always-on-clocks-v2-46-1479443ee016@oss.qualcomm.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> 
Describe the always-on branches in a critical_cbcrs array and reference
it through qcom_cc_driver_data. Let qcom_cc_really_probe() enable these
branches instead of programming them directly in the driver's probe.

Assisted-by: LLM
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
Link: https://patch.msgid.link/20260924-clk-qcom-rework-legacy-always-on-clocks-v2-46-1479443ee016@oss.qualcomm.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>