Re: [PATCH net v2 2/3] net: stmmac: thead: Get and enable APB clock on initialization

On Sun, Aug 03, 2025 at 12:02:06PM -0500, Rob Herring wrote:

On Fri, Aug 01, 2025 at 09:12:39AM +0000, Yao Zi wrote:

quoted

It's necessary to adjust the MAC TX clock when the linkspeed changes,
but it's noted such adjustment always fails on TH1520 SoC, and reading
back from APB glue registers that control clock generation results in
garbage, causing broken link.

With some testing, it's found a clock must be ungated for access to APB
glue registers. Without any consumer, the clock is automatically
disabled during late kernel startup. Let's get and enable it if it's
described in devicetree.

Fixes: 33a1a01e3afa ("net: stmmac: Add glue layer for T-HEAD TH1520 SoC")
Signed-off-by: Yao Zi <redacted>
Reviewed-by: Drew Fustini <fustini@kernel.org>
Tested-by: Drew Fustini <fustini@kernel.org>
---
 drivers/net/ethernet/stmicro/stmmac/dwmac-thead.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac-thead.c b/drivers/net/ethernet/stmicro/stmmac/dwmac-thead.c
index c72ee759aae5..95096244a846 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac-thead.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac-thead.c

@@ -211,6 +211,7 @@ static int thead_dwmac_probe(struct platform_device *pdev)
 	struct stmmac_resources stmmac_res;
 	struct plat_stmmacenet_data *plat;
 	struct thead_dwmac *dwmac;
+	struct clk *apb_clk;
 	void __iomem *apb;
 	int ret;
 

@@ -224,6 +225,11 @@ static int thead_dwmac_probe(struct platform_device *pdev)
 		return dev_err_probe(&pdev->dev, PTR_ERR(plat),
 				     "dt configuration failed\n");
 
+	apb_clk = devm_clk_get_optional_enabled(&pdev->dev, "apb");

The description sounds like this should not be optional. The binding 
change also makes it not optional.

Yes, it shouldn't be. But using the non-optional API will cause the
driver fails to probe with the old (problematic) devicetree, IOW, it
breaks the ABI. Comparing to unusable ethernet, failing to adjust the
link speed sounds a minor point to me.

Maybe we could add a comment to explain why optional API is used, or
just use the non-optional one if such ABI breakages are acceptable --
for which I'd like to wait for more opinions.

Rob

Thanks,
Yao Zi