[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <80925b27-5302-4253-ad6d-221ba8bf45f4@lunn.ch>
Date: Thu, 9 Jan 2025 20:33:07 +0100
From: Andrew Lunn <andrew@...n.ch>
To: "Russell King (Oracle)" <linux@...linux.org.uk>
Cc: Oleksij Rempel <o.rempel@...gutronix.de>,
"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
> 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.
Andrew
Powered by blists - more mailing lists