[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<TY3PR01MB113466ADD365C6C569923F9A486B82@TY3PR01MB11346.jpnprd01.prod.outlook.com>
Date: Mon, 21 Apr 2025 17:50:25 +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: Biju Das
> Sent: 21 April 2025 18:26
> 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.
I need to debug this issue further as without reinitializing the PHY, the STR wakeup is not stable
(Linkup, but not able to contact the server).
[ 34.572232] dwmac4: Master AXI performs fixed burst length
[ 34.572232] renesas-gbeth 15c30000.ethernet eth0: No Safety Features support found
[ 34.572232] renesas-gbeth 15c30000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported
[ 34.572232] renesas-gbeth 15c30000.ethernet eth0: configuring for phy/rgmii-id link mode
[ 34.572232] OOM killer enabled.
[ 34.572232] Restarting tasks ... done.
[ 34.572232] random: crng reseeded on system resumption
[ 34.572232] PM: suspend exit
root@...rc-rzg3e:~#
root@...rc-rzg3e:~# ls
[ 34.572232] renesas-gbeth 15c30000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
root@...rc-rzg3e:~# [ 34.572232] mmc2: Skipping voltage switch
root@...rc-rzg3e:~#
root@...rc-rzg3e:~#
root@...rc-rzg3e:~# ping 192.168.10.1
[ 34.572232] nfs: server 192.168.10.1 not responding, still trying
Cheers,
Biju
Powered by blists - more mailing lists