On Wed, 8 Jan 2025 17:24:56 +0100 Maxime Chevallier wrote: > > > On one side I need to address the request to handle phydev specific > > > thing withing the PHYlib framework. On other side, I can't do it without > > > openen a pandora box of build dependencies. It will be a new main-side-quest > > > to resolve build dependency of net/ethtool/ and PHYlib. The workaround is to > > > put this functions to the header. > > > > Yes, the code is like this because phylib can be a module, and when it > > is, you would end up with unresolved symbols if ethtool code is built > > in. There are circular dependence as well, if both ethtool and phylib > > are module. The inlines help solve this. > > > > However, the number of these inline functions keeps growing. At some > > point, we might want a different solution. Maybe phylib needs to > > register a structure of ops with ethtool when it loads? > > Isn't it already the case with the ethtool_phy_ops singleton ? Maybe we > can add wrap the get_phy_stats / get_link_ext_stats ops to the > ethtool_phy_ops ? My understanding was that this singleton served this > purpose. Right, or for tiny pieces of code like this we could as well always build them in? Isn't drivers/net/phy/stubs.c already always built in?