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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250108094728.077d7bc9@kernel.org>
Date: Wed, 8 Jan 2025 09:47:28 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Maxime Chevallier <maxime.chevallier@...tlin.com>
Cc: Andrew Lunn <andrew@...n.ch>, Oleksij Rempel <o.rempel@...gutronix.de>,
 "David S. Miller" <davem@...emloft.net>, Eric Dumazet
 <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>, Andrew Lunn
 <andrew+netdev@...n.ch>, Heiner Kallweit <hkallweit1@...il.com>, Jonathan
 Corbet <corbet@....net>, kernel@...gutronix.de,
 linux-kernel@...r.kernel.org, netdev@...r.kernel.org, Simon Horman
 <horms@...nel.org>, Russell King <linux@...linux.org.uk>,
 linux-doc@...r.kernel.org
Subject: Re: [PATCH net-next v5 2/8] net: ethtool: plumb PHY stats to PHY
 drivers

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?