Thread (15 messages) 15 messages, 4 authors, 2025-01-08

Re: [PATCH net-next v5 2/8] net: ethtool: plumb PHY stats to PHY drivers

flat view

From: Jakub Kicinski <kuba@kernel.org>
Date: 2025-01-08 17:47:30
Also in: linux-doc, lkml

On Wed, 8 Jan 2025 17:24:56 +0100 Maxime Chevallier wrote:
quoted
quoted
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?
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help