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:
 <TY3PR01MB1134652607E0CB04ED520EDFF86B82@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Mon, 21 Apr 2025 17:25:36 +0000
From: Biju Das <biju.das.jz@...renesas.com>
To: Andrew Lunn <andrew@...n.ch>
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

Hi Andrew,

> -----Original Message-----
> From: Andrew Lunn <andrew@...n.ch>
> Sent: 21 April 2025 16:12
> 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?

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.

OK.

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

OK.

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

OK.

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

It is connected to TX_CTL on micrel phy.

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

Pinctrl resume is called before PHY resume

Previously STR did not work, because of not restoring direction (MII/RGMII) of IO block for ET0/1_TXC_TXCLK (IO attribute)
.Because of this, the direction of IO block is set to IN (input) MII mode instead of OUT(output) RGMII mode.

Now everything works. Thanks for your detailed pointers.

Cheers,
Biju