netdev - Re: [PATCH net-next 3/3] net: fec: reset phy on resume after power-up

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: <Ybjr1isMQBXfoo0S@shell.armlinux.org.uk>
Date:   Tue, 14 Dec 2021 19:09:10 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     Philippe Schenker <philippe.schenker@...adex.com>,
        netdev@...r.kernel.org, Joakim Zhang <qiangqing.zhang@....com>,
        "David S . Miller" <davem@...emloft.net>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Francesco Dolcini <francesco.dolcini@...adex.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Fabio Estevam <festevam@...il.com>,
        Fugang Duan <fugang.duan@....com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next 3/3] net: fec: reset phy on resume after power-up

On Tue, Dec 14, 2021 at 07:54:54PM +0100, Andrew Lunn wrote:
> On Tue, Dec 14, 2021 at 01:16:38PM +0100, Philippe Schenker wrote:
> > Reset the eth PHY after resume in case the power was switched off
> > during suspend, this is required by some PHYs if the reset signal
> > is controlled by software.
> > 
> > Signed-off-by: Philippe Schenker <philippe.schenker@...adex.com>
> > 
> > ---
> > 
> >  drivers/net/ethernet/freescale/fec_main.c | 1 +
> 
> Hi Philippe
> 
> What i don't particularly like about this is that the MAC driver is
> doing it. Meaning if this PHY is used with any other MAC, the same
> code needs adding there.
> 
> Is there a way we can put this into phylib? Maybe as part of
> phy_init_hw()? Humm, actually, thinking aloud:
> 
> int phy_init_hw(struct phy_device *phydev)
> {
> 	int ret = 0;
> 
> 	/* Deassert the reset signal */
> 	phy_device_reset(phydev, 0);
> 
> So maybe in the phy driver, add a suspend handler, which asserts the
> reset. This call here will take it out of reset, so applying the reset
> you need?

It seems to be a combination issue - it's the fact that the power is
turned off and the fact that the reset needs to be applied.

If other PHYs such as AR8035 are subjected to this, they appear to
have a requirement that reset is asserted when power is applied and
kept asserted until the clock has stabilised and a certain time has
elapsed.

As I've already highlighted, we do not want to be asserting the reset
signal in phy_init_hw() - doing so would mean that any PHY with a GPIO
reset gets reset whenever the PHY is connected to the MAC - which can
be whenever the interface is brought up. That will introduce a multi-
second delay to bringing up the network.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!