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]
Date:   Wed, 9 Aug 2023 18:21:58 +0200
From:   Andrew Lunn <andrew@...n.ch>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Ioana Ciornei <ioana.ciornei@....com>,
        Florian Fainelli <f.fainelli@...il.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Uwe Kleine-K├Ânig 
        <u.kleine-koenig@...gutronix.de>,
        Ioana Ciornei <ciorneiioana@...il.com>, netdev@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Alexandru Ardelean <alexandru.ardelean@...log.com>,
        Andre Edich <andre.edich@...rochip.com>,
        Antoine Tenart <atenart@...nel.org>,
        Baruch Siach <baruch@...s.co.il>,
        Christophe Leroy <christophe.leroy@....fr>,
        Divya Koppera <Divya.Koppera@...rochip.com>,
        Hauke Mehrtens <hauke@...ke-m.de>,
        Jerome Brunet <jbrunet@...libre.com>,
        Kavya Sree Kotagiri <kavyasree.kotagiri@...rochip.com>,
        Linus Walleij <linus.walleij@...aro.org>,
        Marco Felsch <m.felsch@...gutronix.de>,
        Marek Vasut <marex@...x.de>,
        Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
        Mathias Kresin <dev@...sin.me>,
        Maxim Kochetkov <fido_max@...ox.ru>,
        Michael Walle <michael@...le.cc>,
        Neil Armstrong <narmstrong@...libre.com>,
        Nisar Sayed <Nisar.Sayed@...rochip.com>,
        Oleksij Rempel <o.rempel@...gutronix.de>,
        Philippe Schenker <philippe.schenker@...adex.com>,
        Willy Liu <willy.liu@...ltek.com>,
        Yuiko Oshino <yuiko.oshino@...rochip.com>
Subject: Re: [PATCH] net: phy: Don't disable irqs on shutdown if WoL is
 enabled

> Thinking about this, I wonder whether we could solve your issue by
> disabling interrupts when the PHY is probed, rather than disabling
> them on shutdown - something like this? (not build tested)
> 
> diff --git a/drivers/net/phy/phy_device.c b/drivers/net/phy/phy_device.c
> index 3e9909b30938..4d1a37487923 100644
> --- a/drivers/net/phy/phy_device.c
> +++ b/drivers/net/phy/phy_device.c
> @@ -3216,6 +3216,8 @@ static int phy_probe(struct device *dev)
>  			goto out;
>  	}
>  
> +        phy_disable_interrupts(phydev);
> +
>  	/* Start out supporting everything. Eventually,
>  	 * a controller will attach, and may modify one
>  	 * or both of these values

At some point, the interrupt is going to be enabled again. And then
the WoL interrupt will fire. I think some PHY drivers actually need to
see that WoL interrupt. e.g. the marvell driver has this comment:

static int m88e1318_set_wol(struct phy_device *phydev,
                            struct ethtool_wolinfo *wol)
{
....
                /* If WOL event happened once, the LED[2] interrupt pin
                 * will not be cleared unless we reading the interrupt status
                 * register. If interrupts are in use, the normal interrupt
                 * handling will clear the WOL event. Clear the WOL event
                 * before enabling it if !phy_interrupt_is_valid()
                 */

So it seems like just probing the marvell PHY is not enough to clear
the WoL interrupt.

Can we be sure that the other PHY has reached a state it can handle
and clear an interrupt when we come to enable the interrupt? I think
not, especially in cases like NFS root, where the interface will be
put into use as soon as it exists, maybe before the other interface
has probed.

	Andrew

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ