kernel/linux.git/drivers/clk, branch v4.14.263

clk: bcm-2835: Remove rounding up the dividers

2022-01-27T08:00:49+00:00

[ Upstream commit 8ca011ef4af48a7af7b15afd8a4a44039dd04cea ] The driver, once it found a divider, tries to round it up by increasing the least significant bit of the fractional part by one when the round_up argument is set and there's a remainder. However, since it increases the divider it will actually reduce the clock rate below what we were asking for, leading to issues with clk_set_min_rate() that will complain that our rounded clock rate is below the minimum of the rate. Since the dividers are fairly precise already, let's remove that part so that we can have clk_set_min_rate() working. This is effectively a revert of 9c95b32ca093 ("clk: bcm2835: add a round up ability to the clock divisor"). Fixes: 9c95b32ca093 ("clk: bcm2835: add a round up ability to the clock divisor") Signed-off-by: Maxime Ripard Acked-by: Stephen Boyd Reviewed-by: Nicolas Saenz Julienne Tested-by: Nicolas Saenz Julienne # boot and basic functionality Tested-by: Michael Stapelberg Link: https://patchwork.freedesktop.org/patch/msgid/20210922125419.4125779-3-maxime@cerno.tech Signed-off-by: Sasha Levin

clk: bcm-2835: Pick the closest clock rate

2022-01-27T08:00:48+00:00

[ Upstream commit 5517357a4733d7cf7c17fc79d0530cfa47add372 ] The driver currently tries to pick the closest rate that is lower than the rate being requested. This causes an issue with clk_set_min_rate() since it actively checks for the rounded rate to be above the minimum that was just set. Let's change the logic a bit to pick the closest rate to the requested rate, no matter if it's actually higher or lower. Fixes: 6d18b8adbe67 ("clk: bcm2835: Support for clock parent selection") Signed-off-by: Maxime Ripard Acked-by: Stephen Boyd Reviewed-by: Nicolas Saenz Julienne Tested-by: Nicolas Saenz Julienne # boot and basic functionality Tested-by: Michael Stapelberg Link: https://patchwork.freedesktop.org/patch/msgid/20210922125419.4125779-2-maxime@cerno.tech Signed-off-by: Sasha Levin

clk: kirkwood: Fix a clocking boot regression

2021-09-22T09:45:23+00:00

commit aaedb9e00e5400220a8871180d23a83e67f29f63 upstream. Since a few kernel releases the Pogoplug 4 has crashed like this during boot: Unable to handle kernel NULL pointer dereference at virtual address 00000002 (...) [] (strlen) from [] (kstrdup+0x1c/0x4c) [] (kstrdup) from [] (__clk_register+0x44/0x37c) [] (__clk_register) from [] (clk_hw_register+0x20/0x44) [] (clk_hw_register) from [] (__clk_hw_register_mux+0x198/0x1e4) [] (__clk_hw_register_mux) from [] (clk_register_mux_table+0x5c/0x6c) [] (clk_register_mux_table) from [] (kirkwood_clk_muxing_setup.constprop.0+0x13c/0x1ac) [] (kirkwood_clk_muxing_setup.constprop.0) from [] (of_clk_init+0x12c/0x214) [] (of_clk_init) from [] (time_init+0x20/0x2c) [] (time_init) from [] (start_kernel+0x3dc/0x56c) [] (start_kernel) from [<00000000>] (0x0) Code: e3130020 1afffffb e12fff1e c08a1078 (e5d03000) This is because the "powersave" mux clock 0 was provided in an unterminated array, which is required by the loop in the driver: /* Count, allocate, and register clock muxes */ for (n = 0; desc[n].name;) n++; Here n will go out of bounds and then call clk_register_mux() on random memory contents after the mux clock. Fix this by terminating the array with a blank entry. Fixes: 105299381d87 ("cpufreq: kirkwood: use the powersave multiplexer") Cc: stable@vger.kernel.org Cc: Andrew Lunn Cc: Chris Packham Cc: Gregory CLEMENT Cc: Sebastian Hesselbarth Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20210814235514.403426-1-linus.walleij@linaro.org Reviewed-by: Andrew Lunn Signed-off-by: Stephen Boyd Signed-off-by: Greg Kroah-Hartman

clk: fix build warning for orphan_list

2021-09-22T09:45:15+00:00

In the backport of commit bdcf1dc25324 ("clk: Evict unregistered clks from parent caches") to the 4.19.y and 4.14.y stable trees, the orphan_list structure was placed in the wrong location, causing loads of build warnings on systems that do not define CONFIG_DEBUG_FS. Fix this up by moving the structure to the correct place in the file. Reported-by: "kernelci.org bot" Signed-off-by: Greg Kroah-Hartman

clk: stm32f4: fix post divisor setup for I2S/SAI PLLs

2021-08-15T11:03:28+00:00

[ Upstream commit 24b5b1978cd5a80db58e2a19db2f9c36fe8d4f7a ] Enabling the framebuffer leads to a system hang. Running, as a debug hack, the store_pan() function in drivers/video/fbdev/core/fbsysfs.c without taking the console_lock, allows to see the crash backtrace on the serial line. ~ # echo 0 0 > /sys/class/graphics/fb0/pan [ 9.719414] Unhandled exception: IPSR = 00000005 LR = fffffff1 [ 9.726937] CPU: 0 PID: 49 Comm: sh Not tainted 5.13.0-rc5 #9 [ 9.733008] Hardware name: STM32 (Device Tree Support) [ 9.738296] PC is at clk_gate_is_enabled+0x0/0x28 [ 9.743426] LR is at stm32f4_pll_div_set_rate+0xf/0x38 [ 9.748857] pc : [<0011e4be>] lr : [<0011f9e3>] psr: 0100000b [ 9.755373] sp : 00bc7be0 ip : 00000000 fp : 001f3ac4 [ 9.760812] r10: 002610d0 r9 : 01efe920 r8 : 00540560 [ 9.766269] r7 : 02e7ddb0 r6 : 0173eed8 r5 : 00000000 r4 : 004027c0 [ 9.773081] r3 : 0011e4bf r2 : 02e7ddb0 r1 : 0173eed8 r0 : 1d3267b8 [ 9.779911] xPSR: 0100000b [ 9.782719] CPU: 0 PID: 49 Comm: sh Not tainted 5.13.0-rc5 #9 [ 9.788791] Hardware name: STM32 (Device Tree Support) [ 9.794120] [<0000afa1>] (unwind_backtrace) from [<0000a33f>] (show_stack+0xb/0xc) [ 9.802421] [<0000a33f>] (show_stack) from [<0000a8df>] (__invalid_entry+0x4b/0x4c) The `pll_num' field in the post_div_data configuration contained a wrong value which also referenced an uninitialized hardware clock when clk_register_pll_div() was called. Fixes: 517633ef630e ("clk: stm32f4: Add post divisor for I2S & SAI PLLs") Signed-off-by: Dario Binacchi Reviewed-by: Gabriel Fernandez Link: https://lore.kernel.org/r/20210725160725.10788-1-dariobin@libero.it Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin

clk: tegra: Ensure that PLLU configuration is applied properly

2021-07-20T14:17:43+00:00

[ Upstream commit a7196048cd5168096c2c4f44a3939d7a6dcd06b9 ] The PLLU (USB) consists of the PLL configuration itself and configuration of the PLLU outputs. The PLLU programming is inconsistent on T30 vs T114, where T114 immediately bails out if PLLU is enabled and T30 re-enables a potentially already enabled PLL (left after bootloader) and then fully reprograms it, which could be unsafe to do. The correct way should be to skip enabling of the PLL if it's already enabled and then apply configuration to the outputs. This patch doesn't fix any known problems, it's a minor improvement. Acked-by: Thierry Reding Signed-off-by: Dmitry Osipenko Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin

clk: renesas: r8a77995: Add ZA2 clock

2021-07-20T14:17:43+00:00

[ Upstream commit 790c06cc5df263cdaff748670cc65958c81b0951 ] R-Car D3 ZA2 clock is from PLL0D3 or S0, and it can be controlled by ZA2CKCR. It is needed for R-Car Sound, but is not used so far. Using default settings is very enough at this point. This patch adds it by DEF_FIXED(). Signed-off-by: Kuninori Morimoto Link: https://lore.kernel.org/r/87pmxclrmy.wl-kuninori.morimoto.gx@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin

clk: exynos7: Mark aclk_fsys1_200 as critical

2021-05-22T08:57:41+00:00

commit 34138a59b92c1a30649a18ec442d2e61f3bc34dd upstream. This clock must be always enabled to allow access to any registers in fsys1 CMU. Until proper solution based on runtime PM is applied (similar to what was done for Exynos5433), mark that clock as critical so it won't be disabled. It was observed on Samsung Galaxy S6 device (based on Exynos7420), where UFS module is probed before pmic used to power that device. In this case defer probe was happening and that clock was disabled by UFS driver, causing whole boot to hang on next CMU access. Fixes: 753195a749a6 ("clk: samsung: exynos7: Correct CMU_FSYS1 clocks names") Signed-off-by: Paweł Chmiel Acked-by: Krzysztof Kozlowski Link: https://lore.kernel.org/linux-clk/20201024154346.9589-1-pawel.mikolaj.chmiel@gmail.com [s.nawrocki: Added comment in the code] Signed-off-by: Sylwester Nawrocki Signed-off-by: Greg Kroah-Hartman

clk: uniphier: Fix potential infinite loop

2021-05-22T08:57:31+00:00

[ Upstream commit f6b1340dc751a6caa2a0567b667d0f4f4172cd58 ] The for-loop iterates with a u8 loop counter i and compares this with the loop upper limit of num_parents that is an int type. There is a potential infinite loop if num_parents is larger than the u8 loop counter. Fix this by making the loop counter the same type as num_parents. Also make num_parents an unsigned int to match the return type of the call to clk_hw_get_num_parents. Addresses-Coverity: ("Infinite loop") Fixes: 734d82f4a678 ("clk: uniphier: add core support code for UniPhier clock driver") Signed-off-by: Colin Ian King Reviewed-by: Masahiro Yamada Link: https://lore.kernel.org/r/20210409090104.629722-1-colin.king@canonical.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin

clk: socfpga: arria10: Fix memory leak of socfpga_clk on error return

2021-05-22T08:57:19+00:00

[ Upstream commit 657d4d1934f75a2d978c3cf2086495eaa542e7a9 ] There is an error return path that is not kfree'ing socfpga_clk leading to a memory leak. Fix this by adding in the missing kfree call. Addresses-Coverity: ("Resource leak") Signed-off-by: Colin Ian King Link: https://lore.kernel.org/r/20210406170115.430990-1-colin.king@canonical.com Acked-by: Dinh Nguyen Reviewed-by: Krzysztof Kozlowski Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin