linux-stable.git/drivers/clk, branch v6.1.2

clk: imx: imx8mp: add shared clk gate for usb suspend clk

2022-12-31T12:33:09+00:00

commit ed1f4ccfe947a3e1018a3bd7325134574c7ff9b3 upstream.

32K usb suspend clock gate is shared with usb_root_clk, this
shared clock gate was initially defined only for usb suspend
clock, usb suspend clk is kept on while system is active or
system sleep with usb wakeup enabled, so usb root clock is
fine with this situation; with the commit cf7f3f4fa9e5
("clk: imx8mp: fix usb_root_clk parent"), this clock gate is
changed to be for usb root clock, but usb root clock will
be off while usb is suspended, so usb suspend clock will be
gated too, this cause some usb functionalities will not work,
so define this clock to be a shared clock gate to conform with
the real HW status.

Fixes: 9c140d9926761 ("clk: imx: Add support for i.MX8MP clock driver")
Cc: stable@vger.kernel.org # v5.19+
Tested-by: Alexander Stein 
Signed-off-by: Li Jun 
Signed-off-by: Abel Vesa 
Link: https://lore.kernel.org/r/1664549663-20364-2-git-send-email-jun.li@nxp.com
Signed-off-by: Greg Kroah-Hartman

clk: st: Fix memory leak in st_of_quadfs_setup()

2022-12-31T12:33:04+00:00

[ Upstream commit cfd3ffb36f0d566846163118651d868e607300ba ]

If st_clk_register_quadfs_pll() fails, @lock should be freed before goto
@err_exit, otherwise will cause meory leak issue, fix it.

Signed-off-by: Xiu Jianfeng 
Link: https://lore.kernel.org/r/20221122133614.184910-1-xiujianfeng@huawei.com
Reviewed-by: Patrice Chotard 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

clk: socfpga: Fix memory leak in socfpga_gate_init()

2022-12-31T12:32:26+00:00

[ Upstream commit 0b8ba891ad4d1ef6bfa4c72efc83f9f9f855f68b ]

Free @socfpga_clk and @ops on the error path to avoid memory leak issue.

Fixes: a30a67be7b6e ("clk: socfpga: Don't have get_parent for single parent ops")
Signed-off-by: Xiu Jianfeng 
Link: https://lore.kernel.org/r/20221123031622.63171-1-xiujianfeng@huawei.com
Acked-by: Dinh Nguyen 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

clk: samsung: Fix memory leak in _samsung_clk_register_pll()

2022-12-31T12:32:25+00:00

[ Upstream commit 5174e5b0d1b669a489524192b6adcbb3c54ebc72 ]

If clk_register() fails, @pll->rate_table may have allocated memory by
kmemdup(), so it needs to be freed, otherwise will cause memory leak
issue, this patch fixes it.

Fixes: 3ff6e0d8d64d ("clk: samsung: Add support to register rate_table for samsung plls")
Signed-off-by: Xiu Jianfeng 
Link: https://lore.kernel.org/r/20221123032015.63980-1-xiujianfeng@huawei.com
Reviewed-by: Alim Akhtar 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

clk: qcom: clk-krait: fix wrong div2 functions

2022-12-31T12:32:21+00:00

[ Upstream commit d676d3a3717cf726d3affedbe5ba98fc4ccad7b3 ]

Currently div2 value is applied to the wrong bits. This is caused by a
bug in the code where the shift is done only for lpl, for anything
else the mask is not shifted to the correct bits.

Fix this by correctly shift if lpl is not supported.

Fixes: 4d7dc77babfe ("clk: qcom: Add support for Krait clocks")
Signed-off-by: Christian Marangi 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20221108215625.30186-1-ansuelsmth@gmail.com
Signed-off-by: Sasha Levin

clk: qcom: lpass-sc7180: Fix pm_runtime usage

2022-12-31T12:32:21+00:00

[ Upstream commit ff1ccf59eaffd192efe21f7de9fb0c130faf1b1b ]

The sc7180 lpass clock controller's pm_runtime usage wasn't broken
quite as spectacularly as the sc7280's pm_runtime usage, but it was
still broken. Putting some printouts in at boot showed me this (with
serial console enabled, which makes the prints slow and thus changes
timing):
  [    3.109951] DOUG: my_pm_clk_resume, usage=1
  [    3.114767] DOUG: my_pm_clk_resume, usage=1
  [    3.664443] DOUG: my_pm_clk_suspend, usage=0
  [    3.897566] DOUG: my_pm_clk_suspend, usage=0
  [    3.910137] DOUG: my_pm_clk_resume, usage=1
  [    3.923217] DOUG: my_pm_clk_resume, usage=0
  [    4.440116] DOUG: my_pm_clk_suspend, usage=-1
  [    4.444982] DOUG: my_pm_clk_suspend, usage=0
  [   14.170501] DOUG: my_pm_clk_resume, usage=1
  [   14.176245] DOUG: my_pm_clk_resume, usage=0

...or this w/out serial console:
  [    0.556139] DOUG: my_pm_clk_resume, usage=1
  [    0.556279] DOUG: my_pm_clk_resume, usage=1
  [    1.058422] DOUG: my_pm_clk_suspend, usage=-1
  [    1.058464] DOUG: my_pm_clk_suspend, usage=0
  [    1.186250] DOUG: my_pm_clk_resume, usage=1
  [    1.186292] DOUG: my_pm_clk_resume, usage=0
  [    1.731536] DOUG: my_pm_clk_suspend, usage=-1
  [    1.731557] DOUG: my_pm_clk_suspend, usage=0
  [   10.288910] DOUG: my_pm_clk_resume, usage=1
  [   10.289496] DOUG: my_pm_clk_resume, usage=0

It seems to be doing roughly the right sequence of calls, but just
like with sc7280 this is more by luck than anything. Having a usage of
-1 is just not OK.

Let's fix this like we did with sc7280.

Signed-off-by: Douglas Anderson 
Fixes: ce8c195e652f ("clk: qcom: lpasscc: Introduce pm autosuspend for SC7180")
Reviewed-by: Stephen Boyd 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20221104064055.2.I49b25b9bda9430fc7ea21e5a708ca5a0aced2798@changeid
Signed-off-by: Sasha Levin

clk: qcom: lpass-sc7280: Fix pm_runtime usage

2022-12-31T12:32:21+00:00

[ Upstream commit d470be3c4f30b4666e43eef6bab80f543563cdb0 ]

The pm_runtime usage in lpass-sc7280 was broken in quite a few
ways. Specifically:

1. At the end of probe it called "put" twice. This is a no-no and will
   end us up with a negative usage count. Even worse than calling
   "put" twice, it never called "get" once. Thus after bootup it could
   be seen that the runtime usage of the devices managed by this
   driver was -2.
2. In some error cases it manually called pm_runtime_disable() even
   though it had previously used devm_add_action_or_reset() to set
   this up to be called automatically. This meant that in these error
   cases we'd double-call pm_runtime_disable().
3. It forgot to call undo pm_runtime_use_autosuspend(), which can
   sometimes have subtle problems (and the docs specifically mention
   that you need to undo this function).

Overall the above seriously calls into question how this driver is
working. It seems like a combination of "it doesn't", "by luck", and
"because of the weirdness of runtime_pm". Specifically I put a
printout to the serial console every time the runtime suspend/resume
was called for the two devices created by this driver (I wrapped the
pm_clk calls). When I had serial console enabled, I found that the
calls got resumed at bootup (when the clk core probed and before our
double-put) and then never touched again. That's no good.
  [    0.829997] DOUG: my_pm_clk_resume, usage=1
  [    0.835487] DOUG: my_pm_clk_resume, usage=1

When I disabled serial console (speeding up boot), I got a different
pattern, which I guess (?) is better:
  [    0.089767] DOUG: my_pm_clk_resume, usage=1
  [    0.090507] DOUG: my_pm_clk_resume, usage=1
  [    0.151885] DOUG: my_pm_clk_suspend, usage=-2
  [    0.151914] DOUG: my_pm_clk_suspend, usage=-2
  [    1.825747] DOUG: my_pm_clk_resume, usage=-1
  [    1.825774] DOUG: my_pm_clk_resume, usage=-1
  [    1.888269] DOUG: my_pm_clk_suspend, usage=-2
  [    1.888282] DOUG: my_pm_clk_suspend, usage=-2

These different patterns have to do with the fact that the core PM
Runtime code really isn't designed to be robust to negative usage
counts and sometimes may happen to stumble upon a behavior that
happens to "work". For instance, you can see that
__pm_runtime_suspend() will treat any non-zero value (including
negative numbers) as if the device is in use.

In any case, let's fix the driver to be correct. We'll hold a
pm_runtime reference for the whole probe and then drop it (once!) at
the end. We'll get rid of manual pm_runtime_disable() calls in the
error handling. We'll also switch to devm_pm_runtime_enable(), which
magically handles undoing pm_runtime_use_autosuspend() as of commit
b4060db9251f ("PM: runtime: Have devm_pm_runtime_enable() handle
pm_runtime_dont_use_autosuspend()").

While we're at this, let's also use devm_pm_clk_create() instead of
rolling it ourselves.

Note that the above changes make it obvious that
lpassaudio_create_pm_clks() was doing more than just creating
clocks. It was also setting up pm_runtime parameters. Let's rename it.

All of these problems were found by code inspection. I started looking
at this driver because it was involved in a deadlock that I reported a
while ago [1]. Though I bisected the deadlock to commit 1b771839de05
("clk: qcom: gdsc: enable optional power domain support"), it was
never really clear why that patch affected it other than a luck of
timing changes. I'll also note that by fixing the timing (as done in
this change) we also seem to aboid the deadlock, which is a nice
benefit.

Also note that some of the fixes here are much the same type of stuff
that Dmitry did in commit 72cfc73f4663 ("clk: qcom: use
devm_pm_runtime_enable and devm_pm_clk_create"), but I guess
lpassaudiocc-sc7280.c didn't exist then.

[1] https://lore.kernel.org/r/20220922154354.2486595-1-dianders@chromium.org

Fixes: a9dd26639d05 ("clk: qcom: lpass: Add support for LPASS clock controller for SC7280")
Signed-off-by: Douglas Anderson 
Reviewed-by: Dmitry Baryshkov 
Reviewed-by: Stephen Boyd 
Signed-off-by: Bjorn Andersson 
Link: https://lore.kernel.org/r/20221104064055.1.I00a0e4564a25489e85328ec41636497775627564@changeid
Signed-off-by: Sasha Levin

clk: visconti: Fix memory leak in visconti_register_pll()

2022-12-31T12:32:19+00:00

[ Upstream commit b55226f8553d255f5002c751c7c6ba9291f34bf2 ]

@pll->rate_table has allocated memory by kmemdup(), if clk_hw_register()
fails, it should be freed, otherwise it will cause memory leak issue,
this patch fixes it.

Fixes: b4cbe606dc36 ("clk: visconti: Add support common clock driver and reset driver")
Signed-off-by: Xiu Jianfeng 
Link: https://lore.kernel.org/r/20221122152353.204132-1-xiujianfeng@huawei.com
Acked-by: Nobuhiro Iwamatsu 
Signed-off-by: Stephen Boyd 
Signed-off-by: Sasha Levin

clk: mediatek: fix dependency of MT7986 ADC clocks

2022-12-31T12:32:19+00:00

[ Upstream commit a46315295489933209e902638cd287aeb5f982ab ]

It seems like CLK_INFRA_ADC_FRC_CK always need to be enabled for
CLK_INFRA_ADC_26M_CK to work. Instead of adding this dependency to the
mtk-thermal and mt6577_auxadc drivers, add dependency to the clock
driver clk-mt7986-infracfg.c.

Fixes: ec97d23c8e22 ("clk: mediatek: add mt7986 clock support")
Suggested-by: AngeloGioacchino Del Regno 
Reviewed-by: AngeloGioacchino Del Regno 
Signed-off-by: Daniel Golle 
Link: https://lore.kernel.org/r/5e55012567da74870e1fb2edc2dc513b5821e523.1666801017.git.daniel@makrotopia.org
Signed-off-by: Chen-Yu Tsai 
Signed-off-by: Sasha Levin

clk: imx8mn: fix imx8mn_enet_phy_sels clocks list

2022-12-31T12:32:16+00:00

[ Upstream commit 2626cf67f20b28446dfc3a5b9493dd535cdb747b ]

According to the "Clock Root" table of the reference manual (document
IMX8MNRM Rev 2, 07/2022):

     Clock Root         offset     Source Select (CCM_TARGET_ROOTn[MUX])
        ...              ...                    ...
 ENET_PHY_REF_CLK_ROOT  0xAA80            000 - 24M_REF_CLK
                                          001 - SYSTEM_PLL2_DIV20
                                          010 - SYSTEM_PLL2_DIV8
                                          011 - SYSTEM_PLL2_DIV5
                                          100 - SYSTEM_PLL2_DIV2
                                          101 - AUDIO_PLL1_CLK
                                          110 - VIDEO_PLL_CLK
                                          111 - AUDIO_PLL2_CLK
        ...              ...                    ...

while the imx8mn_enet_phy_sels list didn't contained audio_pll1_out for
source select bits 101b.

Fixes: 96d6392b54dbb ("clk: imx: Add support for i.MX8MN clock driver")
Signed-off-by: Dario Binacchi 
Acked-by: Marco Felsch 
Reviewed-by: Abel Vesa 
Signed-off-by: Abel Vesa 
Link: https://lore.kernel.org/r/20221117113637.1978703-6-dario.binacchi@amarulasolutions.com
Signed-off-by: Sasha Levin