linux-kernel - Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH

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: <c27a2359-ee55-4d20-907d-314eee30ed4f@lunn.ch>
Date: Mon, 21 Apr 2025 17:11:33 +0200
From: Andrew Lunn <andrew@...n.ch>
To: Biju Das <biju.das.jz@...renesas.com>
Cc: "Lad, Prabhakar" <prabhakar.csengg@...il.com>,
	"Russell King (Oracle)" <linux@...linux.org.uk>,
	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>,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Maxime Coquelin <mcoquelin.stm32@...il.com>,
	Alexandre Torgue <alexandre.torgue@...s.st.com>,
	Richard Cochran <richardcochran@...il.com>,
	Philipp Zabel <p.zabel@...gutronix.de>,
	Geert Uytterhoeven <geert+renesas@...der.be>,
	Magnus Damm <magnus.damm@...il.com>,
	Giuseppe Cavallaro <peppe.cavallaro@...com>,
	Jose Abreu <joabreu@...opsys.com>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-stm32@...md-mailman.stormreply.com" <linux-stm32@...md-mailman.stormreply.com>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"linux-renesas-soc@...r.kernel.org" <linux-renesas-soc@...r.kernel.org>,
	Fabrizio Castro <fabrizio.castro.jz@...esas.com>,
	Prabhakar Mahadev Lad <prabhakar.mahadev-lad.rj@...renesas.com>
Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for
 Renesas GBETH

On Mon, Apr 21, 2025 at 02:22:01PM +0000, Biju Das wrote:
> Hi Andrew,
> 
> > -----Original Message-----
> > From: Andrew Lunn <andrew@...n.ch>
> > Sent: 21 April 2025 15:02
> > Subject: Re: [PATCH net-next v5 3/3] net: stmmac: Add DWMAC glue layer for Renesas GBETH
> > 
> > > > On the RZ/G3E, the upstream support for testing S2R is not yet in a
> > > > usable state. So for now, I'll switch to using init/exit callbacks and drop the PM callback.
> > >
> > > FYI, On RZ/G3E, for STR to work with mainline, we need to reinitialize the PHY.
> > > I have done below changes on top of [1] to make STR working.
> > 
> > Can you explain why you need to reinitialise the PHY? The MAC driver should not need to do this, so
> > something is wrong somewhere. If we understand the 'Why?' we can probably tell you a better way to do
> > this.
> 
> Without this change bind/unbind works. But for the STR case, without reinitializing the PHY, even though
> the IP link is UP, I am not able to talk the NFS server or ping the host properly.
> 
> I checked clock/reset before and after reset everything set as expected.
> 
> Only change during STR is, on wakeup we need to restore direction (MII/RGMII) of IO block 
> for ET0/1_TXC_TXCLK (IO attribute) in the pin control driver. After that looks like PHY init
> is required to talk to server. 

When talking about suspend/resume, is this with or without WoL?

If WoL is enabled for the PHY, the PHY is left running while the
system is suspended, and so all its clocks and reset lines also need
to be left enabled etc. On resume, there should not be any need to
touch the PHY.

If WoL is not enabled in the PHY, it should get powered off. On
resume, phylib should be reinitializing the PHY.

Which of these two cases need the reinitialisation?

The reasons i can think of for the PHY needing a reinitialization are:

1) It lost power when it did not expect to loose power
2) Got reset when it did not expect to be reset
3) Clock not ticking when it should of been ticking.

So you cannot just check clock/reset before and after, you need to
look at the order of events. The loss of power, or a reset after
phylib resumed the PHY would not be good. Similarly, if the needed
clocks are not ticking while phylib resumes it would also not be good.

I would also suggest you check the datasheet for the PHY, and does it
document anything about the clock input TXC_TXCLK is connected to?
Does it need to be ticking while configuring the PHY? Any action which
needs to be taken after this starts ticking? Is the pinctrl resume
being called before the PHY resume?

	Andrew