netdev - Re: [net-next PATCH v3 03/11] net: pcs: Add subsystem

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: <20250418094735.GA2676982@horms.kernel.org>
Date: Fri, 18 Apr 2025 10:47:35 +0100
From: Simon Horman <horms@...nel.org>
To: Sean Anderson <sean.anderson@...ux.dev>
Cc: netdev@...r.kernel.org, Andrew Lunn <andrew+netdev@...n.ch>,
	"David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>,
	Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
	Russell King <linux@...linux.org.uk>, upstream@...oha.com,
	Christian Marangi <ansuelsmth@...il.com>,
	linux-kernel@...r.kernel.org,
	Kory Maincent <kory.maincent@...tlin.com>,
	Heiner Kallweit <hkallweit1@...il.com>,
	Jonathan Corbet <corbet@....net>, linux-doc@...r.kernel.org
Subject: Re: [net-next PATCH v3 03/11] net: pcs: Add subsystem

On Thu, Apr 17, 2025 at 11:05:24AM -0400, Sean Anderson wrote:
> On 4/17/25 05:19, Simon Horman wrote:
> > On Tue, Apr 15, 2025 at 03:33:15PM -0400, Sean Anderson wrote:
> >> This adds support for getting PCS devices from the device tree. PCS
> >> drivers must first register with phylink_register_pcs. After that, MAC
> >> drivers may look up their PCS using phylink_get_pcs.
> >> 
> >> We wrap registered PCSs in another PCS. This wrapper PCS is refcounted
> >> and can outlive the wrapped PCS (such as if the wrapped PCS's driver is
> >> unbound). The wrapper forwards all PCS callbacks to the wrapped PCS,
> >> first checking to make sure the wrapped PCS still exists. This design
> >> was inspired by Bartosz Golaszewski's talk at LPC [1].
> >> 
> >> pcs_get_by_fwnode_compat is a bit hairy, but it's necessary for
> >> compatibility with existing drivers, which often attach to (devicetree)
> >> nodes directly. We use the devicetree changeset system instead of
> >> adding a (secondary) software node because mdio_bus_match calls
> >> of_driver_match_device to match devices, and that function only works on
> >> devicetree nodes.
> >> 
> >> [1] https://lpc.events/event/17/contributions/1627/
> >> 
> >> Signed-off-by: Sean Anderson <sean.anderson@...ux.dev>
> > 
> > Hi Sean,
> > 
> > I noticed a few build problems after sending my previous email.
> > 
> > I was able to exercise them using variants of the following to
> > generate small configs. I include this here in case it is useful to you.
> > 
> > make tinyconfig
> > 
> > cat >> .config << __EOF__
> > CONFIG_MODULES=y
> > CONFIG_NET=y
> > CONFIG_NETDEVICES=y
> > CONFIG_PCS=y
> > CONFIG_PHYLIB=m
> > __EOF__
> > 
> > cat >> .config << __EOF__
> > CONFIG_OF=y
> > CONFIG_OF_UNITTEST=y
> > CONFIG_OF_DYNAMIC=y
> > __EOF__
> > 
> > yes "" | make oldconfig
> > 
> > ...
> > 
> >> diff --git a/drivers/net/pcs/core.c b/drivers/net/pcs/core.c
> > 
> > ...
> 
> Thanks, I was able to reproduce/fix these issues.
> 
> How did you find these? By inspection?
> 
> I often end up missing build issues like this because I mostly
> test with everything enabled.

Hi Sean,

The issue regarding fwnode_mdio_find_device and PHYLIB as a module
came up with an automated allmodconfig W=1 build.

I came across the other issue, regarding CONFIG_OF_DYNAMIC, while
investigating the PHYLIB issue.  Basically running allmodconfig takes ages
on my development machine.  So I wanted to try coming up with a small
config, based on tinyconfig, that would reproduce the PHYLIB issue. And on
the way there - as you can see artifacts of in the configuration commands
above - I hit the CONFIG_OF_DYNAMIC issue.

My take on this is that it's good to test allmodconfig, although the build
can take ages. Especially if there is any risk of link failures. And, as
for other cases, perhaps there are standard ones that are worth exercising,
like with/without IPv6 support (probably not relevant to this patchset).
But otherwise I think we get down to waiting for the bots (or someone on
the ML) to happen to come across a broken (random?) configuration.

...