netdev - Re: [PATCH RFC 00/18] Rework MAC drivers EEE support

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] [day] [month] [year] [list]

Message-ID: <20230218122529.GC9065@pengutronix.de>
Date:   Sat, 18 Feb 2023 13:25:29 +0100
From:   Oleksij Rempel <o.rempel@...gutronix.de>
To:     "Russell King (Oracle)" <linux@...linux.org.uk>
Cc:     Andrew Lunn <andrew@...n.ch>, netdev <netdev@...r.kernel.org>,
        Florian Fainelli <f.fainelli@...il.com>,
        Vladimir Oltean <vladimir.oltean@....com>,
        Sean Wang <sean.wang@...iatek.com>,
        Landen Chao <Landen.Chao@...iatek.com>,
        DENG Qingfang <dqfext@...il.com>,
        Matthias Brugger <matthias.bgg@...il.com>,
        AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        Doug Berger <opendmb@...il.com>,
        Broadcom internal kernel review list 
        <bcm-kernel-feedback-list@...adcom.com>,
        Wei Fang <wei.fang@....com>,
        Shenwei Wang <shenwei.wang@....com>,
        Clark Wang <xiaoning.wang@....com>,
        NXP Linux Team <linux-imx@....com>,
        UNGLinuxDriver@...rochip.com, Byungho An <bh74.an@...sung.com>,
        Giuseppe Cavallaro <peppe.cavallaro@...com>,
        Alexandre Torgue <alexandre.torgue@...s.st.com>,
        Jose Abreu <joabreu@...opsys.com>,
        Maxime Coquelin <mcoquelin.stm32@...il.com>,
        Heiner Kallweit <hkallweit1@...il.com>,
        Woojung Huh <woojung.huh@...rochip.com>,
        Oleksij Rempel <linux@...pel-privat.de>
Subject: Re: [PATCH RFC 00/18] Rework MAC drivers EEE support

On Fri, Feb 17, 2023 at 02:25:57PM +0000, Russell King (Oracle) wrote:
> On Fri, Feb 17, 2023 at 04:42:12AM +0100, Andrew Lunn wrote:
> > phy_init_eee() is supposed to be called once auto-neg has been
> > completed to determine if EEE should be used with the current link
> > mode. The MAC hardware should then be configured to either enable or
> > disable EEE. Many drivers get this wrong, calling phy_init_eee() once,
> > or only in the ethtool set_eee callback.
> 
> Looking at some of the recent EEE changes (not related to this patch
> set) I've come across:
> 
> commit 9b01c885be364526d8c05794f8358b3e563b7ff8
> Author: Oleksij Rempel <linux@...pel-privat.de>
> Date:   Sat Feb 11 08:41:10 2023 +0100
> 
>     net: phy: c22: migrate to genphy_c45_write_eee_adv()
> 
> This part of the patch is wrong:
> 
> __genphy_config_aneg():
> -       if (genphy_config_eee_advert(phydev))
> +       err = genphy_c45_write_eee_adv(phydev, phydev->supported_eee);
> 
> The problem here is that these are not equivalent.
> 
> genphy_config_eee_advert() only clears the broken EEE modes in the
> advertisement, it doesn't actually set the advertisement to anything
> in particular.
> 
> The replacement code _configures_ the advertisement to whatever the
> second argument is, which means each time the advertisement is
> changed (and thus __genphy_config_aneg() is called) the EEE
> advertisement will ignore whatever the user configured via the
> set_eee() APIs, and be restored to the full EEE capabilities in the
> supported mask.
> 
> This is an obvious regression that needs fixing, especially as the
> merge window is potentially due to open this weekend.

You are right :(

I'll be able to come with a fix this Monday.

Regards,
Oleksij
-- 
Pengutronix e.K.                           |                             |
Steuerwalder Str. 21                       | http://www.pengutronix.de/  |
31137 Hildesheim, Germany                  | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |