[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Z4UVQRHqk8ND984c@shell.armlinux.org.uk>
Date: Mon, 13 Jan 2025 13:29:37 +0000
From: "Russell King (Oracle)" <linux@...linux.org.uk>
To: Oleksij Rempel <o.rempel@...gutronix.de>
Cc: Andrew Lunn <andrew@...n.ch>, "David S. Miller" <davem@...emloft.net>,
Eric Dumazet <edumazet@...gle.com>,
Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
Woojung Huh <woojung.huh@...rochip.com>,
Andrew Lunn <andrew+netdev@...n.ch>, kernel@...gutronix.de,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
UNGLinuxDriver@...rochip.com, Phil Elwell <phil@...pberrypi.org>
Subject: Re: [PATCH net-next v1 7/7] net: usb: lan78xx: Enable EEE support
with phylink integration
On Mon, Jan 13, 2025 at 01:42:06PM +0100, Oleksij Rempel wrote:
> On Thu, Jan 09, 2025 at 08:33:07PM +0100, Andrew Lunn wrote:
> > > Andrew had a large patch set, which added the phylib core code, and
> > > fixed up many drivers. This was taken by someone else, and only
> > > Andrew's core phylib code was merged along with the code for their
> > > driver, thus breaking a heck of a lot of other drivers.
> >
> > As Russell says, i did convert all existing drivers over the new
> > internal API, and removed some ugly parts of the old EEE core code.
> > I'm not too happy we only got part way with my patches. Having this in
> > between state makes the internal APIs much harder to deal with, and as
> > Russell says, we broke a few MAC drivers because the rest did not get
> > merged.
> >
> > Before we think about extensions to the kAPI, we first need to finish
> > the refactor. Get all MAC drivers over to the newer internal API and
> > remove phy_init_eee() which really does need to die. My patches have
> > probably bit rotted a bit, but i doubt they are unusable. So i would
> > like to see them merged. I would however leave phylink drivers to
> > Russell. He went a slight different way than i did, and he should get
> > to decide how phylink should support this.
>
> Hi Andrew,
>
> Ok. If I see it correctly, all patches from the
> v6.4-rc6-net-next-ethtool-eee-v7 branch, which I was working on, have been
> merged by now. The missing parts are patches from the
> v6.3-rc3-net-next-ethtool-eee-v5 branch.
>
> More precisely, the following non-phylink drivers still need to be addressed:
> drivers/net/ethernet/broadcom/asp2
> drivers/net/ethernet/broadcom/genet
> drivers/net/ethernet/samsung/sxgbe
> drivers/net/usb/lan78xx - this one is in progress
>
> Unfortunately, I won’t be able to accomplish this before the merge window, as I
> am currently on sick leave. However, I promise to take care of it as soon as
> possible.
Does any of this include mvneta?
static int mvneta_ethtool_get_eee(struct net_device *dev,
struct ethtool_keee *eee)
{
struct mvneta_port *pp = netdev_priv(dev);
u32 lpi_ctl0;
lpi_ctl0 = mvreg_read(pp, MVNETA_LPI_CTRL_0);
eee->eee_enabled = pp->eee_enabled;
eee->eee_active = pp->eee_active;
eee->tx_lpi_enabled = pp->tx_lpi_enabled;
eee->tx_lpi_timer = (lpi_ctl0) >> 8; // * scale;
return phylink_ethtool_get_eee(pp->phylink, eee);
}
Any driver that writes any members of struct ethtool_keee before
calling phylink_ethtool_get_eee() or phy_ethtool_get_eee() was
broken by the merging of phylib-managed EEE. I've been submitting
patches to fix these over time, such as my recently merged DSA
patches that remove the now useless get_mac_eee() method.
The biggest problem is that phylib overwrites eee->tx_lpi_timer,
which broke a lot of drivers. For example, I've fixed FEC:
3fa2540d93d8 net: fec: use phydev->eee_cfg.tx_lpi_timer
Anyway, I'm going to re-post a cut-down version of my phylink-
managed EEE support once Herner's EEE patch set has been merged.
This will convert mvneta, lan743x and stmmac, and add support for
mvpp2, thus resolving the breakage in at last some of those drivers..
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!
Powered by blists - more mailing lists