linux-stable.git/drivers/clk, branch v5.4.294 Linux kernel stable tree clk: check for disabled clock-provider in of_clk_get_hw_from_clkspec() 2025-05-02T05:39:28+00:00 Heiko Stuebner heiko@sntech.de 2025-02-22T22:37:33+00:00 e31c2569c8142093bafafd5e2675a14807f732f7 [ Upstream commit b20150d499b3ee5c2d632fbc5ac94f98dd33accf ] of_clk_get_hw_from_clkspec() checks all available clock-providers by comparing their of nodes to the one from the clkspec. If no matching clock provider is found, the function returns -EPROBE_DEFER to cause a re-check at a later date. If a matching clock provider is found, an authoritative answer can be retrieved from it whether the clock exists or not. This does not take into account that the clock-provider may never appear, because it's node is disabled. This can happen when a clock is optional, provided by a separate block which never gets enabled. One example of this happening is the rk3588's VOP, which has optional additional display clocks coming from PLLs inside the hdmiphy blocks. These can be used for better rates, but the system will also work without them. The problem around that is described in the followups to[1]. As we already know the of node of the presumed clock provider, add a check via of_device_is_available() whether this is a "valid" device node. This prevents eternal defer loops. Link: https://lore.kernel.org/dri-devel/20250215-vop2-hdmi1-disp-modes-v1-3-81962a7151d6@collabora.com/ [1] Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com> Tested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com> Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250222223733.2990179-1-heiko@sntech.de [sboyd@kernel.org: Reword commit text a bit] Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit b20150d499b3ee5c2d632fbc5ac94f98dd33accf ]

of_clk_get_hw_from_clkspec() checks all available clock-providers by
comparing their of nodes to the one from the clkspec. If no matching
clock provider is found, the function returns -EPROBE_DEFER to cause a
re-check at a later date. If a matching clock provider is found, an
authoritative answer can be retrieved from it whether the clock exists
or not.

This does not take into account that the clock-provider may never
appear, because it's node is disabled. This can happen when a clock is
optional, provided by a separate block which never gets enabled.

One example of this happening is the rk3588's VOP, which has optional
additional display clocks coming from PLLs inside the hdmiphy blocks.
These can be used for better rates, but the system will also work
without them.

The problem around that is described in the followups to[1]. As we
already know the of node of the presumed clock provider, add a check via
of_device_is_available() whether this is a "valid" device node. This
prevents eternal defer loops.

Link: https://lore.kernel.org/dri-devel/20250215-vop2-hdmi1-disp-modes-v1-3-81962a7151d6@collabora.com/ [1]
Reviewed-by: Sebastian Reichel <sebastian.reichel@collabora.com>
Tested-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Link: https://lore.kernel.org/r/20250222223733.2990179-1-heiko@sntech.de
[sboyd@kernel.org: Reword commit text a bit]
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
clk: amlogic: g12a: fix mmc A peripheral clock 2025-04-10T12:29:41+00:00 Jerome Brunet jbrunet@baylibre.com 2024-12-13T10:03:23+00:00 62ae4a1b2917097db784b34f9de1317d7be906f9 [ Upstream commit 0079e77c08de692cb20b38e408365c830a44b1ef ] The bit index of the peripheral clock for mmc A is wrong This was probably not a problem for mmc A as the peripheral is likely left enabled by the bootloader. No issues has been reported so far but it could be a problem, most likely some form of conflict between the ethernet and mmc A clock, breaking ethernet on init. Use the value provided by the documentation for mmc A before this becomes an actual problem. Fixes: 085a4ea93d54 ("clk: meson: g12a: add peripheral clock controller") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20241213-amlogic-clk-g12a-mmca-fix-v1-1-5af421f58b64@baylibre.com Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 0079e77c08de692cb20b38e408365c830a44b1ef ]

The bit index of the peripheral clock for mmc A is wrong
This was probably not a problem for mmc A as the peripheral is likely left
enabled by the bootloader.

No issues has been reported so far but it could be a problem, most likely
some form of conflict between the ethernet and mmc A clock, breaking
ethernet on init.

Use the value provided by the documentation for mmc A before this
becomes an actual problem.

Fixes: 085a4ea93d54 ("clk: meson: g12a: add peripheral clock controller")
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20241213-amlogic-clk-g12a-mmca-fix-v1-1-5af421f58b64@baylibre.com
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
clk: amlogic: gxbb: drop non existing 32k clock parent 2025-04-10T12:29:41+00:00 Jerome Brunet jbrunet@baylibre.com 2024-12-20T10:25:37+00:00 450a1d9eac98886c7d19586dd10e72a4eaf8e1bc [ Upstream commit 7915d7d5407c026fa9343befb4d3343f7a345f97 ] The 32k clock reference a parent 'cts_slow_oscin' with a fixme note saying that this clock should be provided by AO controller. The HW probably has this clock but it does not exist at the moment in any controller implementation. Furthermore, referencing clock by the global name should be avoided whenever possible. There is no reason to keep this hack around, at least for now. Fixes: 14c735c8e308 ("clk: meson-gxbb: Add EE 32K Clock for CEC") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20241220-amlogic-clk-gxbb-32k-fixes-v1-2-baca56ecf2db@baylibre.com Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 7915d7d5407c026fa9343befb4d3343f7a345f97 ]

The 32k clock reference a parent 'cts_slow_oscin' with a fixme note saying
that this clock should be provided by AO controller.

The HW probably has this clock but it does not exist at the moment in
any controller implementation. Furthermore, referencing clock by the global
name should be avoided whenever possible.

There is no reason to keep this hack around, at least for now.

Fixes: 14c735c8e308 ("clk: meson-gxbb: Add EE 32K Clock for CEC")
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20241220-amlogic-clk-gxbb-32k-fixes-v1-2-baca56ecf2db@baylibre.com
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
clk: amlogic: g12b: fix cluster A parent data 2025-04-10T12:29:41+00:00 Jerome Brunet jbrunet@baylibre.com 2024-12-13T14:30:17+00:00 d15e95d7b846e7f20ea152abc0e11522fe92724a [ Upstream commit 8995f8f108c3ac5ad52b12a6cfbbc7b3b32e9a58 ] Several clocks used by both g12a and g12b use the g12a cpu A clock hw pointer as clock parent. This is incorrect on g12b since the parents of cluster A cpu clock are different. Also the hw clock provided as parent to these children is not even registered clock on g12b. Fix the problem by reverting to the global namespace and let CCF pick the appropriate, as it is already done for other clocks, such as cpu_clk_trace_div. Fixes: 25e682a02d91 ("clk: meson: g12a: migrate to the new parent description method") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20241213-amlogic-clk-g12a-cpua-parent-fix-v1-1-d8c0f41865fe@baylibre.com Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 8995f8f108c3ac5ad52b12a6cfbbc7b3b32e9a58 ]

Several clocks used by both g12a and g12b use the g12a cpu A clock hw
pointer as clock parent. This is incorrect on g12b since the parents of
cluster A cpu clock are different. Also the hw clock provided as parent to
these children is not even registered clock on g12b.

Fix the problem by reverting to the global namespace and let CCF pick
the appropriate, as it is already done for other clocks, such as
cpu_clk_trace_div.

Fixes: 25e682a02d91 ("clk: meson: g12a: migrate to the new parent description method")
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20241213-amlogic-clk-g12a-cpua-parent-fix-v1-1-d8c0f41865fe@baylibre.com
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
clk: rockchip: rk3328: fix wrong clk_ref_usb3otg parent 2025-04-10T12:29:41+00:00 Peter Geis pgwipeout@gmail.com 2025-01-15T01:26:22+00:00 64f805c30c32d69809288f0f3d49c1d2254e2956 [ Upstream commit a9e60f1ffe1ca57d6af6a2573e2f950e76efbf5b ] Correct the clk_ref_usb3otg parent to fix clock control for the usb3 controller on rk3328. Verified against the rk3328 trm, the rk3228h trm, and the rk3328 usb3 phy clock map. Fixes: fe3511ad8a1c ("clk: rockchip: add clock controller for rk3328") Signed-off-by: Peter Geis <pgwipeout@gmail.com> Reviewed-by: Dragan Simic <dsimic@manjaro.org> Link: https://lore.kernel.org/r/20250115012628.1035928-2-pgwipeout@gmail.com Signed-off-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit a9e60f1ffe1ca57d6af6a2573e2f950e76efbf5b ]

Correct the clk_ref_usb3otg parent to fix clock control for the usb3
controller on rk3328. Verified against the rk3328 trm, the rk3228h trm,
and the rk3328 usb3 phy clock map.

Fixes: fe3511ad8a1c ("clk: rockchip: add clock controller for rk3328")
Signed-off-by: Peter Geis <pgwipeout@gmail.com>
Reviewed-by: Dragan Simic <dsimic@manjaro.org>
Link: https://lore.kernel.org/r/20250115012628.1035928-2-pgwipeout@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
clk: amlogic: gxbb: drop incorrect flag on 32k clock 2025-04-10T12:29:40+00:00 Jerome Brunet jbrunet@baylibre.com 2024-12-20T10:25:36+00:00 671760004d52f1a2d2a0ac8e4725f4d489ed0248 [ Upstream commit f38f7fe4830c5cb4eac138249225f119e7939965 ] gxbb_32k_clk_div sets CLK_DIVIDER_ROUND_CLOSEST in the init_data flag which is incorrect. This is field is not where the divider flags belong. Thankfully, CLK_DIVIDER_ROUND_CLOSEST maps to bit 4 which is an unused clock flag, so there is no unintended consequence to this error. Effectively, the clock has been used without CLK_DIVIDER_ROUND_CLOSEST so far, so just drop it. Fixes: 14c735c8e308 ("clk: meson-gxbb: Add EE 32K Clock for CEC") Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org> Link: https://lore.kernel.org/r/20241220-amlogic-clk-gxbb-32k-fixes-v1-1-baca56ecf2db@baylibre.com Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit f38f7fe4830c5cb4eac138249225f119e7939965 ]

gxbb_32k_clk_div sets CLK_DIVIDER_ROUND_CLOSEST in the init_data flag which
is incorrect. This is field is not where the divider flags belong.

Thankfully, CLK_DIVIDER_ROUND_CLOSEST maps to bit 4 which is an unused
clock flag, so there is no unintended consequence to this error.

Effectively, the clock has been used without CLK_DIVIDER_ROUND_CLOSEST
so far, so just drop it.

Fixes: 14c735c8e308 ("clk: meson-gxbb: Add EE 32K Clock for CEC")
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Link: https://lore.kernel.org/r/20241220-amlogic-clk-gxbb-32k-fixes-v1-1-baca56ecf2db@baylibre.com
Signed-off-by: Jerome Brunet <jbrunet@baylibre.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
clk: qcom: clk-rpmh: prevent integer overflow in recalc_rate 2025-03-13T11:43:07+00:00 Anastasia Belova abelova@astralinux.ru 2024-12-03T08:42:31+00:00 523003eb6c9420cf6026d860b420120ef5d85443 commit 89aa5925d201b90a48416784831916ca203658f9 upstream. aggr_state and unit fields are u32. The result of their multiplication may not fit in this type. Add explicit casting to prevent overflow. Found by Linux Verification Center (linuxtesting.org) with SVACE. Fixes: 04053f4d23a4 ("clk: qcom: clk-rpmh: Add IPA clock support") Cc: stable@vger.kernel.org # 5.4+ Signed-off-by: Anastasia Belova <abelova@astralinux.ru> Link: https://lore.kernel.org/r/20241203084231.6001-1-abelova@astralinux.ru Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 89aa5925d201b90a48416784831916ca203658f9 upstream.

aggr_state and unit fields are u32. The result of their
multiplication may not fit in this type.

Add explicit casting to prevent overflow.

Found by Linux Verification Center (linuxtesting.org) with SVACE.

Fixes: 04053f4d23a4 ("clk: qcom: clk-rpmh: Add IPA clock support")
Cc: stable@vger.kernel.org # 5.4+
Signed-off-by: Anastasia Belova <abelova@astralinux.ru>
Link: https://lore.kernel.org/r/20241203084231.6001-1-abelova@astralinux.ru
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
clk: qcom: clk-alpha-pll: fix alpha mode configuration 2025-03-13T11:43:07+00:00 Gabor Juhos j4g8y7@gmail.com 2024-10-21T17:32:48+00:00 5d549136fa90ca040b382f29e142e2abfd1db77d commit 33f1722eb86e45320a3dd7b3d42f6593a1d595c2 upstream. Commit c45ae598fc16 ("clk: qcom: support for alpha mode configuration") added support for configuring alpha mode, but it seems that the feature was never working in practice. The value of the alpha_{en,mode}_mask members of the configuration gets added to the value parameter passed to the regmap_update_bits() function, however the same values are not getting applied to the bitmask. As the result, the respective bits in the USER_CTL register are never modifed which leads to improper configuration of several PLLs. The following table shows the PLL configurations where the 'alpha_en_mask' member is set and which are passed as a parameter for the clk_alpha_pll_configure() function. In the table the 'expected rate' column shows the rate the PLL should run at with the given configuration, and the 'real rate' column shows the rate the PLL runs at actually. The real rates has been verified on hardwareOn IPQ* platforms, on other platforms, those are computed values only. file pll expected rate real rate dispcc-qcm2290.c disp_cc_pll0 768.0 MHz 768.0 MHz dispcc-sm6115.c disp_cc_pll0 768.0 MHz 768.0 MHz gcc-ipq5018.c ubi32_pll 1000.0 MHz != 984.0 MHz gcc-ipq6018.c nss_crypto_pll 1200.0 MHz 1200.0 MHz gcc-ipq6018.c ubi32_pll 1497.6 MHz != 1488.0 MHz gcc-ipq8074.c nss_crypto_pll 1200.0 MHz != 1190.4 MHz gcc-qcm2290.c gpll11 532.0 MHz != 518.4 MHz gcc-qcm2290.c gpll8 533.2 MHz != 518.4 MHz gcc-qcs404.c gpll3 921.6 MHz 921.6 MHz gcc-sm6115.c gpll11 600.0 MHz != 595.2 MHz gcc-sm6115.c gpll8 800.0 MHz != 787.2 MHz gpucc-sdm660.c gpu_cc_pll0 800.0 MHz != 787.2 MHz gpucc-sdm660.c gpu_cc_pll1 740.0 MHz != 729.6 MHz gpucc-sm6115.c gpu_cc_pll0 1200.0 MHz != 1190.4 MHz gpucc-sm6115.c gpu_cc_pll1 640.0 MHz != 633.6 MHz gpucc-sm6125.c gpu_pll0 1020.0 MHz != 1017.6 MHz gpucc-sm6125.c gpu_pll1 930.0 MHz != 921.6 MHz mmcc-sdm660.c mmpll8 930.0 MHz != 921.6 MHz mmcc-sdm660.c mmpll5 825.0 MHz != 806.4 MHz As it can be seen from the above, there are several PLLs which are configured incorrectly. Change the code to apply both 'alpha_en_mask' and 'alpha_mode_mask' values to the bitmask in order to configure the alpha mode correctly. Applying the 'alpha_en_mask' fixes the initial rate of the PLLs showed in the table above. Since the 'alpha_mode_mask' is not used by any driver currently, that part of the change causes no functional changes. Cc: stable@vger.kernel.org Fixes: c45ae598fc16 ("clk: qcom: support for alpha mode configuration") Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Gabor Juhos <j4g8y7@gmail.com> Link: https://lore.kernel.org/r/20241021-fix-alpha-mode-config-v1-1-f32c254e02bc@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 33f1722eb86e45320a3dd7b3d42f6593a1d595c2 upstream.

Commit c45ae598fc16 ("clk: qcom: support for alpha mode configuration")
added support for configuring alpha mode, but it seems that the feature
was never working in practice.

The value of the alpha_{en,mode}_mask members of the configuration gets
added to the value parameter passed to the regmap_update_bits() function,
however the same values are not getting applied to the bitmask. As the
result, the respective bits in the USER_CTL register are never modifed
which leads to improper configuration of several PLLs.

The following table shows the PLL configurations where the 'alpha_en_mask'
member is set and which are passed as a parameter for the
clk_alpha_pll_configure() function. In the table the 'expected rate' column
shows the rate the PLL should run at with the given configuration, and
the 'real rate' column shows the rate the PLL runs at actually. The real
rates has been verified on hardwareOn IPQ* platforms, on other platforms,
those are computed values only.

      file                 pll         expected rate   real rate
  dispcc-qcm2290.c     disp_cc_pll0      768.0 MHz     768.0 MHz
  dispcc-sm6115.c      disp_cc_pll0      768.0 MHz     768.0 MHz
  gcc-ipq5018.c        ubi32_pll        1000.0 MHz !=  984.0 MHz
  gcc-ipq6018.c        nss_crypto_pll   1200.0 MHz    1200.0 MHz
  gcc-ipq6018.c        ubi32_pll        1497.6 MHz != 1488.0 MHz
  gcc-ipq8074.c        nss_crypto_pll   1200.0 MHz != 1190.4 MHz
  gcc-qcm2290.c        gpll11            532.0 MHz !=  518.4 MHz
  gcc-qcm2290.c        gpll8             533.2 MHz !=  518.4 MHz
  gcc-qcs404.c         gpll3             921.6 MHz     921.6 MHz
  gcc-sm6115.c         gpll11            600.0 MHz !=  595.2 MHz
  gcc-sm6115.c         gpll8             800.0 MHz !=  787.2 MHz
  gpucc-sdm660.c       gpu_cc_pll0       800.0 MHz !=  787.2 MHz
  gpucc-sdm660.c       gpu_cc_pll1       740.0 MHz !=  729.6 MHz
  gpucc-sm6115.c       gpu_cc_pll0      1200.0 MHz != 1190.4 MHz
  gpucc-sm6115.c       gpu_cc_pll1       640.0 MHz !=  633.6 MHz
  gpucc-sm6125.c       gpu_pll0         1020.0 MHz != 1017.6 MHz
  gpucc-sm6125.c       gpu_pll1          930.0 MHz !=  921.6 MHz
  mmcc-sdm660.c        mmpll8            930.0 MHz !=  921.6 MHz
  mmcc-sdm660.c        mmpll5            825.0 MHz !=  806.4 MHz

As it can be seen from the above, there are several PLLs which are
configured incorrectly.

Change the code to apply both 'alpha_en_mask' and 'alpha_mode_mask'
values to the bitmask in order to configure the alpha mode correctly.

Applying the 'alpha_en_mask' fixes the initial rate of the PLLs showed
in the table above. Since the 'alpha_mode_mask' is not used by any driver
currently, that part of the change causes no functional changes.

Cc: stable@vger.kernel.org
Fixes: c45ae598fc16 ("clk: qcom: support for alpha mode configuration")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Tested-by: Gabor Juhos <j4g8y7@gmail.com>
Link: https://lore.kernel.org/r/20241021-fix-alpha-mode-config-v1-1-f32c254e02bc@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
clk: analogbits: Fix incorrect calculation of vco rate delta 2025-03-13T11:42:55+00:00 Bo Gan ganboing@gmail.com 2024-08-30T06:16:39+00:00 a24287200bb060eb5a6554063dbd6c582cd67bb9 [ Upstream commit d7f12857f095ef38523399d47e68787b357232f6 ] In wrpll_configure_for_rate() we try to determine the best PLL configuration for a target rate. However, in the loop where we try values of R, we should compare the derived `vco` with `target_vco_rate`. However, we were in fact comparing it with `target_rate`, which is actually after Q shift. This is incorrect, and sometimes can result in suboptimal clock rates. Fix it. Fixes: 7b9487a9a5c4 ("clk: analogbits: add Wide-Range PLL library") Signed-off-by: Bo Gan <ganboing@gmail.com> Link: https://lore.kernel.org/r/20240830061639.2316-1-ganboing@gmail.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit d7f12857f095ef38523399d47e68787b357232f6 ]

In wrpll_configure_for_rate() we try to determine the best PLL
configuration for a target rate. However, in the loop where we try
values of R, we should compare the derived `vco` with `target_vco_rate`.
However, we were in fact comparing it with `target_rate`, which is
actually after Q shift. This is incorrect, and sometimes can result in
suboptimal clock rates. Fix it.

Fixes: 7b9487a9a5c4 ("clk: analogbits: add Wide-Range PLL library")
Signed-off-by: Bo Gan <ganboing@gmail.com>
Link: https://lore.kernel.org/r/20240830061639.2316-1-ganboing@gmail.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
clk: qcom: gcc-qcs404: fix initial rate of GPLL3 2024-12-14T18:44:43+00:00 Gabor Juhos j4g8y7@gmail.com 2024-10-22T09:45:56+00:00 a42d050d07b8fd15b0574175857535a116bc5072 commit 36d202241d234fa4ac50743510d098ad52bd193a upstream. The comment before the config of the GPLL3 PLL says that the PLL should run at 930 MHz. In contrary to this, calculating the frequency from the current configuration values by using 19.2 MHz as input frequency defined in 'qcs404.dtsi', it gives 921.6 MHz: $ xo=19200000; l=48; alpha=0x0; alpha_hi=0x0 $ echo "$xo * ($((l)) + $(((alpha_hi << 32 | alpha) >> 8)) / 2^32)" | bc -l 921600000.00000000000000000000 Set 'alpha_hi' in the configuration to a value used in downstream kernels [1][2] in order to get the correct output rate: $ xo=19200000; l=48; alpha=0x0; alpha_hi=0x70 $ echo "$xo * ($((l)) + $(((alpha_hi << 32 | alpha) >> 8)) / 2^32)" | bc -l 930000000.00000000000000000000 The change is based on static code analysis, compile tested only. [1] https://git.codelinaro.org/clo/la/kernel/msm-5.4/-/blob/kernel.lnx.5.4.r56-rel/drivers/clk/qcom/gcc-qcs404.c?ref_type=heads#L335 [2} https://git.codelinaro.org/clo/la/kernel/msm-5.15/-/blob/kernel.lnx.5.15.r49-rel/drivers/clk/qcom/gcc-qcs404.c?ref_type=heads#L127 Cc: stable@vger.kernel.org Fixes: 652f1813c113 ("clk: qcom: gcc: Add global clock controller driver for QCS404") Signed-off-by: Gabor Juhos <j4g8y7@gmail.com> Link: https://lore.kernel.org/r/20241022-fix-gcc-qcs404-gpll3-v1-1-c4d30d634d19@gmail.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 36d202241d234fa4ac50743510d098ad52bd193a upstream.

The comment before the config of the GPLL3 PLL says that the
PLL should run at 930 MHz. In contrary to this, calculating
the frequency from the current configuration values by using
19.2 MHz as input frequency defined in 'qcs404.dtsi', it gives
921.6 MHz:

  $ xo=19200000; l=48; alpha=0x0; alpha_hi=0x0
  $ echo "$xo * ($((l)) + $(((alpha_hi << 32 | alpha) >> 8)) / 2^32)" | bc -l
  921600000.00000000000000000000

Set 'alpha_hi' in the configuration to a value used in downstream
kernels [1][2] in order to get the correct output rate:

  $ xo=19200000; l=48; alpha=0x0; alpha_hi=0x70
  $ echo "$xo * ($((l)) + $(((alpha_hi << 32 | alpha) >> 8)) / 2^32)" | bc -l
  930000000.00000000000000000000

The change is based on static code analysis, compile tested only.

[1] https://git.codelinaro.org/clo/la/kernel/msm-5.4/-/blob/kernel.lnx.5.4.r56-rel/drivers/clk/qcom/gcc-qcs404.c?ref_type=heads#L335
[2} https://git.codelinaro.org/clo/la/kernel/msm-5.15/-/blob/kernel.lnx.5.15.r49-rel/drivers/clk/qcom/gcc-qcs404.c?ref_type=heads#L127

Cc: stable@vger.kernel.org
Fixes: 652f1813c113 ("clk: qcom: gcc: Add global clock controller driver for QCS404")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Link: https://lore.kernel.org/r/20241022-fix-gcc-qcs404-gpll3-v1-1-c4d30d634d19@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>