All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Russell King (Oracle)" <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Kory Maincent <kory.maincent@bootlin.com>,
	Carlo Szelinsky <github@szelinsky.de>,
	o.rempel@pengutronix.de, andrew+netdev@lunn.ch,
	hkallweit1@gmail.com, kuba@kernel.org, davem@davemloft.net,
	edumazet@google.com, pabeni@redhat.com, horms@kernel.org,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration
Date: Thu, 9 Apr 2026 17:08:33 +0100	[thread overview]
Message-ID: <adfPAQDiYX6eIjrT@shell.armlinux.org.uk> (raw)
In-Reply-To: <908a84be-d403-4f59-8d8e-aa9de35bccbb@lunn.ch>

On Thu, Apr 09, 2026 at 05:34:56PM +0200, Andrew Lunn wrote:
> I still think we should be deferring probe until we have all the parts
> available. The question is, how do we actually do that?

Indeed...

> We could insist that MACs being used with PSE need to call
> phylink_connect() in probe, so we can return EPROBE_DEFER. We might
> actually need a new API method, phylink_connect_probe(). That can call
> down into phylib, maybe again new API methods, which will not bind
> genphy, but return EPROBE_DEFER.

How would MACs know whether they should call phylink_connect_probe()
or phylink_connect_phy() ?

What do we do about MAC drivers that are a single driver and device,
but are made up of several network devices (like Marvell PP2) ?

We also have network drivers that provide a MDIO bus for a different
network device, which makes connecting the PHY harder in the probe
path.

Lastly, what do we do where a PHY driver hasn't been configured or
doesn't exist for the PHY?

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 80Mbps down 10Mbps up. Decent connectivity at last!

  reply	other threads:[~2026-04-09 16:08 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-29 16:10 [PATCH 0/3] net: pse-pd: support module-based PSE controller drivers Carlo Szelinsky
2026-03-29 16:10 ` [PATCH 1/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration Carlo Szelinsky
2026-03-30 11:16   ` Kory Maincent
2026-03-29 16:10 ` [PATCH 2/3] net: pse-pd: prevent regulator cleanup from disabling unclaimed PSE PIs Carlo Szelinsky
2026-03-30 11:17   ` Kory Maincent
2026-03-29 16:10 ` [PATCH 3/3] net: pse-pd: add lazy PSE control resolution for modular drivers Carlo Szelinsky
2026-03-30 11:23   ` Kory Maincent
2026-03-30 11:09 ` [PATCH 0/3] net: pse-pd: support module-based PSE controller drivers Kory Maincent
2026-03-30 13:29 ` [PATCH net-next v2 " Carlo Szelinsky
2026-03-30 13:29   ` [PATCH net-next v2 1/3] net: pse-pd: prevent regulator cleanup from disabling unclaimed PSE PIs Carlo Szelinsky
2026-04-01  2:28     ` Jakub Kicinski
2026-04-06 10:22     ` Oleksij Rempel
2026-03-30 13:29   ` [PATCH net-next v2 2/3] net: pse-pd: add lazy PSE control resolution for modular drivers Carlo Szelinsky
2026-03-30 13:29   ` [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration Carlo Szelinsky
2026-03-30 14:11     ` Andrew Lunn
2026-04-03 13:31       ` Carlo Szelinsky
2026-04-03 13:38         ` Kory Maincent
2026-04-06  8:42           ` Oleksij Rempel
2026-04-07  9:31             ` Kory Maincent
2026-04-03 15:16         ` Andrew Lunn
2026-04-05 18:57           ` Carlo Szelinsky
2026-04-06  9:30             ` Oleksij Rempel
2026-04-06 12:22               ` Andrew Lunn
2026-04-06 14:12                 ` Oleksij Rempel
2026-04-07  9:40                   ` Kory Maincent
2026-04-06 12:42             ` Andrew Lunn
2026-04-06 14:43               ` Carlo Szelinsky
2026-04-06 15:21                 ` Andrew Lunn
2026-04-08 21:07                   ` Carlo Szelinsky
2026-04-08 21:56                     ` Andrew Lunn
2026-04-09 12:30                     ` Andrew Lunn
2026-04-09 13:09                       ` Kory Maincent
2026-04-09 15:34                         ` Andrew Lunn
2026-04-09 16:08                           ` Russell King (Oracle) [this message]
2026-04-09 19:54                             ` Andrew Lunn
2026-04-13  9:28                               ` Kory Maincent

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=adfPAQDiYX6eIjrT@shell.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=github@szelinsky.de \
    --cc=hkallweit1@gmail.com \
    --cc=horms@kernel.org \
    --cc=kory.maincent@bootlin.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=o.rempel@pengutronix.de \
    --cc=pabeni@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.