linux-stable.git/drivers/clk, branch v5.2.15

clk: Fix potential NULL dereference in clk_fetch_parent_index()

2019-09-10T09:35:17+00:00

[ Upstream commit 24876f09a7dfe36a82f53d304d8c1bceb3257a0f ]

Don't compare the parent clock name with a NULL name in the
clk_parent_map. This prevents a kernel crash when passing NULL
core->parents[i].name to strcmp().

An example which triggered this is a mux clock with four parents when
each of them is referenced in the clock driver using
clk_parent_data.fw_name and then calling clk_set_parent(clk, 3rd_parent)
on this mux.
In this case the first parent is also the HW default so
core->parents[i].hw is populated when the clock is registered. Calling
clk_set_parent(clk, 3rd_parent) will then go through all parents and
skip the first parent because it's hw pointer doesn't match. For the
second parent no hw pointer is cached yet and clk_core_get(core, 1)
returns a non-matching pointer (which is correct because we are comparing
the second with the third parent). Comparing the result of
clk_core_get(core, 2) with the requested parent gives a match. However
we don't reach this point because right after the clk_core_get(core, 1)
mismatch the old code tried to !strcmp(parent->name, NULL) (where the
second argument is actually core->parents[i].name, but that was never
populated by the clock driver).

Signed-off-by: Martin Blumenstingl 
Link: https://lkml.kernel.org/r/20190815223155.21384-1-martin.blumenstingl@googlemail.com
Fixes: fc0c209c147f ("clk: Allow parents to be specified without string names")
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

clk: Fix falling back to legacy parent string matching

2019-09-10T09:35:17+00:00

[ Upstream commit 4f8c6aba37da199155a121c6cdc38505a9eb0259 ]

Calls to clk_core_get() will return ERR_PTR(-EINVAL) if we've started
migrating a clk driver to use the DT based style of specifying parents
but we haven't made any DT updates yet. This happens when we pass a
non-NULL value as the 'name' argument of of_parse_clkspec(). That
function returns -EINVAL in such a situation, instead of -ENOENT like we
expected. The return value comes back up to clk_core_fill_parent_index()
which proceeds to skip calling clk_core_lookup() because the error
pointer isn't equal to -ENOENT, it's -EINVAL.

Furthermore, we blindly overwrite the error pointer returned by
clk_core_get() with NULL when there isn't a legacy .name member
specified in the parent map. This isn't too bad right now because we
don't really care to differentiate NULL from an error, but in the future
we should only try to do a legacy lookup if we know we might find
something. This way DT lookups that fail don't try to lookup based on
strings when there isn't any string to match, hiding the error from DT
parsing.

Fix both these problems so that clk provider drivers can use the new
style of parent mapping without having to also update their DT at the
same time. This patch is based on an earlier patch from Taniya Das which
checked for -EINVAL in addition to -ENOENT return values from
clk_core_get().

Fixes: 601b6e93304a ("clk: Allow parents to be specified via clkspec index")
Cc: Taniya Das 
Cc: Jerome Brunet 
Cc: Chen-Yu Tsai 
Reported-by: Taniya Das 
Signed-off-by: Stephen Boyd 
Link: https://lkml.kernel.org/r/20190813214147.34394-1-sboyd@kernel.org
Tested-by: Taniya Das 
Signed-off-by: Sasha Levin

clk: samsung: exynos542x: Move MSCL subsystem clocks to its sub-CMU

2019-09-10T09:35:12+00:00

[ Upstream commit baf7b79e1ad79a41fafd8ab8597b9a96962d822d ]

M2M scaler clocks require special handling of their parent bus clock during
power domain on/off sequences. MSCL clocks were not initially added to the
sub-CMU handler, because that time there was no driver for the M2M scaler
device and it was not possible to test it.

This patch fixes this issue. Parent clock for M2M scaler devices is now
properly preserved during MSC power domain on/off sequence. This gives M2M
scaler devices proper performance: fullHD XRGB32 image 1000 rotations test
takes 3.17s instead of 45.08s.

Fixes: b06a532bf1fa ("clk: samsung: Add Exynos5 sub-CMU clock driver")
Signed-off-by: Marek Szyprowski 
Link: https://lkml.kernel.org/r/20190808121839.23892-1-m.szyprowski@samsung.com
Acked-by: Sylwester Nawrocki 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

clk: samsung: exynos5800: Move MAU subsystem clocks to MAU sub-CMU

2019-09-10T09:35:11+00:00

[ Upstream commit b6adeb6bc61c2567b9efd815d61a61b34a2e51a6 ]

This patch fixes broken sound on Exynos5422/5800 platforms after
system/suspend resume cycle in cases where the audio root clock
is derived from MAU_EPLL_CLK.

In order to preserve state of the USER_MUX_MAU_EPLL_CLK clock mux
during system suspend/resume cycle for Exynos5800 we group the MAU
block input clocks in "MAU" sub-CMU and add the clock mux control
bit to .suspend_regs.  This ensures that user configuration of the mux
is not lost after the PMU block changes the mux setting to OSC_DIV
when switching off the MAU power domain.

Adding the SRC_TOP9 register to exynos5800_clk_regs[] array is not
sufficient as at the time of the syscore_ops suspend call MAU power
domain is already turned off and we already save and subsequently
restore an incorrect register's value.

Fixes: b06a532bf1fa ("clk: samsung: Add Exynos5 sub-CMU clock driver")
Reported-by: Jaafar Ali 
Suggested-by: Marek Szyprowski 
Tested-by: Jaafar Ali 
Signed-off-by: Sylwester Nawrocki 
Link: https://lkml.kernel.org/r/20190808144929.18685-2-s.nawrocki@samsung.com
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

clk: samsung: Change signature of exynos5_subcmus_init() function

2019-09-10T09:35:11+00:00

[ Upstream commit bf32e7dbfce87d518c0ca77af890eae9ab8d6ab9 ]

In order to make it easier in subsequent patch to create different subcmu
lists for exynos5420 and exynos5800 SoCs the code is rewritten so we pass
an array of pointers to the subcmus initialization function.

Fixes: b06a532bf1fa ("clk: samsung: Add Exynos5 sub-CMU clock driver")
Tested-by: Jaafar Ali 
Signed-off-by: Sylwester Nawrocki 
Link: https://lkml.kernel.org/r/20190808144929.18685-1-s.nawrocki@samsung.com
Reviewed-by: Marek Szyprowski 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

clk: socfpga: stratix10: fix rate caclulationg for cnt_clks

2019-08-29T06:30:21+00:00

commit c7ec75ea4d5316518adc87224e3cff47192579e7 upstream.

Checking bypass_reg is incorrect for calculating the cnt_clk rates.
Instead we should be checking that there is a proper hardware register
that holds the clock divider.

Cc: stable@vger.kernel.org
Signed-off-by: Dinh Nguyen 
Link: https://lkml.kernel.org/r/20190814153014.12962-1-dinguyen@kernel.org
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman

clk: renesas: cpg-mssr: Fix reset control race condition

2019-08-25T14:10:25+00:00

[ Upstream commit e1f1ae8002e4b06addc52443fcd975bbf554ae92 ]

The module reset code in the Renesas CPG/MSSR driver uses
read-modify-write (RMW) operations to write to a Software Reset Register
(SRCRn), and simple writes to write to a Software Reset Clearing
Register (SRSTCLRn), as was mandated by the R-Car Gen2 and Gen3 Hardware
User's Manuals.

However, this may cause a race condition when two devices are reset in
parallel: if the reset for device A completes in the middle of the RMW
operation for device B, device A may be reset again, causing subtle
failures (e.g. i2c timeouts):

	thread A			thread B
	--------			--------

	val = SRCRn
	val |= bit A
	SRCRn = val

	delay

					val = SRCRn (bit A is set)

	SRSTCLRn = bit A
	(bit A in SRCRn is cleared)

					val |= bit B
					SRCRn = val (bit A and B are set)

This can be reproduced on e.g. Salvator-XS using:

    $ while true; do i2cdump -f -y 4 0x6A b > /dev/null; done &
    $ while true; do i2cdump -f -y 2 0x10 b > /dev/null; done &

    i2c-rcar e6510000.i2c: error -110 : 40000002
    i2c-rcar e66d8000.i2c: error -110 : 40000002

According to the R-Car Gen3 Hardware Manual Errata for Rev.
0.80 of Feb 28, 2018, reflected in Rev. 1.00 of the R-Car Gen3 Hardware
User's Manual, writes to SRCRn do not require read-modify-write cycles.

Note that the R-Car Gen2 Hardware User's Manual has not been updated
yet, and still says a read-modify-write sequence is required.  According
to the hardware team, the reset hardware block is the same on both R-Car
Gen2 and Gen3, though.

Hence fix the issue by replacing the read-modify-write operations on
SRCRn by simple writes.

Reported-by: Yao Lihua 
Fixes: 6197aa65c4905532 ("clk: renesas: cpg-mssr: Add support for reset control")
Signed-off-by: Geert Uytterhoeven 
Tested-by: Linh Phung 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

clk: sprd: Select REGMAP_MMIO to avoid compile errors

2019-08-25T14:10:25+00:00

[ Upstream commit c9a67cbb5189e966c70451562b2ca4c3876ab546 ]

Make REGMAP_MMIO selected to avoid undefined reference to regmap symbols.

Fixes: d41f59fd92f2 ("clk: sprd: Add common infrastructure")
Signed-off-by: Chunyan Zhang 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

clk: at91: generated: Truncate divisor to GENERATED_MAX_DIV + 1

2019-08-25T14:10:25+00:00

[ Upstream commit 1573eebeaa8055777eb753f9b4d1cbe653380c38 ]

In clk_generated_determine_rate(), if the divisor is greater than
GENERATED_MAX_DIV + 1, then the wrong best_rate will be returned.
If clk_generated_set_rate() will be called later with this wrong
rate, it will return -EINVAL, so the generated clock won't change
its value. Do no let the divisor be greater than GENERATED_MAX_DIV + 1.

Fixes: 8c7aa6328947 ("clk: at91: clk-generated: remove useless divisor loop")
Signed-off-by: Codrin Ciubotariu 
Acked-by: Nicolas Ferre 
Acked-by: Ludovic Desroches 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

clk: mediatek: mt8183: Register 13MHz clock earlier for clocksource

2019-08-06T17:08:19+00:00

commit c93d059a80450af99dd6c0e8c36790579343675a upstream.

The 13MHz clock should be registered before clocksource driver is
initialized. Use CLK_OF_DECLARE_DRIVER() to guarantee.

Fixes: acddfc2c261b ("clk: mediatek: Add MT8183 clock support")
Cc: 
Signed-off-by: Weiyi Lu 
Signed-off-by: Stephen Boyd 
Signed-off-by: Greg Kroah-Hartman