| Message ID | 20221104083004.2212520-1-linux@rasmusvillemoes.dk (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | ed4314f7729714d788698ade4f9905ee5378ebc0 |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | net: stmmac: dwmac-meson8b: fix meson8b_devm_clk_prepare_enable() | expand |
Hello Rasmus, Thanks for your patch! It would be great if you could Cc linux-amlogic@lists.infradead.org in v2 of this patch, so other Amlogic SoC maintainers can also provide their feedback. On Fri, Nov 4, 2022 at 9:30 AM Rasmus Villemoes <linux@rasmusvillemoes.dk> wrote: > > There are two problems with meson8b_devm_clk_prepare_enable(), > introduced in a54dc4a49045 (net: stmmac: dwmac-meson8b: Make the clock > enabling code re-usable): > > - It doesn't pass the clk argument, but instead always the > rgmii_tx_clk of the device. Indeed, this is a problem - thanks for fixing this! > - It silently ignores the return value of devm_add_action_or_reset(). This second part is not so easy. The thought process back when this code was implemented was: let's continue loading of the driver even if devm_add_action_or_reset() fails as this just means during shutdown/rmmod we don't disable all clocks. If we want to propagate the error code returned by devm_add_action_or_reset() then we also need to do the clean up within meson8b_devm_clk_prepare_enable(), meaning we need to call clk_disable_unprepare() in case devm_add_action_or_reset() failed. Your change just propagates the error code without disabling and unpreparing the clock. [...] > The latter means the callers could > end up with the clock not actually prepared/enabled. In my opinion this statement is not correct: even if devm_add_action_or_reset() fails the clock will be prepared and enabled (by clk_prepare_enable() right before). Personally I would just change the clk argument and keep the return 0. What do you think? Best regards, Martin
Rasmus replied to me off-list yesterday. His reply is important so I am sharing it here. On Fri, Nov 4, 2022 at 10:02 PM Martin Blumenstingl <martin.blumenstingl@googlemail.com> wrote: [...] > If we want to propagate the error code returned by > devm_add_action_or_reset() then we also need to do the clean up within > meson8b_devm_clk_prepare_enable(), meaning we need to call > clk_disable_unprepare() in case devm_add_action_or_reset() failed. > Your change just propagates the error code without disabling and > unpreparing the clock. Rasmus replied to me: "devm_add_action_or_reset precisely calls the reset callback for you if the add action falls..." I was not aware of this but it's actually true, which makes the patch perfectly valid. Thanks for the heads up Rasmus! So this patch gets my: Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> I suggest applying it to net-next (even though it carries a Fixes tag) so the various kernel auto testing labs can try it out on as many Amlogic SoCs as possible. Best regards, Martin
Hello: This patch was applied to netdev/net.git (master) by Jakub Kicinski <kuba@kernel.org>: On Fri, 4 Nov 2022 09:30:04 +0100 you wrote: > There are two problems with meson8b_devm_clk_prepare_enable(), > introduced in a54dc4a49045 (net: stmmac: dwmac-meson8b: Make the clock > enabling code re-usable): > > - It doesn't pass the clk argument, but instead always the > rgmii_tx_clk of the device. > > [...] Here is the summary with links: - net: stmmac: dwmac-meson8b: fix meson8b_devm_clk_prepare_enable() https://git.kernel.org/netdev/net/c/ed4314f77297 You are awesome, thank you!
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c index c7a6588d9398..e8b507f88fbc 100644 --- a/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c +++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c @@ -272,11 +272,9 @@ static int meson8b_devm_clk_prepare_enable(struct meson8b_dwmac *dwmac, if (ret) return ret; - devm_add_action_or_reset(dwmac->dev, - (void(*)(void *))clk_disable_unprepare, - dwmac->rgmii_tx_clk); - - return 0; + return devm_add_action_or_reset(dwmac->dev, + (void(*)(void *))clk_disable_unprepare, + clk); } static int meson8b_init_rgmii_delays(struct meson8b_dwmac *dwmac)
There are two problems with meson8b_devm_clk_prepare_enable(), introduced in a54dc4a49045 (net: stmmac: dwmac-meson8b: Make the clock enabling code re-usable): - It doesn't pass the clk argument, but instead always the rgmii_tx_clk of the device. - It silently ignores the return value of devm_add_action_or_reset(). The former didn't become an actual bug until another user showed up in the next commit, 9308c47640d5 (net: stmmac: dwmac-meson8b: add support for the RX delay configuration). The latter means the callers could end up with the clock not actually prepared/enabled. Fixes: a54dc4a49045 (net: stmmac: dwmac-meson8b: Make the clock enabling code re-usable) Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk> --- Not tested in any way, just stumbled on this which didn't seem right. It seems that the timing_adj_clk could be changed (with a bit of refactoring) to use devm_clk_get_enabled() - i.e. don't make it optional, but only get/prepare/enable it in the (delay_config & PRG_ETH0_ADJ_ENABLE) branch where the code actually requires it. But since there's no official devm_clk_prepare_enable, and the rgmii_tx_clk isn't obtained via a clk_get, I don't see a simple way to avoid this private implmentation of devm_clk_prepare_enable(). drivers/net/ethernet/stmicro/stmmac/dwmac-meson8b.c | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-)