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

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aJDeZJrKkqH23V/V@x1>
Date: Mon, 4 Aug 2025 09:23:00 -0700
From: Drew Fustini <fustini@...nel.org>
To: Yao Zi <ziyao@...root.org>
Cc: Rob Herring <robh@...nel.org>, Guo Ren <guoren@...nel.org>,
	Fu Wei <wefu@...hat.com>, Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Paul Walmsley <paul.walmsley@...ive.com>,
	Palmer Dabbelt <palmer@...belt.com>,
	Albert Ou <aou@...s.berkeley.edu>, Alexandre Ghiti <alex@...ti.fr>,
	Emil Renner Berthing <emil.renner.berthing@...onical.com>,
	Jisheng Zhang <jszhang@...nel.org>, linux-riscv@...ts.infradead.org,
	netdev@...r.kernel.org, devicetree@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH net v2 2/3] net: stmmac: thead: Get and enable APB clock
 on initialization

On Mon, Aug 04, 2025 at 05:12:26AM +0000, Yao Zi wrote:
> 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:
> > > 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 <ziyao@...root.org>
> > > Reviewed-by: Drew Fustini <fustini@...nel.org>
> > > Tested-by: Drew Fustini <fustini@...nel.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.

I've just read Conor's comment in the v1 again: 

 Nah, introduce the warnings. If the clock is required for operation, it
 should be marked as such. You've made it optional in the driver, which
 is the important part (backwards compatible) and you've got the dts
 patch in the series.

Thus I think the argument I made in my reply to this thread is
incorrect and the driver should remain backwards compatible.

> 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.

I think a comment in the code about why it uses the optional variant of
the function is a good idea.

Thanks,
Drew