[ Upstream commit e97fe4901e ]
It is possible for clk_core_get to dereference a NULL in the following
sequence:
clk_core_get()
of_clk_get_hw_from_clkspec()
__of_clk_get_hw_from_provider()
__clk_get_hw()
__clk_get_hw() can return NULL which is dereferenced by clk_core_get() at
hw->core.
Prior to commit dde4eff47c ("clk: Look for parents with clkdev based
clk_lookups") the check IS_ERR_OR_NULL() was performed which would have
caught the NULL.
Reading the description of this function it talks about returning NULL but
that cannot be so at the moment.
Update the function to check for hw before dereferencing it and return NULL
if hw is NULL.
Fixes: dde4eff47c ("clk: Look for parents with clkdev based clk_lookups")
Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Link: https://lore.kernel.org/r/20240302-linux-next-24-03-01-simple-clock-fixes-v1-1-25f348a5982b@linaro.org
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 11b752ac5a ]
The following table shows the values of the 'halt_reg' and the
'enable_reg' fields from the pcie clocks defined in the current
driver:
clock halt_reg enable_reg
gcc_pcie0_ahb_clk 0x75010 0x75010
gcc_pcie0_aux_clk 0x75014 0x75014
gcc_pcie0_axi_m_clk 0x75008 0x75008
gcc_pcie0_axi_s_bridge_clk 0x75048 0x75048
gcc_pcie0_axi_s_clk 0x7500c 0x7500c
gcc_pcie0_pipe_clk 0x75018 0x75018
gcc_pcie1_ahb_clk 0x76010 0x76010
gcc_pcie1_aux_clk 0x76014 0x76014
gcc_pcie1_axi_m_clk 0x76008 0x76008
gcc_pcie1_axi_s_bridge_clk 0x76048 0x76048
gcc_pcie1_axi_s_clk 0x7600c 0x7600c
gcc_pcie1_pipe_clk 8* 0x76018
Based on the table, it is quite likely that the pcie0 and the pci1
clocks are using the same register layout, however it seems that
the value of the 'halt_reg' field in the 'gcc_pcie1_pipe_clk' clock
is wrong.
In the downstream driver [1], the same '0x76018' value is used for
both the 'halt_reg' and for the 'enable_reg' fields of the
'gcc_pcie1_pipe_clk' clock.
Update the current driver to use the same value used downstream as
probably that is the correct value.
1. https://git.codelinaro.org/clo/qsdk/oss/kernel/linux-ipq-5.4/-/blob/NHSS.QSDK.12.4.r4/drivers/clk/qcom/gcc-ipq5018.c?ref_type=heads#L2316
Fixes: e3fdbef1ba ("clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
Link: https://lore.kernel.org/r/20240225-gcc-ipq5018-register-fixes-v1-2-3c191404d9f0@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit f982adcc1b ]
The value of the 'enable_reg' field in the 'gcc_gmac0_sys_clk'
clock definition seems wrong as it is greater than the
'max_register' value defined in the regmap configuration.
Additionally, all other gmac specific branch clock definitions
within the driver uses the same value both for the 'enable_reg'
and for the 'halt_reg' fields.
Due to the lack of documentation the correct value is not known.
Looking into the downstream driver does not help either, as that
uses the same (presumably wrong) value [1].
Nevertheless, change the 'enable_reg' field of 'gcc_gmac0_sys_clk'
to use the value from the 'halt_reg' field so it follows the pattern
used in other gmac clock definitions. The change is based on the
assumption that the register layout of this clock is the same
as the other gmac clocks.
1. https://git.codelinaro.org/clo/qsdk/oss/kernel/linux-ipq-5.4/-/blob/NHSS.QSDK.12.4.r4/drivers/clk/qcom/gcc-ipq5018.c?ref_type=heads#L1889
Fixes: e3fdbef1ba ("clk: qcom: Add Global Clock controller (GCC) driver for IPQ5018")
Signed-off-by: Gabor Juhos <j4g8y7@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Reviewed-by: Kathiravan Thirumoorthy <quic_kathirav@quicinc.com>
Link: https://lore.kernel.org/r/20240225-gcc-ipq5018-register-fixes-v1-1-3c191404d9f0@gmail.com
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit a65083fa66 ]
CLK_INFRA_SSPM_32K_SELF has the "f_f26m_ck" clock assigned as its parent.
This is inconsistent as the clock is part of a group that are all gates
without dividers, and this makes the kernel think it runs at 26 MHz.
After clarification from MediaTek engineers, the correct parent is
actually the system 32 KHz clock.
Fixes: 1eb8d61ac5 ("clk: mediatek: mt8183: Add back SSPM related clocks")
Signed-off-by: Chen-Yu Tsai <wenst@chromium.org>
Link: https://lore.kernel.org/r/20240219105125.956278-1-wenst@chromium.org
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 67c15187d4 ]
When SPI transfer is being prepared, the spi-s3c64xx driver will call
clk_set_rate() to change the rate of SPI source clock (IPCLK). But IPCLK
is a gate (leaf) clock, so it must propagate the rate change up the
clock tree, so that corresponding DIV clocks can actually change their
divider values. Add CLK_SET_RATE_PARENT flag to corresponding clocks for
all SPI instances in Exynos850 (spi_0, spi_1 and spi_2) to make it
possible. This change involves next clocks:
usi_spi_0:
Clock Block Div range
--------------------------------------------
gout_spi0_ipclk CMU_PERI -
dout_peri_spi0 CMU_PERI /1..32
mout_peri_spi_user CMU_PERI -
dout_peri_ip CMU_TOP /1..16
usi_cmgp0:
Clock Block Div range
--------------------------------------------
gout_cmgp_usi0_ipclk CMU_CMGP -
dout_cmgp_usi0 CMU_CMGP /1..32
mout_cmgp_usi0 CMU_CMGP -
gout_clkcmu_cmgp_bus CMU_APM -
dout_apm_bus CMU_APM /1..8
usi_cmgp1:
Clock Block Div range
--------------------------------------------
gout_cmgp_usi1_ipclk CMU_CMGP -
dout_cmgp_usi1 CMU_CMGP /1..32
mout_cmgp_usi1 CMU_CMGP -
gout_clkcmu_cmgp_bus CMU_APM -
dout_apm_bus CMU_APM /1..8
With input clock of 400 MHz, this scheme provides next IPCLK rate range,
for each SPI block:
SPI0: 781 kHz ... 400 MHz
SPI1/2: 1.6 MHz ... 400 MHz
Accounting for internal /4 divider in SPI blocks, and because the max
SPI frequency is limited at 50 MHz, it gives us next SPI SCK rates:
SPI0: 200 kHz ... 49.9 MHz
SPI1/2: 400 kHz ... 49.9 MHz
Which should cover all possible applications of SPI bus. Of course,
setting SPI frequency to values as low as 500 kHz will also affect the
common bus dividers (dout_apm_bus or dout_peri_ip), which in turn
effectively lowers the rates for all leaf bus clocks derived from those
dividers, like HSI2C and I3C clocks. But at least it gives the board
designer a choice, whether to keep all clocks (SPI/HSI2C/I3C) at high
frequencies, or make all those clocks have lower frequencies. Not
propagating the rate change to those common dividers would limit this
choice to "only high frequencies are allowed for SPI/HSI2C/I3C" option,
making the common dividers useless. This decision follows the "Worse is
better" approach, relying on the users/engineers to know the system
internals when working with such low-level features, instead of trying
to account for all possible use-cases.
Fixes: 7dd0557819 ("clk: samsung: Introduce Exynos850 clock driver")
Signed-off-by: Sam Protsenko <semen.protsenko@linaro.org>
Reviewed-by: Tudor Ambarus <tudor.ambarus@linaro.org>
Link: https://lore.kernel.org/r/20240125013858.3986-2-semen.protsenko@linaro.org
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7e77a39265 ]
The PCIe GDSCs can be shared with other masters and should use the APCS
collapse-vote register when updating the power state.
This is specifically also needed to be able to disable power domains
that have been enabled by boot firmware using the vote register.
Following other recent Qualcomm platforms, describe this register and
the corresponding mask for the PCIe (and _phy) GDSCs.
Fixes: 955f2ea3b9 ("clk: qcom: Add GCC driver for SM8550")
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Link: https://lore.kernel.org/r/20231218-topic-8550_fixes-v1-5-ce1272d77540@linaro.org
Signed-off-by: Bjorn Andersson <andersson@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 1fe15be1fb ]
Currently zynqmp divider round rate is considering single parent and
calculating rate and parent rate accordingly. But if divider clock flag
is set to SET_RATE_PARENT then its not trying to traverse through all
parent rate and not selecting best parent rate from that. So use common
divider_round_rate() which is traversing through all clock parents and
its rate and calculating proper parent rate.
Fixes: 3fde0e16d0 ("drivers: clk: Add ZynqMP clock driver")
Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Link: https://lore.kernel.org/r/20231129112916.23125-3-jay.buddhabhatti@amd.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit b782921ddd ]
Currently zynqmp clock driver is not calculating closest mux rate and
because of that Linux is not setting proper frequency for CPU and
not able to set given frequency for dynamic frequency scaling.
E.g., In current logic initial acpu clock parent and frequency as below
apll1 0 0 0 2199999978 0 0 50000 Y
acpu0_mux 0 0 0 2199999978 0 0 50000 Y
acpu0_idiv1 0 0 0 2199999978 0 0 50000 Y
acpu0 0 0 0 2199999978 0 0 50000 Y
After changing acpu frequency to 549999994 Hz using CPU freq scaling its
selecting incorrect parent which is not closest frequency.
rpll_to_xpd 0 0 0 1599999984 0 0 50000 Y
acpu0_mux 0 0 0 1599999984 0 0 50000 Y
acpu0_div1 0 0 0 533333328 0 0 50000 Y
acpu0 0 0 0 533333328 0 0 50000 Y
Parent should remain same since 549999994 = 2199999978 / 4.
So use __clk_mux_determine_rate_closest() generic function to calculate
closest rate for mux clock. After this change its selecting correct
parent and correct clock rate.
apll1 0 0 0 2199999978 0 0 50000 Y
acpu0_mux 0 0 0 2199999978 0 0 50000 Y
acpu0_div1 0 0 0 549999995 0 0 50000 Y
acpu0 0 0 0 549999995 0 0 50000 Y
Fixes: 3fde0e16d0 ("drivers: clk: Add ZynqMP clock driver")
Signed-off-by: Jay Buddhabhatti <jay.buddhabhatti@amd.com>
Link: https://lore.kernel.org/r/20231129112916.23125-2-jay.buddhabhatti@amd.com
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit da235d2fac ]
The hardware manual of both RZ/G2L and RZ/G3S specifies that the reset
monitor registers need to be interrogated when the reset signals are
toggled (chapters "Procedures for Supplying and Stopping Reset Signals"
and "Procedure for Activating Modules"). Without this, there is a
chance that different modules (e.g. Ethernet) are not ready after their
reset signal is toggled, leading to failures (on probe or resume from
deep sleep states).
The same indications are available for RZ/V2M for TYPE-B reset controls.
Fixes: ef3c613ccd ("clk: renesas: Add CPG core wrapper for RZ/G2L SoC")
Fixes: 8090bea324 ("clk: renesas: rzg2l: Add support for RZ/V2M reset monitor reg")
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/20231207070700.4156557-2-claudiu.beznea.uj@bp.renesas.com
Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 99fe9ee56b ]
SCLK_SDMMC is the parent for SCLK_SDMMC_DRV and SCLK_SDMMC_SAMPLE, but
used with the (more) correct name sclk_sdmmc. SD card tuning does currently
fail as the parent can't be found under that name.
There is no need to suffix the name with '0' since RK312x SoCs do have a
single sdmmc controller - so rename it to the name which is already used
by it's children.
Fixes: f6022e88fa ("clk: rockchip: add clock controller for rk3128")
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Link: https://lore.kernel.org/r/20231127181415.11735-6-knaerzche@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 98dcc6be38 ]
According to the TRM there are no specific gpll_peri, cpll_peri,
gpll_div2_peri or gpll_div3_peri gates, but a single clk_peri_src gate.
Instead mux_clk_peri_src directly connects to the plls respectively the pll
divider clocks.
Fix this by creating a single gated composite.
Also rename all occurrences of aclk_peri_src to clk_peri_src, since it
is the parent for peri aclks, pclks and hclks. That name also matches
the one used in the TRM.
Fixes: f6022e88fa ("clk: rockchip: add clock controller for rk3128")
Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com>
[renamed aclk_peri_src -> clk_peri_src and added commit message]
Signed-off-by: Alex Bee <knaerzche@gmail.com>
Link: https://lore.kernel.org/r/20231127181415.11735-4-knaerzche@gmail.com
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Sasha Levin <sashal@kernel.org>
[ Upstream commit 7e52b1164a ]
Increase the size of temporary print buffer on stack to fix the
following warnings reported by LKP.
Since all the input parameters of snprintf() are under control
of this driver, it is not possible to trigger and overflow here,
but since the print buffer is on stack and discarded once driver
probe() finishes, it is not an issue to increase it by 10 bytes
and fix the warning in the process. Make it so.
"
drivers/clk/clk-si521xx.c: In function 'si521xx_probe':
>> drivers/clk/clk-si521xx.c:318:26: warning: '%d' directive output may be truncated writing between 1 and 10 bytes into a region of size 2 [-Wformat-truncation=]
snprintf(name, 6, "DIFF%d", i);
^~
drivers/clk/clk-si521xx.c:318:21: note: directive argument in the range [0, 2147483647]
snprintf(name, 6, "DIFF%d", i);
^~~~~~~~
drivers/clk/clk-si521xx.c:318:3: note: 'snprintf' output between 6 and 15 bytes into a destination of size 6
snprintf(name, 6, "DIFF%d", i);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"
Fixes: edc12763a3 ("clk: si521xx: Clock driver for Skyworks Si521xx I2C PCIe clock generators")
Reported-by: kernel test robot <lkp@intel.com>
Closes: https://lore.kernel.org/oe-kbuild-all/202310260412.AGASjFN4-lkp@intel.com/
Signed-off-by: Marek Vasut <marex@denx.de>
Link: https://lore.kernel.org/r/20231027085840.30098-1-marex@denx.de
Signed-off-by: Stephen Boyd <sboyd@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
