summaryrefslogtreecommitdiff
path: root/drivers/clk
AgeCommit message (Collapse)AuthorFilesLines
9 daysclk: samsung: exynos-clkout: Assign .num before accessing .hwsNathan Chancellor1-1/+1
commit cf33f0b7df13685234ccea7be7bfe316b60db4db 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 (UBSAN_BOUNDS) 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 exynos_clkout_probe() due to .num being assigned after .hws[] has been accessed: UBSAN: array-index-out-of-bounds in drivers/clk/samsung/clk-exynos-clkout.c:178:18 index 0 is out of range for type 'clk_hw *[*]' Move the .num initialization to before the first access of .hws[], clearing up the warning. Cc: stable@vger.kernel.org Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") Reported-by: Jochen Sprickerhof <jochen@sprickerhof.de> Closes: https://lore.kernel.org/aSIYDN5eyKFKoXKL@eldamar.lan/ Tested-by: Jochen Sprickerhof <jochen@sprickerhof.de> Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: Kees Cook <kees@kernel.org> Reviewed-by: Sam Protsenko <semen.protsenko@linaro.org> Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
9 daysclk: mvebu: cp110 add CLK_IGNORE_UNUSED to pcie_x10, pcie_x11 & pcie_x4Josua Mayer1-0/+20
[ Upstream commit f0e6bc0c3ef4b4afb299bd6912586cafd5d864e9 ] CP110 based platforms rely on the bootloader for pci port initialization. TF-A actively prevents non-uboot re-configuration of pci lanes, and many boards do not have software control over the pci card reset. If a pci port had link at boot-time and the clock is stopped at a later point, the link fails and can not be recovered. PCI controller driver probe - and by extension ownership of a driver for the pci clocks - may be delayed especially on large modular kernels, causing the clock core to start disabling unused clocks. Add the CLK_IGNORE_UNUSED flag to the three pci port's clocks to ensure they are not stopped before the pci controller driver has taken ownership and tested for an existing link. This fixes failed pci link detection when controller driver probes late, e.g. with arm64 defconfig and CONFIG_PHY_MVEBU_CP110_COMPHY=m. Closes: https://lore.kernel.org/r/b71596c7-461b-44b6-89ab-3cfbd492639f@solid-run.com Signed-off-by: Josua Mayer <josua@solid-run.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
9 daysclk: keystone: fix compile testingJohan Hovold1-2/+1
[ Upstream commit b276445e98fe28609688fb85b89a81b803910e63 ] Some keystone clock drivers can be selected when COMPILE_TEST is enabled but since commit b745c0794e2f ("clk: keystone: Add sci-clk driver support") they are never actually built. Enable compile testing by allowing the build system to process the keystone drivers. Fixes: b745c0794e2f ("clk: keystone: Add sci-clk driver support") Signed-off-by: Johan Hovold <johan@kernel.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
9 daysclk: renesas: r9a06g032: Fix memory leak in error pathHaotian Zhang1-3/+3
[ Upstream commit f8def051bbcf8677f64701e9699bf6d11e2780cd ] The current code uses of_iomap() to map registers but never calls iounmap() on any error path after the mapping. This causes a memory leak when probe fails after successful ioremap, for example when of_clk_add_provider() or r9a06g032_add_clk_domain() fails. Replace of_iomap() with devm_of_iomap() to automatically unmap the region on probe failure. Update the error check accordingly to use IS_ERR() and PTR_ERR() since devm_of_iomap() returns ERR_PTR on error. Fixes: 4c3d88526eba ("clk: renesas: Renesas R9A06G032 clock driver") Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20251030061603.1954-1-vulab@iscas.ac.cn Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
9 daysclk: qcom: camcc-sm6350: Fix PLL config of PLL2Luca Weiss1-5/+1
[ Upstream commit ab0e13141d679fdffdd3463a272c5c1b10be1794 ] The 'Agera' PLLs (with clk_agera_pll_configure) do not take some of the parameters that are provided in the vendor driver. Instead the upstream configuration should provide the final user_ctl value that is written to the USER_CTL register. Fix the config so that the PLL is configured correctly, and fixes CAMCC_MCLK* being stuck off. Fixes: 80f5451d9a7c ("clk: qcom: Add camera clock controller driver for SM6350") Suggested-by: Taniya Das <taniya.das@oss.qualcomm.com> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Abel Vesa <abel.vesa@linaro.org> Reviewed-by: Taniya Das <taniya.das@oss.qualcomm.com> Link: https://lore.kernel.org/r/20251021-agera-pll-fixups-v1-1-8c1d8aff4afc@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
9 daysclk: qcom: camcc-sm6350: Specify Titan GDSC power domain as a parent to otherVladimir Zapolskiy1-0/+7
[ Upstream commit a76ce61d7225934b0a52c8172a8cd944002a8c6f ] When a consumer turns on/off a power domain dependent on another power domain in hardware, the parent power domain shall be turned on/off by the power domain provider as well, and to get it the power domain hardware hierarchy shall be described in the CAMCC driver. Establish the power domain hierarchy with a Titan GDSC set as a parent of all other GDSC power domains provided by the SM6350 camera clock controller to enforce a correct sequence of enabling and disabling power domains by the consumers, this fixes the CAMCC as a supplier of power domains to CAMSS IP and its driver. Fixes: 80f5451d9a7c ("clk: qcom: Add camera clock controller driver for SM6350") Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Reviewed-by: Imran Shaik <imran.shaik@oss.qualcomm.com> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> Link: https://lore.kernel.org/r/20251021234450.2271279-3-vladimir.zapolskiy@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
9 daysclk: renesas: cpg-mssr: Read back reset registers to assure values latchedMarek Vasut1-25/+21
[ Upstream commit b91401af6c00ffab003698bfabd4c166df30748b ] On R-Car V4H, the PCIEC controller DBI read would generate an SError in case the controller reset is released by writing SRSTCLR register first, and immediately afterward reading some PCIEC controller DBI register. The issue triggers in rcar_gen4_pcie_additional_common_init() on dw_pcie_readl_dbi(dw, PCIE_PORT_LANE_SKEW), which on V4H is the first read after reset_control_deassert(dw->core_rsts[DW_PCIE_PWR_RST].rstc). The reset controller which contains the SRSTCLR register and the PCIEC controller which contains the DBI register share the same root access bus, but the bus then splits into separate segments before reaching each IP. Even if the SRSTCLR write access was posted on the bus before the DBI read access, it seems the DBI read access may reach the PCIEC controller before the SRSTCLR write completed, and trigger the SError. Mitigate the issue by adding a dummy SRSTCLR read, which assures the SRSTCLR write completes fully and is latched into the reset controller, before the PCIEC DBI read access can occur. Fixes: 0ab55cf18341 ("clk: renesas: cpg-mssr: Add support for R-Car V4H") Reviewed-by: Wolfram Sang <wsa+renesas@sang-engineering.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20250922162113.113223-1-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
9 daysclk: renesas: Pass sub struct of cpg_mssr_priv to cpg_clk_registerThierry Bultel10-71/+88
[ Upstream commit 3d37ca1482c36975255f29911a529f84f1bc34a9 ] In a subsequent patch, the registration callback will need more parameters from cpg_mssr_priv (like another base address with clock controllers with double register block, and also, notifiers and rmw_lock). Instead of adding more parameters, move the needed parameters to a public sub-struct. Instead moving clks to this structure, which would have implied to add an allocation (and cleanup) for it, keep the way the allocation is done and just have a copy of the pointer in the public structure. Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Thierry Bultel <thierry.bultel.yh@bp.renesas.com> Link: https://lore.kernel.org/20250515141828.43444-5-thierry.bultel.yh@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Stable-dep-of: b91401af6c00 ("clk: renesas: cpg-mssr: Read back reset registers to assure values latched") Signed-off-by: Sasha Levin <sashal@kernel.org>
9 daysclk: renesas: Use str_on_off() helperGeert Uytterhoeven2-2/+4
[ Upstream commit aff664cc8cbc5c28e5aa57dc4201c34497f3c871 ] Use the str_on_off() helper instead of open-coding the same operation. Note that this does change the case of the flags, which doesn't matter much for debug messages. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/622f8554dcb815c8fc73511a1a118c1724570fa9.1745840497.git.geert+renesas@glider.be Stable-dep-of: b91401af6c00 ("clk: renesas: cpg-mssr: Read back reset registers to assure values latched") Signed-off-by: Sasha Levin <sashal@kernel.org>
9 daysclk: renesas: rzg2l: Use %x format specifier to print CLK_ON_R()Claudiu Beznea1-1/+1
[ Upstream commit fd627207aaa782c1fd4224076b56a03a1059f516 ] Use the %x format specifier to print CLK_ON_R(). This makes debugging easier as the value printed will be hexadecimal like in the hardware manual. Along with it add "0x" in front of the printed value. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20231010132701.1658737-2-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Stable-dep-of: b91401af6c00 ("clk: renesas: cpg-mssr: Read back reset registers to assure values latched") Signed-off-by: Sasha Levin <sashal@kernel.org>
9 daysclk: renesas: rzg2l: Remove critical areaClaudiu Beznea1-4/+1
[ Upstream commit 5f710e3bc5987373737470f98798bbd49134a2e0 ] The spinlock in rzg2l_mod_clock_endisable() is intended to protect RMW-accesses to the hardware register. There is no need to protect instructions that set temporary variables which will be written afterwards to a hardware register. With this only one write to one clock register is executed thus locking/unlocking rmw_lock is removed. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230929053915.1530607-7-claudiu.beznea@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Stable-dep-of: b91401af6c00 ("clk: renesas: cpg-mssr: Read back reset registers to assure values latched") Signed-off-by: Sasha Levin <sashal@kernel.org>
9 daysclk: renesas: rzg2l: Simplify the logic in rzg2l_mod_clock_endisable()Claudiu Beznea1-3/+2
[ Upstream commit becf4a771a12b52dc5b3d2b089598d5603f3bbec ] The bitmask << 16 is anyway set on both branches of if thus move it before the if and set the lower bits of registers only in case clock is enabled. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230912045157.177966-12-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Stable-dep-of: b91401af6c00 ("clk: renesas: cpg-mssr: Read back reset registers to assure values latched") Signed-off-by: Sasha Levin <sashal@kernel.org>
9 daysclk: renesas: cpg-mssr: Add missing 1ms delay into reset toggle callbackMarek Vasut1-2/+9
[ Upstream commit 62abfd7bedc2b3d86d4209a4146f9d2b5ae21fab ] R-Car V4H Reference Manual R19UH0186EJ0130 Rev.1.30 Apr. 21, 2025 page 583 Figure 9.3.1(a) Software Reset flow (A) as well as flow (B) / (C) indicate after reset has been asserted by writing a matching reset bit into register SRCR, it is mandatory to wait 1ms. This 1ms delay is documented on R-Car V4H and V4M, it is currently unclear whether S4 is affected as well. This patch does apply the extra delay on R-Car S4 as well. Fix the reset driver to respect the additional delay when toggling resets. Drivers which use separate reset_control_(de)assert() must assure matching delay in their driver code. Fixes: 0ab55cf18341 ("clk: renesas: cpg-mssr: Add support for R-Car V4H") Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://patch.msgid.link/20250918030552.331389-1-marek.vasut+renesas@mailbox.org Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-11-24clk: ti: am33xx: keep WKUP_DEBUGSS_CLKCTRL enabledMatthias Schiffer1-0/+2
[ Upstream commit 1e0d75258bd09323cb452655549e03975992b29e ] As described in AM335x Errata Advisory 1.0.42, WKUP_DEBUGSS_CLKCTRL can't be disabled - the clock module will just be stuck in transitioning state forever, resulting in the following warning message after the wait loop times out: l3-aon-clkctrl:0000:0: failed to disable Just add the clock to enable_init_clks, so no attempt is made to disable it. Signed-off-by: Matthias Schiffer <matthias.schiffer@tq-group.com> Signed-off-by: Alexander Stein <alexander.stein@ew.tq-group.com> Acked-by: Kevin Hilman <khilman@baylibre.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-11-24clk: at91: clk-sam9x60-pll: force write to PLL_UPDT registerNicolas Ferre1-36/+39
[ Upstream commit af98caeaa7b6ad11eb7b7c8bfaddc769df2889f3 ] This register is important for sequencing the commands to PLLs, so actually write the update bits with regmap_write_bits() instead of relying on a read/modify/write regmap command that could skip the actual hardware write if the value is identical to the one read. It's changed when modification is needed to the PLL, when read-only operation is done, we could keep the call to regmap_update_bits(). Add a comment to the sam9x60_div_pll_set_div() function that uses this PLL_UPDT register so that it's used consistently, according to the product's datasheet. Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Tested-by: Ryan Wanner <ryan.wanner@microchip.com> # on sama7d65 and sam9x75 Link: https://lore.kernel.org/r/20250827150811.82496-1-nicolas.ferre@microchip.com [claudiu.beznea: fix "Alignment should match open parenthesis" checkpatch.pl check] Signed-off-by: Claudiu Beznea <claudiu.beznea@tuxon.dev> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-11-24clk: at91: clk-master: Add check for divide by 3Ryan Wanner1-0/+3
[ Upstream commit e0237f5635727d64635ec6665e1de9f4cacce35c ] A potential divider for the master clock is div/3. The register configuration for div/3 is MASTER_PRES_MAX. The current bit shifting method does not work for this case. Checking for MASTER_PRES_MAX will ensure the correct decimal value is stored in the system. Signed-off-by: Ryan Wanner <Ryan.Wanner@microchip.com> Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-11-24clk: sunxi-ng: sun6i-rtc: Add A523 specificsChen-Yu Tsai1-0/+11
[ Upstream commit 7aa8781f379c32c31bd78f1408a31765b2297c43 ] The A523's RTC block is backward compatible with the R329's, but it also has a calibration function for its internal oscillator, which would allow it to provide a clock rate closer to the desired 32.768 KHz. This is useful on the Radxa Cubie A5E, which does not have an external 32.768 KHz crystal. Add new compatible-specific data for it. Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Link: https://patch.msgid.link/20250909170947.2221611-1-wens@kernel.org Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-19clk: tegra: do not overallocate memory for bpmp clocksFedor Pchelkin1-1/+1
[ Upstream commit 49ef6491106209c595476fc122c3922dfd03253f ] struct tegra_bpmp::clocks is a pointer to a dynamically allocated array of pointers to 'struct tegra_bpmp_clk'. But the size of the allocated area is calculated like it is an array containing actual 'struct tegra_bpmp_clk' objects - it's not true, there are just pointers. Found by Linux Verification Center (linuxtesting.org) with Svace static analysis tool. Fixes: 2db12b15c6f3 ("clk: tegra: Register clocks from root to leaf") Signed-off-by: Fedor Pchelkin <pchelkin@ispras.ru> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-19clk: nxp: Fix pll0 rate check condition in LPC18xx CGU driverAlok Tiwari1-2/+2
[ Upstream commit 1624dead9a4d288a594fdf19735ebfe4bb567cb8 ] The conditional check for the PLL0 multiplier 'm' used a logical AND instead of OR, making the range check ineffective. This patch replaces && with || to correctly reject invalid values of 'm' that are either less than or equal to 0 or greater than LPC18XX_PLL0_MSEL_MAX. This ensures proper bounds checking during clk rate setting and rounding. Fixes: b04e0b8fd544 ("clk: add lpc18xx cgu clk driver") Signed-off-by: Alok Tiwari <alok.a.tiwari@oracle.com> [sboyd@kernel.org: 'm' is unsigned so remove < condition] Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-19clk: nxp: lpc18xx-cgu: convert from round_rate() to determine_rate()Brian Masney1-7/+9
[ Upstream commit b46a3d323a5b7942e65025254c13801d0f475f02 ] The round_rate() clk ops is deprecated, so migrate this driver from round_rate() to determine_rate() using the Coccinelle semantic patch on the cover letter of this series. Signed-off-by: Brian Masney <bmasney@redhat.com> Stable-dep-of: 1624dead9a4d ("clk: nxp: Fix pll0 rate check condition in LPC18xx CGU driver") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-19clk: mediatek: clk-mux: Do not pass flags to clk_mux_determine_rate_flags()Chen-Yu Tsai1-3/+1
[ Upstream commit 5e121370a7ad3414c7f3a77002e2b18abe5c6fe1 ] The `flags` in |struct mtk_mux| are core clk flags, not mux clk flags. Passing one to the other is wrong. Since there aren't any actual users adding CLK_MUX_* flags, just drop it for now. Fixes: b05ea3314390 ("clk: mediatek: clk-mux: Add .determine_rate() callback") Signed-off-by: Chen-Yu Tsai <wenst@chromium.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-19clk: mediatek: mt8195-infra_ao: Fix parent for infra_ao_hdmi_26mAngeloGioacchino Del Regno1-1/+1
[ Upstream commit 6c4c26b624790098988c1034541087e3e5ed5bed ] The infrastructure gate for the HDMI specific crystal needs the top_hdmi_xtal clock to be configured in order to ungate the 26m clock to the HDMI IP, and it wouldn't work without. Reparent the infra_ao_hdmi_26m clock to top_hdmi_xtal to fix that. Fixes: e2edf59dec0b ("clk: mediatek: Add MT8195 infrastructure clock support") Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-10-19clk: at91: peripheral: fix return valueBrian Masney1-2/+5
[ Upstream commit 47b13635dabc14f1c2fdcaa5468b47ddadbdd1b5 ] determine_rate() is expected to return an error code, or 0 on success. clk_sam9x5_peripheral_determine_rate() has a branch that returns the parent rate on a certain case. This is the behavior of round_rate(), so let's go ahead and fix this by setting req->rate. Fixes: b4c115c76184f ("clk: at91: clk-peripheral: add support for changeable parent rate") Reviewed-by: Alexander Sverdlin <alexander.sverdlin@gmail.com> Acked-by: Nicolas Ferre <nicolas.ferre@microchip.com> Signed-off-by: Brian Masney <bmasney@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-28clk: qcom: ipq5018: keep XO clock always onGeorge Moussalem1-1/+1
[ Upstream commit 693a723291d0634eaea24cff2f9d807f3223f204 ] The XO clock must not be disabled to avoid the kernel trying to disable the it. As such, keep the XO clock always on by flagging it as critical. Signed-off-by: George Moussalem <george.moussalem@outlook.com> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com> Link: https://lore.kernel.org/r/20250516-ipq5018-cmn-pll-v4-1-389a6b30e504@outlook.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-28clk: tegra: periph: Fix error handling and resolve unsigned compare warningPei Xiao1-2/+2
[ Upstream commit 2dc2ca9000eea2eb749f658196204cb84d4306f7 ] ./drivers/clk/tegra/clk-periph.c:59:5-9: WARNING: Unsigned expression compared with zero: rate < 0 The unsigned long 'rate' variable caused: - Incorrect handling of negative errors - Compile warning: "Unsigned expression compared with zero" Fix by changing to long type and adding req->rate cast. Signed-off-by: Pei Xiao <xiaopei01@kylinos.cn> Link: https://lore.kernel.org/r/79c7f01e29876c612e90d6d0157fb1572ca8b3fb.1752046270.git.xiaopei01@kylinos.cn Acked-by: Thierry Reding <treding@nvidia.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15clk: sunxi-ng: v3s: Fix de clock definitionPaul Kocialkowski1-2/+1
[ Upstream commit e8ab346f9907a1a3aa2f0e5decf849925c06ae2e ] The de clock is marked with CLK_SET_RATE_PARENT, which is really not necessary (as confirmed from experimentation) and significantly restricts flexibility for other clocks using the same parent. In addition the source selection (parent) field is marked as using 2 bits, when it the documentation reports that it uses 3. Fix both issues in the de clock definition. Fixes: d0f11d14b0bc ("clk: sunxi-ng: add support for V3s CCU") Signed-off-by: Paul Kocialkowski <paulk@sys-base.io> Link: https://patch.msgid.link/20250704154008.3463257-1-paulk@sys-base.io Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15clk: clk-axi-clkgen: fix fpfd_max frequency for zynqNuno Sá1-1/+1
[ Upstream commit ce8a9096699500e2c5bca09dde27b16edda5f636 ] The fpfd_max frequency should be set to 450 MHz instead of 300 MHz. Well, it actually depends on the platform speed grade but we are being conservative for ultrascale so let's be consistent. In a following change we will set these limits at runtime. Fixes: 0e646c52cf0e ("clk: Add axi-clkgen driver") Signed-off-by: Nuno Sá <nuno.sa@analog.com> Link: https://lore.kernel.org/r/20250519-dev-axi-clkgen-limits-v6-1-bc4b3b61d1d4@analog.com Reviewed-by: David Lechner <dlechner@baylibre.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15clk: xilinx: vcu: unregister pll_post only if registered correctlyRohit Visavalia1-2/+2
[ Upstream commit 3b0abc443ac22f7d4f61ddbbbbc5dbb06c87139d ] If registration of pll_post is failed, it will be set to NULL or ERR, unregistering same will fail with following call trace: Unable to handle kernel NULL pointer dereference at virtual address 008 pc : clk_hw_unregister+0xc/0x20 lr : clk_hw_unregister_fixed_factor+0x18/0x30 sp : ffff800011923850 ... Call trace: clk_hw_unregister+0xc/0x20 clk_hw_unregister_fixed_factor+0x18/0x30 xvcu_unregister_clock_provider+0xcc/0xf4 [xlnx_vcu] xvcu_probe+0x2bc/0x53c [xlnx_vcu] Fixes: 4472e1849db7 ("soc: xilinx: vcu: make pll post divider explicit") Signed-off-by: Rohit Visavalia <rohit.visavalia@amd.com> Link: https://lore.kernel.org/r/20250210113614.4149050-2-rohit.visavalia@amd.com Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-08-15clk: davinci: Add NULL check in davinci_lpsc_clk_register()Henry Martin1-0/+5
[ Upstream commit 13de464f445d42738fe18c9a28bab056ba3a290a ] devm_kasprintf() returns NULL when memory allocation fails. Currently, davinci_lpsc_clk_register() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue and ensuring no resources are left allocated. Fixes: c6ed4d734bc7 ("clk: davinci: New driver for davinci PSC clocks") Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com> Link: https://lore.kernel.org/r/20250401131341.26800-1-bsdhenrymartin@gmail.com Reviewed-by: David Lechner <david@lechnology.com> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27clk: rockchip: rk3036: mark ddrphy as criticalHeiko Stuebner1-0/+1
[ Upstream commit 596a977b34a722c00245801a5774aa79cec4e81d ] The ddrphy is supplied by the dpll, but due to the limited number of PLLs on the rk3036, the dpll also is used for other periperhals, like the GPU. So it happened, when the Lima driver turned off the gpu clock, this in turn also disabled the dpll and thus the ram. Signed-off-by: Heiko Stuebner <heiko@sntech.de> Link: https://lore.kernel.org/r/20250503202532.992033-4-heiko@sntech.de Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-27clk: meson-g12a: add missing fclk_div2 to spiccDa Xue1-0/+1
commit daf004f87c3520c414992893e2eadd5db5f86a5a upstream. SPICC is missing fclk_div2, which means fclk_div5 and fclk_div7 indexes are wrong on this clock. This causes the spicc module to output sclk at 2.5x the expected rate when clock index 3 is picked. Adding the missing fclk_div2 resolves this. [jbrunet: amended commit description] Fixes: a18c8e0b7697 ("clk: meson: g12a: add support for the SPICC SCLK Source clocks") Cc: stable@vger.kernel.org # 6.1 Signed-off-by: Da Xue <da@libre.computer> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> Link: https://lore.kernel.org/r/20250512142617.2175291-1-da@libre.computer Signed-off-by: Jerome Brunet <jbrunet@baylibre.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-19clk: qcom: gcc-msm8939: Fix mclk0 & mclk1 for 24 MHzVincent Knecht1-2/+2
[ Upstream commit 9e7acf70cf6aa7b22f67d911f50a8cd510e8fb00 ] Fix mclk0 & mclk1 parent map to use correct GPLL6 configuration and freq_tbl to use GPLL6 instead of GPLL0 so that they tick at 24 MHz. Fixes: 1664014e4679 ("clk: qcom: gcc-msm8939: Add MSM8939 Generic Clock Controller") Suggested-by: Stephan Gerhold <stephan@gerhold.net> Reviewed-by: Konrad Dybcio <konrad.dybcio@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Signed-off-by: Vincent Knecht <vincent.knecht@mailoo.org> Link: https://lore.kernel.org/r/20250414-gcc-msm8939-fixes-mclk-v2-resend2-v2-1-5ddcf572a6de@mailoo.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19clk: bcm: rpi: Add NULL check in raspberrypi_clk_register()Henry Martin1-0/+2
[ Upstream commit 73c46d9a93d071ca69858dea3f569111b03e549e ] devm_kasprintf() returns NULL when memory allocation fails. Currently, raspberrypi_clk_register() does not check for this case, which results in a NULL pointer dereference. Add NULL check after devm_kasprintf() to prevent this issue. Fixes: 93d2725affd6 ("clk: bcm: rpi: Discover the firmware clocks") Signed-off-by: Henry Martin <bsdhenrymartin@gmail.com> Reviewed-by: Dave Stevenson <dave.stevenson@raspberrypi.com> Link: https://lore.kernel.org/r/20250402020513.42628-1-bsdhenrymartin@gmail.com Reviewed-by: Stefan Wahren <wahrenst@gmx.net> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19clk: qcom: gpucc-sm6350: Add *_wait_val values for GDSCsLuca Weiss1-0/+6
[ Upstream commit d988b0b866c2aeb23aa74022b5bbd463165a7a33 ] Compared to the msm-4.19 driver the mainline GDSC driver always sets the bits for en_rest, en_few & clk_dis, and if those values are not set per-GDSC in the respective driver then the default value from the GDSC driver is used. The downstream driver only conditionally sets clk_dis_wait_val if qcom,clk-dis-wait-val is given in devicetree. Correct this situation by explicitly setting those values. For all GDSCs the reset value of those bits are used, with the exception of gpu_cx_gdsc which has an explicit value (qcom,clk-dis-wait-val = <8>). Fixes: 013804a727a0 ("clk: qcom: Add GPU clock controller driver for SM6350") Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Taniya Das <quic_tdas@quicinc.com> Link: https://lore.kernel.org/r/20250425-sm6350-gdsc-val-v1-4-1f252d9c5e4e@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19clk: qcom: gcc-sm6350: Add *_wait_val values for GDSCsLuca Weiss1-0/+6
[ Upstream commit afdfd829a99e467869e3ca1955fb6c6e337c340a ] Compared to the msm-4.19 driver the mainline GDSC driver always sets the bits for en_rest, en_few & clk_dis, and if those values are not set per-GDSC in the respective driver then the default value from the GDSC driver is used. The downstream driver only conditionally sets clk_dis_wait_val if qcom,clk-dis-wait-val is given in devicetree. Correct this situation by explicitly setting those values. For all GDSCs the reset value of those bits are used. Fixes: 131abae905df ("clk: qcom: Add SM6350 GCC driver") Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Taniya Das <quic_tdas@quicinc.com> Link: https://lore.kernel.org/r/20250425-sm6350-gdsc-val-v1-3-1f252d9c5e4e@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19clk: qcom: dispcc-sm6350: Add *_wait_val values for GDSCsLuca Weiss1-0/+3
[ Upstream commit 673989d27123618afab56df1143a75454178b4ae ] Compared to the msm-4.19 driver the mainline GDSC driver always sets the bits for en_rest, en_few & clk_dis, and if those values are not set per-GDSC in the respective driver then the default value from the GDSC driver is used. The downstream driver only conditionally sets clk_dis_wait_val if qcom,clk-dis-wait-val is given in devicetree. Correct this situation by explicitly setting those values. For all GDSCs the reset value of those bits are used. Fixes: 837519775f1d ("clk: qcom: Add display clock controller driver for SM6350") Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Taniya Das <quic_tdas@quicinc.com> Link: https://lore.kernel.org/r/20250425-sm6350-gdsc-val-v1-2-1f252d9c5e4e@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-19clk: qcom: camcc-sm6350: Add *_wait_val values for GDSCsLuca Weiss1-0/+18
[ Upstream commit e7b1c13280ad866f3b935f6c658713c41db61635 ] Compared to the msm-4.19 driver the mainline GDSC driver always sets the bits for en_rest, en_few & clk_dis, and if those values are not set per-GDSC in the respective driver then the default value from the GDSC driver is used. The downstream driver only conditionally sets clk_dis_wait_val if qcom,clk-dis-wait-val is given in devicetree. Correct this situation by explicitly setting those values. For all GDSCs the reset value of those bits are used. Fixes: 80f5451d9a7c ("clk: qcom: Add camera clock controller driver for SM6350") Signed-off-by: Luca Weiss <luca.weiss@fairphone.com> Reviewed-by: Taniya Das <quic_tdas@quicinc.com> Link: https://lore.kernel.org/r/20250425-sm6350-gdsc-val-v1-1-1f252d9c5e4e@fairphone.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-04clk: s2mps11: initialise clk_hw_onecell_data::num before accessing ::hws[] ↵André Draszik1-1/+2
in probe() commit 3e14c7207a975eefcda1929b2134a9f4119dde45 upstream. With UBSAN enabled, we're getting the following trace: UBSAN: array-index-out-of-bounds in .../drivers/clk/clk-s2mps11.c:186:3 index 0 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]') This is because commit f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") annotated the hws member of that struct 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 initialised with the number of elements before the first array access happens, otherwise there will be a warning from each access prior to the initialisation because the number of elements is zero. This occurs in s2mps11_clk_probe() due to ::num being assigned after ::hws access. Move the assignment to satisfy the requirement of assign-before-access. Cc: stable@vger.kernel.org Fixes: f316cdff8d67 ("clk: Annotate struct clk_hw_onecell_data with __counted_by") Signed-off-by: André Draszik <andre.draszik@linaro.org> Link: https://lore.kernel.org/r/20250326-s2mps11-ubsan-v1-1-fcc6fce5c8a9@linaro.org Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Signed-off-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2025-06-04clk: sunxi-ng: d1: Add missing divider for MMC mod clocksAndre Przywara2-19/+47
[ Upstream commit 98e6da673cc6dd46ca9a599802bd2c8f83606710 ] The D1/R528/T113 SoCs have a hidden divider of 2 in the MMC mod clocks, just as other recent SoCs. So far we did not describe that, which led to the resulting MMC clock rate to be only half of its intended value. Use a macro that allows to describe a fixed post-divider, to compensate for that divisor. This brings the MMC performance on those SoCs to its expected level, so about 23 MB/s for SD cards, instead of the 11 MB/s measured so far. Fixes: 35b97bb94111 ("clk: sunxi-ng: Add support for the D1 SoC clocks") Reported-by: Kuba Szczodrzyński <kuba@szczodrzynski.pl> Signed-off-by: Andre Przywara <andre.przywara@arm.com> Link: https://patch.msgid.link/20250501120631.837186-1-andre.przywara@arm.com Signed-off-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-04clk: qcom: camcc-sm8250: Use clk_rcg2_shared_ops for some RCGsJordan Crouse1-28/+28
[ Upstream commit 52b10b591f83dc6d9a1d6c2dc89433470a787ecd ] Update some RCGs on the sm8250 camera clock controller to use clk_rcg2_shared_ops. The shared_ops ensure the RCGs get parked to the XO during clock disable to prevent the clocks from locking up when the GDSC is enabled. These mirror similar fixes for other controllers such as commit e5c359f70e4b ("clk: qcom: camcc: Update the clock ops for the SC7180"). Signed-off-by: Jordan Crouse <jorcrous@amazon.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org> Link: https://lore.kernel.org/r/20250122222612.32351-1-jorcrous@amazon.com Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-04clk: qcom: clk-alpha-pll: Do not use random stack value for recalc rateKrzysztof Kozlowski1-16/+36
[ Upstream commit 7a243e1b814a02ab40793026ef64223155d86395 ] If regmap_read() fails, random stack value was used in calculating new frequency in recalc_rate() callbacks. Such failure is really not expected as these are all MMIO reads, however code should be here correct and bail out. This also avoids possible warning on uninitialized value. Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org> Link: https://lore.kernel.org/r/20250212-b4-clk-qcom-clean-v3-1-499f37444f5d@linaro.org Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-04clk: qcom: ipq5018: allow it to be bulid on arm32Karl Chan1-1/+1
[ Upstream commit 5d02941c83997b58e8fc15390290c7c6975acaff ] There are some ipq5018 based device's firmware only can able to boot arm32 but the clock driver dont allow it to be compiled on arm32. Therefore allow GCC for IPQ5018 to be selected when building ARM32 kernel Signed-off-by: Karl Chan <exxxxkc@getgoogleoff.me> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Link: https://lore.kernel.org/r/20241007163414.32458-4-exxxxkc@getgoogleoff.me [bjorn: Updated commit message, per Dmitry's suggestion] Signed-off-by: Bjorn Andersson <andersson@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-06-04clk: imx8mp: inform CCF of maximum frequency of clocksAhmad Fatoum1-0/+151
[ Upstream commit 06a61b5cb6a8638fa8823cd09b17233b29696fa2 ] The IMX8MPCEC datasheet lists maximum frequencies allowed for different modules. Some of these limits are universal, but some depend on whether the SoC is operating in nominal or in overdrive mode. The imx8mp.dtsi currently assumes overdrive mode and configures some clocks in accordance with this. Boards wishing to make use of nominal mode will need to override some of the clock rates manually. As operating the clocks outside of their allowed range can lead to difficult to debug issues, it makes sense to register the maximum rates allowed in the driver, so the CCF can take them into account. Reviewed-by: Peng Fan <peng.fan@nxp.com> Signed-off-by: Ahmad Fatoum <a.fatoum@pengutronix.de> Link: https://lore.kernel.org/r/20250218-imx8m-clk-v4-6-b7697dc2dcd0@pengutronix.de Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-02clk: check for disabled clock-provider in of_clk_get_hw_from_clkspec()Heiko Stuebner1-0/+4
[ 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>
2025-05-02clk: renesas: r9a07g043: Fix HP clock source for RZ/FiveLad Prabhakar1-0/+7
[ Upstream commit 7f22a298d926664b51fcfe2f8ea5feb7f8b79952 ] According to the Rev.1.20 hardware manual for the RZ/Five SoC, the clock source for HP is derived from PLL6 divided by 2. Correct the implementation by configuring HP as a fixed clock source instead of a MUX. The `CPG_PL6_ETH_SSEL' register, which is available on the RZ/G2UL SoC, is not present on the RZ/Five SoC, necessitating this change. Fixes: 95d48d270305ad2c ("clk: renesas: r9a07g043: Add support for RZ/Five SoC") Cc: stable@vger.kernel.org Reported-by: Hien Huynh <hien.huynh.px@renesas.com> Signed-off-by: Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/20250127173159.34572-1-prabhakar.mahadev-lad.rj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-02clk: renesas: r9a07g04[34]: Fix typo for sel_shdi variableClaudiu Beznea2-6/+6
[ Upstream commit 46fb5dd9ca289953fa791b2bb060dac7f8002ae0 ] Fix typo for sel_shdi variable. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20240131102930.1841901-3-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Stable-dep-of: 7f22a298d926 ("clk: renesas: r9a07g043: Fix HP clock source for RZ/Five") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-02clk: renesas: r9a07g04[34]: Use SEL_SDHI1_STS status configuration for SD1 muxClaudiu Beznea2-2/+2
[ Upstream commit 9b2a11c83859c06233049b134bd8ee974b284559 ] The status configuration for SD1 mux clock is SEL_SDHI1_STS. Fix it. Fixes: 16b86e5c03c5 ("clk: renesas: rzg2l: Refactor SD mux driver") Reported-by: Hien Huynh <hien.huynh.px@renesas.com> Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20240131102930.1841901-2-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Stable-dep-of: 7f22a298d926 ("clk: renesas: r9a07g043: Fix HP clock source for RZ/Five") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-02clk: renesas: rzg2l: Refactor SD mux driverClaudiu Beznea4-51/+139
[ Upstream commit 16b86e5c03c5b3ef35bf5126b35384faa97428f0 ] Refactor SD MUX driver to be able to reuse the same code on RZ/G3S. RZ/G2{L,UL} has a limitation with regards to switching the clock source for SD MUX (MUX clock source has to be switched to 266MHz before switching b/w 533MHz and 400MHz). Rework the handling of this limitation to use a clock notifier that is registered according to platform based initialization data, so the SD MUX code can be reused on RZ/G3S. As RZ/G2{L,UL} and RZ/G3S use different bits in different registers to check if the clock switching has been done, this configuration (register offset, register bits and bitfield width) is now passed through struct cpg_core_clk::sconf (status configuration) from platform specific initialization code. Along with struct cpg_core_clk::sconf the mux table indices are also passed from platform specific initialization code. Also, mux flags are now passed to DEF_SD_MUX() as they will be used later by RZ/G3S. CPG_WEN_BIT macro has been introduced to select properly the WEN bit of various registers. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20231006103959.197485-3-claudiu.beznea.uj@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Stable-dep-of: 7f22a298d926 ("clk: renesas: r9a07g043: Fix HP clock source for RZ/Five") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-02clk: renesas: rzg2l: Remove CPG_SDHI_DSEL from generic headerClaudiu Beznea3-4/+14
[ Upstream commit 3e8008fcf6b7f7c65ad2718c18fb79f37007f1a5 ] Remove CPG_SDHI_DSEL and its bits from the generic header as RZ/G3S has different offset registers and bits for this, thus avoid mixing them. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230929053915.1530607-10-claudiu.beznea@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Stable-dep-of: 7f22a298d926 ("clk: renesas: r9a07g043: Fix HP clock source for RZ/Five") Signed-off-by: Sasha Levin <sashal@kernel.org>
2025-05-02clk: renesas: rzg2l: Add struct clk_hw_dataClaudiu Beznea1-18/+34
[ Upstream commit 97c1c4ccda76d2919775d748cf223637cf0e82ae ] Add clk_hw_data struct that keeps the core part of the clock data. sd_hw_data embeds a member of type struct clk_hw_data along with other members (in the next commits). This commit prepares the field for refactoring the SD MUX clock driver. Signed-off-by: Claudiu Beznea <claudiu.beznea.uj@bp.renesas.com> Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be> Link: https://lore.kernel.org/r/20230929053915.1530607-9-claudiu.beznea@bp.renesas.com Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Stable-dep-of: 7f22a298d926 ("clk: renesas: r9a07g043: Fix HP clock source for RZ/Five") Signed-off-by: Sasha Levin <sashal@kernel.org>
generated by cgit v1.2.3 (git 2.39.0) at 2026-01-20 23:42:08 +0300