linux-stable.git/drivers/clk, branch v4.4.227

clk: xgene: Don't call __pa on ioremaped address

2020-05-10T08:26:18+00:00

commit 06b113e9f28f8657715919087a3f54b77d1634ed upstream.

ioremaped addresses are not linearly mapped so the physical
address can not be figured out via __pa. More generally, there
is no guarantee that backing value of an ioremapped address
is a physical address at all. The value here is only used
for debugging so just drop the call to __pa on the ioremapped
address.

Fixes: 6ae5fd381251 ("clk: xgene: Silence sparse warnings")
Signed-off-by: Laura Abbott 
Acked-by: Loc Ho 
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

clk: imx: clk-pllv3: fix incorrect handle of enet powerdown bit

2020-05-10T08:26:18+00:00

commit b3e76bdc0b2190e67427d31cd740debd01c03631 upstream.

After commit f53947456f98 ("ARM: clk: imx: update pllv3 to support imx7"),
the former used BM_PLL_POWER bit is not correct anymore for IMX7 ENET.
Instead, pll->powerdown holds the correct bit, so using powerdown bit
in clk_pllv3_{prepare | unprepare} functions.

Fixes: f53947456f98 ("ARM: clk: imx: update pllv3 to support imx7")
Signed-off-by: Dong Aisheng 
Signed-off-by: Shawn Guo 
Signed-off-by: Greg Kroah-Hartman

clk: multiplier: Prevent the multiplier from under / over flowing

2020-05-10T08:26:18+00:00

commit 25f77a3aa4cb948666bf8e7fd972533ea487c3bd upstream.

In the current multiplier base clock implementation, if the
CLK_SET_RATE_PARENT flag isn't set, the code will not make sure that the
multiplier computed remains within the boundaries of our clock.

This means that if the clock we want to reach is below the parent rate,
or if the multiplier is above the maximum that we can reach, we will end up
with a completely bogus one that the clock cannot achieve.

Fixes: f2e0a53271a4 ("clk: Add a basic multiplier clock")
Signed-off-by: Maxime Ripard 
Signed-off-by: Michael Turquette 
Link: lkml.kernel.org/r/1463402840-17062-3-git-send-email-maxime.ripard@free-electrons.com
Signed-off-by: Greg Kroah-Hartman

clk: ti: omap3+: dpll: use non-locking version of clk_get_rate

2020-05-10T08:26:18+00:00

commit a0d54c3899aaeb047969d9479263c6bcf385c331 upstream.

As the code in this file is being executed within irq context in some
cases, we must avoid the clk_get_rate which uses mutex internally.
Switch the code to use clk_hw_get_rate instead which is non-locking.

This fixes an issue where PM runtime will hang the system if enabled
with a serial console before a suspend-resume cycle.

Signed-off-by: Tero Kristo 
Tested-by: Tony Lindgren 
Fixes: a53ad8ef3dcc ("clk: ti: Convert to clk_hw based provider APIs")
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

clk: gpio: handle error codes for of_clk_get_parent_count()

2020-05-10T08:26:17+00:00

commit 0b2e78865d92e2d70542cb1d4d7af1d4ea0a286d upstream.

We might make bad memory allocations if we get (e.g.) -ENOSYS from
of_clk_get_parent_count().

Noticed by Coverity.

Fixes: f66541ba02d5 ("clk: gpio: Get parent clk names in of_gpio_clk_setup()")
Signed-off-by: Brian Norris 
Cc: Jyri Sarha 
Cc: Sergej Sawazki 
Cc: Stephen Boyd 
Signed-off-by: Michael Turquette 
Signed-off-by: Greg Kroah-Hartman

clk: st: avoid uninitialized variable use

2020-05-10T08:26:17+00:00

commit 2dd52d7f6f9d9d03a82a68040ac3d221dd79af94 upstream.

quadfs_pll_fs660c32_round_rate prints a few structure members
that are never initialized, and also doesn't print the only one
it cares about. We get a gcc warning about the ones that
are printed:

clk/st/clkgen-fsyn.c:560:93: warning: 'params.sdiv' may be used uninitialized in this function
clk/st/clkgen-fsyn.c:560:93: warning: 'params.mdiv' may be used uninitialized in this function
clk/st/clkgen-fsyn.c:560:93: warning: 'params.pe' may be used uninitialized in this function
clk/st/clkgen-fsyn.c:560:93: warning: 'params.nsdiv' may be used uninitialized in this function

This changes the code to no longer print uninitialized data, and
for good measure it also prints the ndiv member that is being
set.

Signed-off-by: Arnd Bergmann 
Fixes: 5f7aa9071e93 ("clk: st: Support for QUADFS inside ClockGenB/C/D/E/F")
Acked-by: Gabriel Fernandez 
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

clk: rockchip: Revert "clk: rockchip: reset init state before mmc card initialization"

2020-05-10T08:26:07+00:00

commit 4715f81afc342996f680b08c944a712d9cbef11b upstream.

This reverts commit 7a03fe6f48f3 ("clk: rockchip: reset init state
before mmc card initialization").

Though not totally obvious from the commit message nor from the source
code, that commit appears to be trying to reset the "_drv" MMC clocks to
90 degrees (note that the "_sample" MMC clocks have a shift of 0 so are
not touched).

The major problem here is that it doesn't properly reset things.  The
phase is a two bit field and the commit only touches one of the two
bits.  Thus the commit had the following affect:
- phase   0  => phase  90
- phase  90  => phase  90
- phase 180  => phase 270
- phase 270  => phase 270

Things get even weirder if you happen to have a bootloader that was
actually using delay elements (should be no reason to, but you never
know), since those are additional bits that weren't touched by the
original patch.

This is unlikely to be what we actually want.  Checking on rk3288-veyron
devices, I can see that the bootloader leaves these clocks as:
- emmc:  phase 180
- sdmmc: phase 90
- sdio0: phase 90

Thus on rk3288-veyron devices the commit we're reverting had the effect
of changing the eMMC clock to phase 270.  This probably explains the
scattered reports I've heard of eMMC devices not working on some veyron
devices when using the upstream kernel.

The original commit was presumably made because previously the kernel
didn't touch the "_drv" phase at all and relied on whatever value was
there when the kernel started.  If someone was using a bootloader that
touched the "_drv" phase then, indeed, we should have code in the kernel
to fix that.  ...and also, to get ideal timings, we should also have the
kernel change the phase depending on the speed mode.  In fact, that's
the subject of a recent patch I posted at
.

Ideally, we should take both the patch posted to dw_mmc and this
revert.  Since those will likely go through different trees, here I
describe behavior with the combos:

1. Just this revert: likely will fix rk3288-veyron eMMC on some devices
   + other cases; might break someone with a strange bootloader that
   sets the phase to 0 or one that uses delay elements (pretty
   unpredicable what would happen in that case).
2. Just dw_mmc patch: fixes everyone.  Effectly the dw_mmc patch will
   totally override the broken patch and fix everything.
3. Both patches: fixes everyone.  Once dw_mmc is initting properly then
   any defaults from the clock code doesn't mattery.

Fixes: 7a03fe6f48f3 ("clk: rockchip: reset init state before mmc card initialization")
Signed-off-by: Douglas Anderson 
Reviewed-by: Shawn Lin 
Signed-off-by: Greg Kroah-Hartman 

[emmc and sdmmc still work on all current boards in mainline after this
revert, so they should take precedence over any out-of-tree board that
will hopefully again get fixed with the better upcoming dw_mmc change.]
Signed-off-by: Heiko Stuebner

clk: tegra: Fix Tegra PMC clock out parents

2020-04-24T05:57:23+00:00

[ Upstream commit 6fe38aa8cac3a5db38154331742835a4d9740788 ]

Tegra PMC clocks clk_out_1, clk_out_2, and clk_out_3 supported parents
are osc, osc_div2, osc_div4 and extern clock.

Clock driver is using incorrect parents clk_m, clk_m_div2, clk_m_div4
for PMC clocks.

This patch fixes this.

Tested-by: Dmitry Osipenko 
Reviewed-by: Dmitry Osipenko 
Signed-off-by: Sowjanya Komatineni 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin

clk: at91: usb: continue if clk_hw_round_rate() return zero

2020-04-24T05:57:23+00:00

[ Upstream commit b0ecf1c6c6e82da4847900fad0272abfd014666d ]

clk_hw_round_rate() may call round rate function of its parents. In case
of SAM9X60 two of USB parrents are PLLA and UPLL. These clocks are
controlled by clk-sam9x60-pll.c driver. The round rate function for this
driver is sam9x60_pll_round_rate() which call in turn
sam9x60_pll_get_best_div_mul(). In case the requested rate is not in the
proper range (rate < characteristics->output[0].min &&
rate > characteristics->output[0].max) the sam9x60_pll_round_rate() will
return a negative number to its caller (called by
clk_core_round_rate_nolock()). clk_hw_round_rate() will return zero in
case a negative number is returned by clk_core_round_rate_nolock(). With
this, the USB clock will continue its rate computation even caller of
clk_hw_round_rate() returned an error. With this, the USB clock on SAM9X60
may not chose the best parent. I detected this after a suspend/resume
cycle on SAM9X60.

Signed-off-by: Claudiu Beznea 
Link: https://lkml.kernel.org/r/1579261009-4573-2-git-send-email-claudiu.beznea@microchip.com
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

clk: qcom: rcg: Return failure for RCG update

2020-04-13T08:31:35+00:00

commit 21ea4b62e1f3dc258001a68da98c9663a9dbd6c7 upstream.

In case of update config failure, return -EBUSY, so that consumers could
handle the failure gracefully.

Signed-off-by: Taniya Das 
Link: https://lkml.kernel.org/r/1557339895-21952-2-git-send-email-tdas@codeaurora.org
Signed-off-by: Stephen Boyd 
Signed-off-by: Lee Jones 
Signed-off-by: Greg Kroah-Hartman