public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Carlo Szelinsky <github@szelinsky.de>
To: Andrew Lunn <andrew@lunn.ch>, Oleksij Rempel <o.rempel@pengutronix.de>
Cc: Kory Maincent <kory.maincent@bootlin.com>,
	Andrew Lunn <andrew+netdev@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	Jakub Kicinski <kuba@kernel.org>,
	"David S . Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
	netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
	Carlo Szelinsky <github@szelinsky.de>
Subject: Re: [PATCH net-next v2 3/3] net: mdio: treat PSE EPROBE_DEFER as non-fatal during PHY registration
Date: Mon,  6 Apr 2026 16:43:24 +0200	[thread overview]
Message-ID: <20260406144324.4007913-1-github@szelinsky.de> (raw)
In-Reply-To: <3597433c-ce26-43c6-9a5f-e942a3db5340@lunn.ch>

Hi Andrew, Oleksij,

Thanks for pushing me in the right direction here.

So if I understand correctly, I should move the PSE control lookup
from fwnode_mdiobus_register_phy() into phy_probe(). That way the PHY
just defers like any other device if the PSE controller isn't there
yet, and the bus scan keeps going for the other PHYs.

I checked and bus_probe_device() is void, so device_add() won't fail
even if probe defers. And once the PSE module loads, the deferred
probe retry should kick in and claim the regulator before the 30s
cleanup runs. If the module never loads, the regulator cleanup is
actually the right thing to do safety-wise. So no need for the
admin_state_synced workaround or the lazy resolution stuff -
deferred probe just handles it.

Unlike lazy resolution, this also doesn't break notifications, so
PSE is acquired during probe, not on first ethtool access.

Does that sound like what you had in mind?

Cheers,
Carlo

  reply	other threads:[~2026-04-06 14:43 UTC|newest]

Thread overview: 26+ 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-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-06 12:42             ` Andrew Lunn
2026-04-06 14:43               ` Carlo Szelinsky [this message]
2026-04-06 15:21                 ` Andrew Lunn

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=20260406144324.4007913-1-github@szelinsky.de \
    --to=github@szelinsky.de \
    --cc=andrew+netdev@lunn.ch \
    --cc=andrew@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=hkallweit1@gmail.com \
    --cc=horms@kernel.org \
    --cc=kory.maincent@bootlin.com \
    --cc=kuba@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox