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

Message-ID: <Y+9oDrTXCX6xVKSl@shell.armlinux.org.uk>
Date:   Fri, 17 Feb 2023 11:42:06 +0000
From:   "Russell King (Oracle)" <linux@...linux.org.uk>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     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 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.
> 
> This patchset changes the API, such that EEE becomes the same as other
> parameters which are determined by auto-neg. As will speed and duplex,
> active EEE is now indicated in the phydev structure, and the
> adjust_link callbacks have been modified to act upon its value.
> 
> eee_set and eee_get have been simplified, given that the phylib
> functions act upon most of the data in eee_set, and fill in most of
> the information needed for eee_set.

This is a very nice cleanup, and removes a bunch of logic from MAC
drivers into the phylib core code that should result in more
uniform behaviour across MAC drivers for this feature. Great!

I'm left wondering about the phylink using drivers, whether we could
go a little further, because there's also the tx_lpi_enabled flag
which should also gate whether EEE is enabled at the MAC - and
whether that logic could be handled entirely within phylink too.
That would mean instead of mac_link_up() being passed the phydev
(and EEE is the reason the phydev is passed) we could instead just
pass an "eee" flag to tell the MAC to program itself appropriately.
Then, the only thing which MAC drivers need to concern themselves
with is setting the TX LPI timer to the appropriate value (which
may need to happen in mac_link_up()).

However, for this series, it's definitely a much needed improvement!

Thanks!

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