kernel/drivers/clk, branch linux-6.9.y

clk: qcom: apss-ipq-pll: remove 'config_ctl_hi_val' from Stromer pll configs

2024-07-25T07:53:36Z

[ Upstream commit 2ba8425678af422da37b6c9b50e9ce66f0f55cae ] Since the CONFIG_CTL register is only 32 bits wide in the Stromer and Stromer Plus PLLs , the 'config_ctl_hi_val' values from the IPQ5018 and IPQ5332 configurations are not used so remove those. No functional changes. Signed-off-by: Gabor Juhos Reviewed-by: Kathiravan Thirumoorthy Acked-by: Konrad Dybcio Link: https://lore.kernel.org/r/20240509-stromer-config-ctl-v1-1-6034e17b28d5@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

clk: mediatek: mt8183: Only enable runtime PM on mt8183-mfgcfg

2024-07-11T10:51:20Z

[ Upstream commit 878e845d8db04df9ff3bbbaac09d335b24153704 ] Commit 2f7b1d8b5505 ("clk: mediatek: Do a runtime PM get on controllers during probe") enabled runtime PM for all mediatek clock controllers, but this introduced an issue on the resume path. If a device resumes earlier than the clock controller and calls clk_prepare() when runtime PM is enabled on the controller, it will end up calling clk_pm_runtime_get(). But the subsequent pm_runtime_resume_and_get() call will fail because the runtime PM is temporarily disabled during suspend. To workaround this, introduce a need_runtime_pm flag and only enable it on mt8183-mfgcfg, which is the driver that observed deadlock previously. Hopefully mt8183-cfgcfg won't run into the issue at the resume stage because the GPU should have stopped rendering before the system calls suspend. Fixes: 2f7b1d8b5505 ("clk: mediatek: Do a runtime PM get on controllers during probe") Signed-off-by: Pin-yen Lin Link: https://lore.kernel.org/r/20240613120357.1043342-1-treapking@chromium.org Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin

clk: qcom: clk-alpha-pll: set ALPHA_EN bit for Stromer Plus PLLs

2024-07-11T10:51:20Z

[ Upstream commit 5a33a64524e6381c399e5e42571d9363ffc0bed4 ] The clk_alpha_pll_stromer_plus_set_rate() function does not sets the ALPHA_EN bit in the USER_CTL register, so setting rates which requires using alpha mode works only if the bit gets set already prior calling the function. Extend the function to set the ALPHA_EN bit in order to allow using fractional rates regardless whether the bit gets set previously or not. Fixes: 84da48921a97 ("clk: qcom: clk-alpha-pll: introduce stromer plus ops") Signed-off-by: Gabor Juhos Link: https://lore.kernel.org/r/20240508-stromer-plus-alpha-en-v1-1-6639ce01ca5b@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

clk: qcom: gcc-sm6350: Fix gpll6* & gpll7 parents

2024-07-11T10:51:20Z

[ Upstream commit 3414f41a13eb41db15c558fbc695466203dca4fa ] Both gpll6 and gpll7 are parented to CXO at 19.2 MHz and not to GPLL0 which runs at 600 MHz. Also gpll6_out_even should have the parent gpll6 and not gpll0. Adjust the parents of these clocks to make Linux report the correct rate and not absurd numbers like gpll7 at ~25 GHz or gpll6 at 24 GHz. Corrected rates are the following: gpll7 807999902 Hz gpll6 768000000 Hz gpll6_out_even 384000000 Hz gpll0 600000000 Hz gpll0_out_odd 200000000 Hz gpll0_out_even 300000000 Hz And because gpll6 is the parent of gcc_sdcc2_apps_clk_src (at 202 MHz) that clock also reports the correct rate now and avoids this warning: [ 5.984062] mmc0: Card appears overclocked; req 202000000 Hz, actual 6312499237 Hz Fixes: 131abae905df ("clk: qcom: Add SM6350 GCC driver") Signed-off-by: Luca Weiss Link: https://lore.kernel.org/r/20240508-sm6350-gpll-fix-v1-1-e4ea34284a6d@fairphone.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin

clk: sunxi-ng: common: Don't call hw_to_ccu_common on hw without common

2024-07-11T10:51:18Z

commit ea977d742507e534d9fe4f4d74256f6b7f589338 upstream. In order to set the rate range of a hw sunxi_ccu_probe calls hw_to_ccu_common() assuming all entries in desc->ccu_clks are contained in a ccu_common struct. This assumption is incorrect and, in consequence, causes invalid pointer de-references. Remove the faulty call. Instead, add one more loop that iterates over the ccu_clks and sets the rate range, if required. Fixes: b914ec33b391 ("clk: sunxi-ng: common: Support minimum and maximum rate") Reported-by: Robert J. Pafford Closes: https://lore.kernel.org/lkml/DM6PR01MB58047C810DDD5D0AE397CADFF7C22@DM6PR01MB5804.prod.exchangelabs.com/ Cc: stable@vger.kernel.org Signed-off-by: Frank Oltmanns Tested-by: Robert J. Pafford Link: https://lore.kernel.org/r/20240623-sunxi-ng_fix_common_probe-v1-1-7c97e32824a1@oltmanns.dev Signed-off-by: Chen-Yu Tsai Signed-off-by: Greg Kroah-Hartman

clk: qcom: gcc-ipq9574: Add BRANCH_HALT_VOTED flag

2024-07-11T10:51:17Z

commit 72ceafb587a56e26c905472418c7dc2033c294d3 upstream. The crypto_ahb and crypto_axi clks are hardware voteable. This means that the halt bit isn't reliable because some other voter in the system, e.g. TrustZone, could be keeping the clk enabled when the kernel turns it off from clk_disable(). Make these clks use voting mode by changing the halt check to BRANCH_HALT_VOTED and toggle the voting bit in the voting register instead of directly controlling the branch by writing to the branch register. This fixes stuck clk warnings seen on ipq9574 and saves power by actually turning the clk off. Also changes the CRYPTO_AHB_CLK_ENA & CRYPTO_AXI_CLK_ENA offset to 0xb004 from 0x16014. Cc: stable@vger.kernel.org Fixes: f6b2bd9cb29a ("clk: qcom: gcc-ipq9574: Enable crypto clocks") Signed-off-by: Md Sadre Alam Link: https://lore.kernel.org/r/20240509105405.1262369-1-quic_mdalam@quicinc.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman

clk: sifive: Do not register clkdevs for PRCI clocks

2024-06-21T12:40:17Z

[ Upstream commit 2607133196c35f31892ee199ce7ffa717bea4ad1 ] These clkdevs were unnecessary, because systems using this driver always look up clocks using the devicetree. And as Russell King points out[1], since the provided device name was truncated, lookups via clkdev would never match. Recently, commit 8d532528ff6a ("clkdev: report over-sized strings when creating clkdev entries") caused clkdev registration to fail due to the truncation, and this now prevents the driver from probing. Fix the driver by removing the clkdev registration. Link: https://lore.kernel.org/linux-clk/ZkfYqj+OcAxd9O2t@shell.armlinux.org.uk/ [1] Fixes: 30b8e27e3b58 ("clk: sifive: add a driver for the SiFive FU540 PRCI IP block") Fixes: 8d532528ff6a ("clkdev: report over-sized strings when creating clkdev entries") Reported-by: Guenter Roeck Closes: https://lore.kernel.org/linux-clk/7eda7621-0dde-4153-89e4-172e4c095d01@roeck-us.net/ Suggested-by: Russell King Signed-off-by: Samuel Holland Link: https://lore.kernel.org/r/20240528001432.1200403-1-samuel.holland@sifive.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin

clk: qcom: apss-ipq-pll: use stromer ops for IPQ5018 to fix boot failure

2024-06-16T11:51:03Z

commit 5fce38e2a1a97900989d9fedebcf5a4dacdaee30 upstream. Booting v6.8 results in a hang on various IPQ5018 based boards. Investigating the problem showed that the hang happens when the clk_alpha_pll_stromer_plus_set_rate() function tries to write into the PLL_MODE register of the APSS PLL. Checking the downstream code revealed that it uses [1] stromer specific operations for IPQ5018, whereas in the current code the stromer plus specific operations are used. The ops in the 'ipq_pll_stromer_plus' clock definition can't be changed since that is needed for IPQ5332, so add a new alpha pll clock declaration which uses the correct stromer ops and use this new clock for IPQ5018 to avoid the boot failure. Also, change pll_type in 'ipq5018_pll_data' to CLK_ALPHA_PLL_TYPE_STROMER to better reflect that it is a Stromer PLL and change the apss_ipq_pll_probe() function accordingly. 1. https://git.codelinaro.org/clo/qsdk/oss/kernel/linux-ipq-5.4/-/blob/NHSS.QSDK.12.4/drivers/clk/qcom/apss-ipq5018.c#L67 Cc: stable@vger.kernel.org Fixes: 50492f929486 ("clk: qcom: apss-ipq-pll: add support for IPQ5018") Signed-off-by: Gabor Juhos Tested-by: Kathiravan Thirumoorthy Reviewed-by: Kathiravan Thirumoorthy Link: https://lore.kernel.org/r/20240315-apss-ipq-pll-ipq5018-hang-v2-1-6fe30ada2009@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman

clk: qcom: clk-alpha-pll: fix rate setting for Stromer PLLs

2024-06-16T11:51:03Z

commit 3c5b3e17b8fd1f1add5a9477306c355fab126977 upstream. The clk_alpha_pll_stromer_set_rate() function writes inproper values into the ALPHA_VAL{,_U} registers which results in wrong clock rates when the alpha value is used. The broken behaviour can be seen on IPQ5018 for example, when dynamic scaling sets the CPU frequency to 800000 KHz. In this case the CPU cores are running only at 792031 KHz: # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 800000 # cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq 792031 This happens because the function ignores the fact that the alpha value calculated by the alpha_pll_round_rate() function is only 32 bits wide which must be extended to 40 bits if it is used on a hardware which supports 40 bits wide values. Extend the clk_alpha_pll_stromer_set_rate() function to convert the alpha value to 40 bits before wrinting that into the registers in order to ensure that the hardware really uses the requested rate. After the change the CPU frequency is correct: # cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq 800000 # cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq 800000 Cc: stable@vger.kernel.org Fixes: e47a4f55f240 ("clk: qcom: clk-alpha-pll: Add support for Stromer PLLs") Reviewed-by: Dmitry Baryshkov Signed-off-by: Gabor Juhos Link: https://lore.kernel.org/r/20240328-alpha-pll-fix-stromer-set-rate-v3-1-1b79714c78bc@gmail.com Signed-off-by: Bjorn Andersson Signed-off-by: Greg Kroah-Hartman

clk: bcm: rpi: Assign ->num before accessing ->hws

2024-06-16T11:51:03Z

commit 6dc445c1905096b2ed4db1a84570375b4e00cc0f upstream. Commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of 'struct clk_hw_onecell_data' with __counted_by, which informs the bounds sanitizer about the number of elements in hws, so that it can warn when hws is accessed out of bounds. As noted in that change, the __counted_by member must be initialized with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialization because the number of elements is zero. This occurs in raspberrypi_discover_clocks() due to ->num being assigned after ->hws has been accessed: UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-raspberrypi.c:374:4 index 3 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]') Move the ->num initialization to before the first access of ->hws, which clears up the warning. Cc: stable@vger.kernel.org Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") Signed-off-by: Nathan Chancellor Link: https://lore.kernel.org/r/20240425-cbl-bcm-assign-counted-by-val-before-access-v1-2-e2db3b82d5ef@kernel.org Reviewed-by: Kees Cook Reviewed-by: Florian Fainelli Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman