From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>

phy_probe() initializes the PHY driver, ports, SFP upstream, and LEDs in
stages. Its error paths do not always release only the resources acquired
at each stage. It can also mark the PHY ready before all setup succeeds.

Port setup also leaves SFP cleanup split between phy_sfp_probe(),
phy_setup_ports(), and phy_probe(), and default port setup ignores errors
from attaching the port to the PHY driver.

This series makes each initialization layer own its cleanup and propagates
setup failures to the caller.

Patch 1 splits the phy_probe() cleanup by initialization stage.

Patch 2 makes SFP and port setup unwind their resources in the required
order.

Patch 3 sets PHY_READY only after LED setup succeeds.

Patch 4 calls the PHY driver remove callback after later probe failures.

Patch 5 propagates errors from default port setup.

---
Changes:
v3:
  Patch 1:
  - Rename cleanup labels to include verbs describing their actions.
    (Jakub Kicinski.)

  Patch 3:
  - Do not clear phydev->drv before device-core teardown completes; this
    can expose NULL dereferences in concurrent attach paths and devres
    callbacks. Set PHY_READY only after LED setup succeeds and update the
    Fixes tag. (Sashiko, Jakub Kicinski.)

v2: https://lore.kernel.org/all/20260813132946.116176-1-xuanqiang.luo@linux.dev/
  Patch 1:
  - Limit this patch to splitting phy_probe() error paths, moving the SFP
    teardown fixes to Patch 2.

  Patch 2 (new):
  - makes SFP and port setup unwind their resources in the required order.
  - Add phy_sfp_release() for complete SFP teardown instead of open-coding
    sfp_bus_del_upstream(). (Andrew Lunn, Maxime Chevallier.)

  Patch 3 (new):
  - Restore PHY_DOWN and clear phydev->drv after probe failure.

  Patch 4:
  - Move the former Patch 2 to Patch 4; no functional changes.

  Patch 5 (new):
  - Propagate errors from default port setup.

v1: https://lore.kernel.org/all/20260812125127.106255-1-xuanqiang.luo@linux.dev/

Xuanqiang Luo (5):
  net: phy: split phy_probe() error paths
  net: phy: unregister SFP upstream before port cleanup
  net: phy: set PHY_READY after LED setup
  net: phy: call driver remove when core initialization fails
  net: phy: propagate errors from default port setup

 drivers/net/phy/phy_device.c | 80 ++++++++++++++++++++++++++----------
 1 file changed, 58 insertions(+), 22 deletions(-)


base-commit: f5bbbfec59b4e2fb7520a91de3df8a6174325d6a
-- 
2.43.0

On Wed, Aug 19, 2026 at 02:02:31PM +0800, Xuanqiang Luo wrote:
> From: Xuanqiang Luo <luoxuanqiang@kylinos.cn>
> 
> phy_probe() initializes the PHY driver, ports, SFP upstream, and LEDs in
> stages. Its error paths do not always release only the resources acquired
> at each stage. It can also mark the PHY ready before all setup succeeds.
> 
> Port setup also leaves SFP cleanup split between phy_sfp_probe(),
> phy_setup_ports(), and phy_probe(), and default port setup ignores errors
> from attaching the port to the PHY driver.
> 
> This series makes each initialization layer own its cleanup and propagates
> setup failures to the caller.
> 
> Patch 1 splits the phy_probe() cleanup by initialization stage.
> 
> Patch 2 makes SFP and port setup unwind their resources in the required
> order.
> 
> Patch 3 sets PHY_READY only after LED setup succeeds.
> 
> Patch 4 calls the PHY driver remove callback after later probe failures.
> 
> Patch 5 propagates errors from default port setup.

The scope of these patches has increased quite a bit. It is now more
like ongoing development work than a actual fix. Does this bother
anybody?

Please submit for net-next, once it reopens.

       Andrew

On Wed, 19 Aug 2026 15:33:28 +0200 Andrew Lunn wrote:
> Please submit for net-next, once it reopens.

FWIW I'd prefer to take these sort of error path fixes to net
during the merge window. No point backlogging borderline stuff.
Any particular reason you want this in net-next?

On Thu, Aug 20, 2026 at 10:46:36AM -0700, Jakub Kicinski wrote:
> On Wed, 19 Aug 2026 15:33:28 +0200 Andrew Lunn wrote:
> > Please submit for net-next, once it reopens.
> 
> FWIW I'd prefer to take these sort of error path fixes to net
> during the merge window. No point backlogging borderline stuff.
> Any particular reason you want this in net-next?

I don't think it bothers anybody, so does not meet stable rules.

But i've nothing against it being merged now.

    Andrew

在 2026/8/21 02:22, Andrew Lunn 写道:
> On Thu, Aug 20, 2026 at 10:46:36AM -0700, Jakub Kicinski wrote:
>> On Wed, 19 Aug 2026 15:33:28 +0200 Andrew Lunn wrote:
>>> Please submit for net-next, once it reopens.
>> FWIW I'd prefer to take these sort of error path fixes to net
>> during the merge window. No point backlogging borderline stuff.
>> Any particular reason you want this in net-next?
> I don't think it bothers anybody, so does not meet stable rules.
>
> But i've nothing against it being merged now.
>
>      Andrew

Thanks for the discussion.

Based on the feedback, I’ll continue targeting net and post a revised
version in a follow-up.

Thanks,
Xuanqiang