<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/drivers/clk, branch v6.0</title>
<subtitle>Mirror of https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
</subtitle>
<id>https://git.shady.money/linux/atom?h=v6.0</id>
<link rel='self' href='https://git.shady.money/linux/atom?h=v6.0'/>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/'/>
<updated>2022-09-29T01:37:36Z</updated>
<entry>
<title>clk: imx93: drop of_match_ptr</title>
<updated>2022-09-29T01:37:36Z</updated>
<author>
<name>Peng Fan</name>
<email>peng.fan@nxp.com</email>
</author>
<published>2022-08-30T03:31:31Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=daaa2fbe678efdaced53d1c635f4d326751addf8'/>
<id>urn:sha1:daaa2fbe678efdaced53d1c635f4d326751addf8</id>
<content type='text'>
There is build warning when CONFIG_OF is not selected.
&gt;&gt; drivers/clk/imx/clk-imx93.c:324:34: warning: 'imx93_clk_of_match'
&gt;&gt; defined but not used [-Wunused-const-variable=]
     324 | static const struct of_device_id imx93_clk_of_match[] = {
         |                                  ^~~~~~~~~~~~~~~~~~

The driver only support DT table, no sense to use of_match_ptr.

Fixes: 24defbe194b6 ("clk: imx: add i.MX93 clk")
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Signed-off-by: Peng Fan &lt;peng.fan@nxp.com&gt;
Link: https://lore.kernel.org/r/20220830033137.4149542-3-peng.fan@oss.nxp.com
Reviewed-by: Abel Vesa &lt;abel.vesa@linaro.org&gt;
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
</content>
</entry>
<entry>
<title>clk: iproc: Do not rely on node name for correct PLL setup</title>
<updated>2022-09-29T01:33:08Z</updated>
<author>
<name>Florian Fainelli</name>
<email>f.fainelli@gmail.com</email>
</author>
<published>2022-09-05T16:15:03Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1b24a132eba7a1c19475ba2510ec1c00af3ff914'/>
<id>urn:sha1:1b24a132eba7a1c19475ba2510ec1c00af3ff914</id>
<content type='text'>
After commit 31fd9b79dc58 ("ARM: dts: BCM5301X: update CRU block
description") a warning from clk-iproc-pll.c was generated due to a
duplicate PLL name as well as the console stopped working. Upon closer
inspection it became clear that iproc_pll_clk_setup() used the Device
Tree node unit name as an unique identifier as well as a parent name to
parent all clocks under the PLL.

BCM5301X was the first platform on which that got noticed because of the
DT node unit name renaming but the same assumptions hold true for any
user of the iproc_pll_clk_setup() function.

The first 'clock-output-names' property is always guaranteed to be
unique as well as providing the actual desired PLL clock name, so we
utilize that to register the PLL and as a parent name of all children
clock.

Fixes: 5fe225c105fd ("clk: iproc: add initial common clock support")
Signed-off-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Acked-by: Rafał Miłecki &lt;rafal@milecki.pl&gt;
Link: https://lore.kernel.org/r/20220905161504.1526-1-f.fainelli@gmail.com
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
</content>
</entry>
<entry>
<title>clk: sunxi-ng: h6: Fix default PLL GPU rate</title>
<updated>2022-09-28T23:42:51Z</updated>
<author>
<name>Jernej Skrabec</name>
<email>jernej.skrabec@gmail.com</email>
</author>
<published>2022-09-28T20:01:22Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=4014e916fd0cea19b559890588d70b4e9f44b87f'/>
<id>urn:sha1:4014e916fd0cea19b559890588d70b4e9f44b87f</id>
<content type='text'>
In commit 4167ac8a657e ("clk: sunxi-ng: sun50i: h6: Modify GPU clock
configuration to support DFS") divider M0 was forced to be 1 in order to
support DFS. However, that left N as it is, at high value of 36. On
boards without devfreq enabled (all of them in kernel 6.0), this
effectively sets GPU frequency to 864 MHz. This is about 100 MHz above
maximum supported frequency.

In order to fix this, let's set N to 18 (register value 17). That way
default frequency of 432 MHz is preserved.

Fixes: 4167ac8a657e ("clk: sunxi-ng: sun50i: h6: Modify GPU clock configuration to support DFS")
Signed-off-by: Jernej Skrabec &lt;jernej.skrabec@gmail.com&gt;
Link: https://lore.kernel.org/r/20220928200122.3963509-1-jernej.skrabec@gmail.com
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
</content>
</entry>
<entry>
<title>clk: imx: imx6sx: remove the SET_RATE_PARENT flag for QSPI clocks</title>
<updated>2022-09-28T20:26:16Z</updated>
<author>
<name>Han Xu</name>
<email>han.xu@nxp.com</email>
</author>
<published>2022-09-15T15:09:59Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=b1ff1bfe81e763420afd5f3f25f0b3cbfd97055c'/>
<id>urn:sha1:b1ff1bfe81e763420afd5f3f25f0b3cbfd97055c</id>
<content type='text'>
There is no dedicate parent clock for QSPI so SET_RATE_PARENT flag
should not be used. For instance, the default parent clock for QSPI is
pll2_bus, which is also the parent clock for quite a few modules, such
as MMDC, once GPMI NAND set clock rate for EDO5 mode can cause system
hang due to pll2_bus rate changed.

Fixes: f1541e15e38e ("clk: imx6sx: Switch to clk_hw based API")
Signed-off-by: Han Xu &lt;han.xu@nxp.com&gt;
Link: https://lore.kernel.org/r/20220915150959.3646702-1-han.xu@nxp.com
Tested-by: Fabio Estevam &lt;festevam@denx.de&gt;
Reviewed-by: Abel Vesa &lt;abel.vesa@linaro.org&gt;
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
</content>
</entry>
<entry>
<title>Merge tag 'clk-microchip-fixes-6.0' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux into clk-fixes</title>
<updated>2022-09-28T17:52:14Z</updated>
<author>
<name>Stephen Boyd</name>
<email>sboyd@kernel.org</email>
</author>
<published>2022-09-28T17:52:14Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=3d87f6c3be0df4a0f6d0ca719550a7bc77e520bf'/>
<id>urn:sha1:3d87f6c3be0df4a0f6d0ca719550a7bc77e520bf</id>
<content type='text'>
Pull Microchip clock fixes for Polarfire SoCs:

 - fix panic at boot in clock initialization when building with clang-15
 - make RTC's AHB clock critical as rtc will stop if the AHB
   interface clock is disabled

* tag 'clk-microchip-fixes-6.0' of https://git.kernel.org/pub/scm/linux/kernel/git/at91/linux:
  clk: microchip: mpfs: make the rtc's ahb clock critical
  clk: microchip: mpfs: fix clk_cfg array bounds violation
</content>
</entry>
<entry>
<title>clk: microchip: mpfs: make the rtc's ahb clock critical</title>
<updated>2022-09-14T07:45:52Z</updated>
<author>
<name>Conor Dooley</name>
<email>conor.dooley@microchip.com</email>
</author>
<published>2022-09-09T12:31:11Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=05d27090b6dc88bce71a608d1271536e582b73d1'/>
<id>urn:sha1:05d27090b6dc88bce71a608d1271536e582b73d1</id>
<content type='text'>
The onboard RTC's AHB bus clock must be kept running as the RTC will
stop &amp; lose track of time if the AHB interface clock is disabled.

Fixes: 635e5e73370e ("clk: microchip: Add driver for Microchip PolarFire SoC")
Signed-off-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Signed-off-by: Claudiu Beznea &lt;claudiu.beznea@microchip.com&gt;
Link: https://lore.kernel.org/r/20220909123123.2699583-3-conor.dooley@microchip.com
</content>
</entry>
<entry>
<title>clk: microchip: mpfs: fix clk_cfg array bounds violation</title>
<updated>2022-09-14T07:45:51Z</updated>
<author>
<name>Conor Dooley</name>
<email>conor.dooley@microchip.com</email>
</author>
<published>2022-09-09T12:31:10Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=5da39ac5d648cdbfdfa8bea0e0cde279ded5c7c2'/>
<id>urn:sha1:5da39ac5d648cdbfdfa8bea0e0cde279ded5c7c2</id>
<content type='text'>
There is an array bounds violation present during clock registration,
triggered by current code by only specific toolchains. This seems to
fail gracefully in v6.0-rc1, using a toolchain build from the riscv-
gnu-toolchain repo and with clang-15, and life carries on. While
converting the driver to use standard clock structs/ops, kernel panics
were seen during boot when built with clang-15:

[    0.581754] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000b1
[    0.591520] Oops [#1]
[    0.594045] Modules linked in:
[    0.597435] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.0.0-rc1-00011-g8e1459cf4eca #1
[    0.606188] Hardware name: Microchip PolarFire-SoC Icicle Kit (DT)
[    0.613012] epc : __clk_register+0x4a6/0x85c
[    0.617759]  ra : __clk_register+0x49e/0x85c
[    0.622489] epc : ffffffff803faf7c ra : ffffffff803faf74 sp : ffffffc80400b720
[    0.630466]  gp : ffffffff810e93f8 tp : ffffffe77fe60000 t0 : ffffffe77ffb3800
[    0.638443]  t1 : 000000000000000a t2 : ffffffffffffffff s0 : ffffffc80400b7c0
[    0.646420]  s1 : 0000000000000001 a0 : 0000000000000001 a1 : 0000000000000000
[    0.654396]  a2 : 0000000000000001 a3 : 0000000000000000 a4 : 0000000000000000
[    0.662373]  a5 : ffffffff803a5810 a6 : 0000000200000022 a7 : 0000000000000006
[    0.670350]  s2 : ffffffff81099d48 s3 : ffffffff80d6e28e s4 : 0000000000000028
[    0.678327]  s5 : ffffffff810ed3c8 s6 : ffffffff810ed3d0 s7 : ffffffe77ffbc100
[    0.686304]  s8 : ffffffe77ffb1540 s9 : ffffffe77ffb1540 s10: 0000000000000008
[    0.694281]  s11: 0000000000000000 t3 : 00000000000000c6 t4 : 0000000000000007
[    0.702258]  t5 : ffffffff810c78c0 t6 : ffffffe77ff88cd0
[    0.708125] status: 0000000200000120 badaddr: 00000000000000b1 cause: 000000000000000d
[    0.716869] [&lt;ffffffff803fb892&gt;] devm_clk_hw_register+0x62/0xaa
[    0.723420] [&lt;ffffffff80403412&gt;] mpfs_clk_probe+0x1e0/0x244

In v6.0-rc1 and later, this issue is visible without the follow on
patches doing the conversion using toolchains provided by our Yocto
meta layer too.

It fails on "clk_periph_timer" - which uses a different parent, that it
tries to find using the macro:
\#define PARENT_CLK(PARENT) (&amp;mpfs_cfg_clks[CLK_##PARENT].cfg.hw)

If parent is RTCREF, so the macro becomes: &amp;mpfs_cfg_clks[33].cfg.hw
which is well beyond the end of the array. Amazingly, builds with GCC
11.1 see no problem here, booting correctly and hooking the parent up
etc. Builds with clang-15 do not, with the above panic.

Change the macro to use specific offsets depending on the parent rather
than the dt-binding's clock IDs.

Fixes: 1c6a7ea32b8c ("clk: microchip: mpfs: add RTCREF clock control")
CC: Nathan Chancellor &lt;nathan@kernel.org&gt;
Signed-off-by: Conor Dooley &lt;conor.dooley@microchip.com&gt;
Reviewed-by: Claudiu Beznea &lt;claudiu.beznea@microchip.com&gt;
Signed-off-by: Claudiu Beznea &lt;claudiu.beznea@microchip.com&gt;
Link: https://lore.kernel.org/r/20220909123123.2699583-2-conor.dooley@microchip.com
</content>
</entry>
<entry>
<title>clk: ingenic-tcu: Properly enable registers before accessing timers</title>
<updated>2022-09-01T01:28:20Z</updated>
<author>
<name>Aidan MacDonald</name>
<email>aidanmacdonald.0x0@gmail.com</email>
</author>
<published>2022-06-17T12:22:54Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=6726d552a6912e88cf63fe2bda87b2efa0efc7d0'/>
<id>urn:sha1:6726d552a6912e88cf63fe2bda87b2efa0efc7d0</id>
<content type='text'>
Access to registers is guarded by ingenic_tcu_{enable,disable}_regs()
so the stop bit can be cleared before accessing a timer channel, but
those functions did not clear the stop bit on SoCs with a global TCU
clock gate.

Testing on the X1000 has revealed that the stop bits must be cleared
_and_ the global TCU clock must be ungated to access timer registers.
This appears to be the norm on Ingenic SoCs, and is specified in the
documentation for the X1000 and numerous JZ47xx SoCs.

If the stop bit isn't cleared, register writes don't take effect and
the system can be left in a broken state, eg. the watchdog timer may
not run.

The bug probably went unnoticed because stop bits are zeroed when
the SoC is reset, and the kernel does not set them unless a timer
gets disabled at runtime. However, it is possible that a bootloader
or a previous kernel (if using kexec) leaves the stop bits set and
we should not rely on them being cleared.

Fixing this is easy: have ingenic_tcu_{enable,disable}_regs() always
clear the stop bit, regardless of the presence of a global TCU gate.

Reviewed-by: Paul Cercueil &lt;paul@crapouillou.net&gt;
Tested-by: Paul Cercueil &lt;paul@crapouillou.net&gt;
Fixes: 4f89e4b8f121 ("clk: ingenic: Add driver for the TCU clocks")
Cc: stable@vger.kernel.org
Signed-off-by: Aidan MacDonald &lt;aidanmacdonald.0x0@gmail.com&gt;
Link: https://lore.kernel.org/r/20220617122254.738900-1-aidanmacdonald.0x0@gmail.com
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
</content>
</entry>
<entry>
<title>Revert "clk: core: Honor CLK_OPS_PARENT_ENABLE for clk gate ops"</title>
<updated>2022-08-31T19:06:46Z</updated>
<author>
<name>Stephen Boyd</name>
<email>sboyd@kernel.org</email>
</author>
<published>2022-08-31T17:53:25Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=abb5f3f4b1f5f0ad50eb067a00051d3587dec9fb'/>
<id>urn:sha1:abb5f3f4b1f5f0ad50eb067a00051d3587dec9fb</id>
<content type='text'>
This reverts commit 35b0fac808b95eea1212f8860baf6ad25b88b087. Alexander
reports that it causes boot failures on i.MX8M Plus based boards
(specifically imx8mp-tqma8mpql-mba8mpxl.dts).

Reported-by: Alexander Stein &lt;alexander.stein@ew.tq-group.com&gt;
Cc: Chen-Yu Tsai &lt;wenst@chromium.org&gt;
Fixes: 35b0fac808b9 ("clk: core: Honor CLK_OPS_PARENT_ENABLE for clk gate ops")
Link: https://lore.kernel.org/r/12115951.O9o76ZdvQC@steina-w
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
Link: https://lore.kernel.org/r/20220831175326.2523912-1-sboyd@kernel.org
</content>
</entry>
<entry>
<title>clk: bcm: rpi: Show clock id limit in error case</title>
<updated>2022-08-23T22:51:18Z</updated>
<author>
<name>Stefan Wahren</name>
<email>stefan.wahren@i2se.com</email>
</author>
<published>2022-07-13T15:49:53Z</published>
<link rel='alternate' type='text/html' href='https://git.shady.money/linux/commit/?id=1a6052e1483f28808845e51a1c82c96e0e7cd419'/>
<id>urn:sha1:1a6052e1483f28808845e51a1c82c96e0e7cd419</id>
<content type='text'>
The clock id limit will be extended in the future, so it would be
helpful to see the actual clock id limit in case the firmware
response has been rejected.

Signed-off-by: Stefan Wahren &lt;stefan.wahren@i2se.com&gt;
Link: https://lore.kernel.org/r/20220713154953.3336-4-stefan.wahren@i2se.com
Acked-by: Florian Fainelli &lt;f.fainelli@gmail.com&gt;
Reviewed-by: Ivan T. Ivanov &lt;iivanov@suse.de&gt;
Signed-off-by: Stephen Boyd &lt;sboyd@kernel.org&gt;
</content>
</entry>
</feed>
