Re: [PATCH 1/2] stmmac: intel: Add a missing clk_disable_unprepare() call in intel_eth_pci_remove()

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Le 30/07/2022 à 22:17, Andy Shevchenko a écrit :
On Sat, Jul 30, 2022 at 08:19:47PM +0200, Christophe JAILLET wrote:
Commit 09f012e64e4b ("stmmac: intel: Fix clock handling on error and remove
paths") removed this clk_disable_unprepare()

This was partly revert by commit ac322f86b56c ("net: stmmac: Fix clock
handling on remove path") which removed this clk_disable_unprepare()
because:
"
    While unloading the dwmac-intel driver, clk_disable_unprepare() is
    being called twice in stmmac_dvr_remove() and
    intel_eth_pci_remove(). This causes kernel panic on the second call.
"

However later on, commit 5ec55823438e8 ("net: stmmac: add clocks management
for gmac driver") has updated stmmac_dvr_remove() which do not call
clk_disable_unprepare() anymore.

So this call should now be called from intel_eth_pci_remove().

The correct way of fixing it (which might be very well end up functionally
the same as this patch), is to introduce ->quit() in struct stmmac_pci_info
and assign it correctly, because not all platforms enable clocks.

I won't be able to propose anything like that.

By the way, in the first sentence of my log, s/removed/added/.
(I hope that it can be fixed when/if the patch is applied)


Thanks for the review.

CJ


Perhaps, we may leave this patch as is (for the sake of easy backporting) and
apply another one as I explained above to avoid similar mistakes in the future.

Reviewed-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx>

Fixes: 5ec55823438e8 ("net: stmmac: add clocks management for gmac driver")
Signed-off-by: Christophe JAILLET <christophe.jaillet@xxxxxxxxxx>
---
/!\     This patch is HIGHLY speculative.     /!\

The corresponding clk_disable_unprepare() is still called within the pm
related stmmac_bus_clks_config() function.

However, with my limited understanding of the pm API, I think it that the
patch is valid.
(in other word, does the pm_runtime_put() and/or pm_runtime_disable()
and/or stmmac_dvr_remove() can end up calling .runtime_suspend())

So please review with care, as I'm not able to test the change by myself.


If I'm wrong, maybe a comment explaining why it is safe to have this
call in the error handling path of the probe and not in the remove function
would avoid erroneous patches generated from static code analyzer to be
sent.
---
  drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
index 52f9ed8db9c9..9f38642f86ce 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-intel.c
@@ -1134,6 +1134,7 @@ static void intel_eth_pci_remove(struct pci_dev *pdev)
stmmac_dvr_remove(&pdev->dev); + clk_disable_unprepare(plat->stmmac_clk);
  	clk_unregister_fixed_rate(priv->plat->stmmac_clk);
pcim_iounmap_regions(pdev, BIT(0));
--
2.34.1







[Index of Archives]     [Kernel Development]     [Kernel Announce]     [Kernel Newbies]     [Linux Networking Development]     [Share Photos]     [IDE]     [Security]     [Git]     [Netfilter]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Device Mapper]

  Powered by Linux