[EXT] Re: [PATCH 1/1] net: stmmac: start PHY early in __stmmac_open

[Shenwei Wang]

> -----Original Message-----
> From: Russell King <linux at armlinux.org.uk>
> Sent: Thursday, March 16, 2023 4:56 PM
> To: Shenwei Wang <shenwei.wang at nxp.com>
> Cc: David S. Miller <davem at davemloft.net>; Eric Dumazet
> <edumazet at google.com>; Jakub Kicinski <kuba at kernel.org>; Paolo Abeni
> <pabeni at redhat.com>; Maxime Coquelin <mcoquelin.stm32 at gmail.com>;
> Giuseppe Cavallaro <peppe.cavallaro at st.com>; Alexandre Torgue
> <alexandre.torgue at foss.st.com>; Jose Abreu <joabreu at synopsys.com>;
> netdev at vger.kernel.org; linux-stm32 at st-md-mailman.stormreply.com; linux-
> arm-kernel at lists.infradead.org; imx at lists.linux.dev
> Subject: [EXT] Re: [PATCH 1/1] net: stmmac: start PHY early in __stmmac_open
> 
> Caution: EXT Email
> 
> On Thu, Mar 16, 2023 at 03:54:49PM -0500, Shenwei Wang wrote:
> > By initializing the PHY and establishing the link before setting the
> > MAC relating configurations, this change ensures that the PHY is
> > operational before the MAC logic starts relying on it. This can
> > prevent synchronization errors and improve system stability.
> >
> > This change especially applies to the RMII mode, where the PHY may
> > drive the REF_CLK signal, which requires the PHY to be started and
> > operational before the MAC logic initializes.
> >
> > This change should not impact other modes of operation.
> 
> NAK. A patch similar to this has already been sent.
> 
> The problem with just moving this is that phylink can call the
> mac_link_up() method *before* phylink_start() has returned - and as this driver
> has not completed the setup, it doesn't expect the link to come up at that point.
> 

Okay. Will fix the issue in another way.

Thanks,
Shenwei

> There are several issues with this driver wanting the PHY clock early, and there
> have been two people working on addressing this previously, proposing two
> different changes to phylink.
> 
> I sent them away to talk to each other and come back with a unified solution.
> Shock horror, they never came back.
> 
> Now we seem to be starting again from the beginning.
> 
> stmmac folk really need to get a handle on this so reviewers are not having to
> NAK similar patches time and time again, resulting in the problem not being
> solved.
> 
> --
> RMK's Patch system:
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ar
> mlinux.org.uk%2Fdeveloper%2Fpatches%2F&data=05%7C01%7Cshenwei.wang
> %40nxp.com%7C23424b2776544630dbcc08db2669469c%7C686ea1d3bc2b4c6f
> a92cd99c5c301635%7C0%7C0%7C638146005820038948%7CUnknown%7CTWF
> pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6
> Mn0%3D%7C3000%7C%7C%7C&sdata=yLeW5tBxRpYK%2B%2FjbwaFqigzjWHRq
> m89FAE3Z%2BlVM4s0%3D&reserved=0
> FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!