Date: Thu, 10 Aug 2023 03:28:13 +0000
From: Wei Fang <wei.fang@....com>
To: Oleksij Rempel <o.rempel@...gutronix.de>
CC: Marek Vasut <marex@...x.de>, "netdev@...r.kernel.org"
	<netdev@...r.kernel.org>, "David S. Miller" <davem@...emloft.net>, Andrew
 Lunn <andrew@...n.ch>, Eric Dumazet <edumazet@...gle.com>, Heiner Kallweit
	<hkallweit1@...il.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
	<pabeni@...hat.com>, Russell King <linux@...linux.org.uk>,
	"kernel@...gutronix.de" <kernel@...gutronix.de>, "linux-clk@...r.kernel.org"
	<linux-clk@...r.kernel.org>, Stephen Boyd <sboyd@...nel.org>, Michael
 Turquette <mturquette@...libre.com>
Subject: RE: [PATCH] net: phy: at803x: Improve hibernation support on start up

> > Furthermore,
> > we would expect the hibernation mode is enabled when the ethernet
> > interface is brought up but the cable is not plugged, that is to say,
> > we only need the PHY to provide the clock for a while to make the MAC
> reset successfully.
> 
> Means, if external clock is not provided, MAC is not fully functional.
> Correct?
> 
The MAC will failed to do software reset if the PHY input clocks are not
present. According to the datasheet from Synopsys, the software reset
is for the MAC and the DMA controller reset the logic and all internal
registers of the DMA, MTL, and MAC.

One obvious error log can be seen from the console shows as follows.
[   26.670276] imx-dwmac 30bf0000.ethernet: Failed to reset the dma
[   26.676322] imx-dwmac 30bf0000.ethernet eth1: stmmac_hw_setup: DMA engine initialization failed
[   26.685103] imx-dwmac 30bf0000.ethernet eth1: __stmmac_open: Hw setup failed

I believe other manufacturers who use the dwmac IP also have encountered
the similar issue and use other methods to resolve it, such as intel,
49725ffc15fc ("net: stmmac: power up/down serdes in stmmac_open/release ")

> What kind of MAC operation will fail in this case?
Below are the steps from Marek to reproduce the issue.
- Make sure "qca,disable-hibernation-mode" is NOT present in PHY DT node
- Boot the machine with NO ethernet cable plugged into the affected port
   (i.e. the EQoS port), this is important
- Make sure the EQoS MAC is not brought up e.g. by systemd-networkd or
   whatever other tool, I use busybox initramfs for testing with plain
   script as init (it mounts the various filesystems and runs /bin/sh)
- Wait longer than 10 seconds
- If possible, measure AR8031 PHY pin 33 RX_CLK, wait for the RX_CLK to
   be turned OFF by the PHY (means PHY entered hibernation)
- ifconfig ethN up -- try to bring up the EQoS MAC <observe failure>

But the situation I encountered on i.MX8DXL-EVK platform was not as
complicated as above. At that time, it only took 3 steps to reproduce
this issue. But now, the latest upstream tree cannot reproduce this
issue based on the following three steps. Something has been changed,
I think it should be feafeb53140a (arm64: dts: imx8dxl-evk: Fix eqos phy reset gpio).
- unplug the cable
- ifconfig eth0 down and wait for about 10 seconds
- ifconfig eth0 up

> For example, if stmmac_open() fails without external clock, will
> stmmac_release() work properly?
Actually, I don't know much about stmmac driver and the dwmac IP,
Because I'm not responsible for this IP on NXP i.MX platform. But I
have a look at the code of stmmac_release(), I think stmmac_release()
will work properly, because it invokes phylink_stop() and phylink_disconnect_phy()
first which will disable the clock from PHY.

>Will we be able to do any configuration on
> an interface which is opened, but without active link and hibernated clock?
I don't know, but as far as I know, we can not set the VLAN filter successfully
due to lack of clock. So there may be other configurations that depend on the
clock.

> How about self tests?
> 
> > Therefore, I think
> > the current approach is more simple and effective, and it takes full
> > advantage of the characteristics of the hardware (The PHY will
> > continue to provide the clock about
> > 10 seconds after hibernation mode is enabled when the cable is not
> > plugged and automatically disable the clock after 10 seconds, so the
> > 10 seconds is enough for the MAC to reset successfully).
> 
> If multiple independent operations are synchronized based on the
> assumption that 10 seconds should be enough, bad thing happens.
> 
> If fully functional external clock provider is need to initialize the MAC, just
> disabling this clock on already initialized HW without doing proper
> re-initialization sequence is usually bad idea. HW may get some glitch which
> will make troubleshooting a pain.
> 

Powered by blists - more mailing lists