Re: [PATCH v2 RFC 4/5] ethtool: add linkmode bitmap support to struct ethtool_keee
From: Andrew Lunn <andrew@lunn.ch>
Date: 2024-01-07 17:14:24
On Sat, Jan 06, 2024 at 11:21:31PM +0100, Heiner Kallweit wrote:
Add linkmode bitmap members to struct ethtool_keee, but keep the legacy u32 bitmaps for compatibility with existing drivers. Use link_modes.supported not being empty as indicator that a user wants to use the linkmode bitmap members instead of the legacy bitmaps.
So my fear is, the legacy code will never get cleaned up. How many MAC drivers are there which don't use phylib/phylink? Maybe i can help out converting them.
quoted hunk ↗ jump to hunk
+++ b/include/linux/ethtool.h@@ -223,6 +223,11 @@ __ethtool_get_link_ksettings(struct net_device *dev, struct ethtool_link_ksettings *link_ksettings); struct ethtool_keee { + struct { + __ETHTOOL_DECLARE_LINK_MODE_MASK(supported); + __ETHTOOL_DECLARE_LINK_MODE_MASK(advertising); + __ETHTOOL_DECLARE_LINK_MODE_MASK(lp_advertising); + } link_modes; u32 supported; u32 advertised; u32 lp_advertised;
I don't particularly like having the link_modes struct here. The end
goal should be that supported, advertised and lp_advertised become
link modes, and all the drivers are changed to use them.
Maybe we have one patch which does another global replace,
supported->supported_u32, advertised->advertised_32, etc, making space
for link mode symbols. phylib can directly use the new link modes so
there is no real change in that code. We can then convert the MAC
drivers not using phylib one by one, and then remove the _u32 members
at the end.
Andrew