linux-kernel - [PATCH] net: stmmac: dwmac-meson8b: fix meson8b_devm_clk_prepare

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-Id: <20221104083004.2212520-1-linux@rasmusvillemoes.dk>
Date:   Fri,  4 Nov 2022 09:30:04 +0100
From:   Rasmus Villemoes <linux@...musvillemoes.dk>
To:     Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Andrew Lunn <andrew@...n.ch>,
        "David S . Miller" <davem@...emloft.net>
Cc:     netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
        Rasmus Villemoes <linux@...musvillemoes.dk>
Subject: [PATCH] net: stmmac: dwmac-meson8b: fix meson8b_devm_clk_prepare_enable()

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@...musvillemoes.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(-)

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)
-- 
2.37.2