netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Simon Horman <horms@kernel.org>
To: Sean Anderson <sean.anderson@linux.dev>
Cc: netdev@vger.kernel.org, Andrew Lunn <andrew+netdev@lunn.ch>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Russell King <linux@armlinux.org.uk>,
	upstream@airoha.com, Christian Marangi <ansuelsmth@gmail.com>,
	linux-kernel@vger.kernel.org,
	Kory Maincent <kory.maincent@bootlin.com>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Jonathan Corbet <corbet@lwn.net>,
	linux-doc@vger.kernel.org
Subject: Re: [net-next PATCH v3 03/11] net: pcs: Add subsystem
Date: Fri, 18 Apr 2025 10:47:35 +0100	[thread overview]
Message-ID: <20250418094735.GA2676982@horms.kernel.org> (raw)
In-Reply-To: <0bd8a9c0-4824-4c1f-bf32-ac1e57e2bea0@linux.dev>

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@linux.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.

...

  reply	other threads:[~2025-04-18  9:47 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-04-15 19:33 [net-next PATCH v3 00/11] Add PCS core support Sean Anderson
2025-04-15 19:33 ` [net-next PATCH v3 01/11] dt-bindings: net: Add Xilinx PCS Sean Anderson
2025-04-15 19:33 ` [net-next PATCH v3 02/11] net: phylink: Support setting PCS link change callbacks Sean Anderson
2025-04-15 19:33 ` [net-next PATCH v3 03/11] net: pcs: Add subsystem Sean Anderson
2025-04-15 20:02   ` Sean Anderson
2025-04-17  8:35   ` Simon Horman
2025-04-17 14:56     ` Sean Anderson
2025-04-17  9:19   ` Simon Horman
2025-04-17 15:05     ` Sean Anderson
2025-04-18  9:47       ` Simon Horman [this message]
2025-04-15 19:33 ` [net-next PATCH v3 04/11] net: dsa: ocelot: suppress PHY device scanning on the internal MDIO bus Sean Anderson
2025-04-15 19:33 ` [net-next PATCH v3 05/11] net: pcs: lynx: Convert to an MDIO driver Sean Anderson
2025-05-06 21:58   ` Vladimir Oltean
2025-05-06 22:03     ` Sean Anderson
2025-05-06 22:18       ` Vladimir Oltean
2025-05-06 22:20         ` Sean Anderson
2025-05-06 22:29           ` Vladimir Oltean
2025-05-06 22:39             ` Sean Anderson
2025-05-07  0:19               ` Andrew Lunn
2025-05-08 15:57                 ` Sean Anderson
2025-05-07 15:04               ` Vladimir Oltean
2025-05-06 23:56         ` Daniel Golle
2025-05-07 14:02           ` Vladimir Oltean
2025-04-15 19:33 ` [net-next PATCH v3 06/11] net: phy: Export some functions Sean Anderson
2025-04-15 19:33 ` [net-next PATCH v3 07/11] net: pcs: Add Xilinx PCS driver Sean Anderson
2025-04-15 19:33 ` [net-next PATCH v3 08/11] net: axienet: Convert to use PCS subsystem Sean Anderson
2025-04-18  9:04   ` Gupta, Suraj
2025-04-15 19:33 ` [net-next PATCH v3 09/11] net: macb: Move most of mac_config to mac_prepare Sean Anderson
2025-04-15 19:35 ` [net-next PATCH v3 10/11] net: macb: Support external PCSs Sean Anderson
2025-04-15 19:35   ` [net-next PATCH v3 11/11] of: property: Add device link support for PCS Sean Anderson
2025-04-17 12:25 ` [net-next PATCH v3 00/11] Add PCS core support Russell King (Oracle)
2025-04-17 14:22   ` Sean Anderson
2025-04-17 15:24     ` Russell King (Oracle)
2025-04-17 15:29       ` Sean Anderson
2025-05-02 17:41         ` Sean Anderson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20250418094735.GA2676982@horms.kernel.org \
    --to=horms@kernel.org \
    --cc=andrew+netdev@lunn.ch \
    --cc=ansuelsmth@gmail.com \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=kory.maincent@bootlin.com \
    --cc=kuba@kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=sean.anderson@linux.dev \
    --cc=upstream@airoha.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).