Re: [PATCH net-next v8 7/7] net: phy: own phydev->psec via PSE notifier and remove fwnode_mdio hook

[Carlo Szelinsky]

On Mon, 05 Oct 2026 17:33:32 +0000, netdev-bot+sashiko@xxxxxxxxxx wrote:
> [Severity: Low]
> Should this have a Fixes: tag?
...
> If this is meant for net-next only, could the commit message say so?

No Fixes: tag: the series goes to net-next. The deferred-probe storm is
not caused by one commit, and fixing it needs the whole series, so it
cannot be backported as a small fix.

> [Severity: Medium]
> Can this retry leak a reference on the PSE controller module? When
> pse_pi_is_hw_enabled() fails, pse_control_get_internal() jumps past
> module_put():

Yes. That is an older bug, and the retries now hit it more often. Its
fix goes to net: both error paths now jump to put_module.

> [Severity: Medium]
> Does a later PSE_REGISTERED event really retry every -EPROBE_DEFER?

No. If the vpwr provider is registered but not bound yet, the PHY gets
no PSE handle until the next PSE_REGISTERED event. The commit message
says so. Retrying when the supply becomes available would need an event
from the regulator core, which does not exist today. It is the same
small window as in the supply check patch.

> [Severity: Medium]
> Can a failed PSE driver probe now power down a port that was already
> live?

Yes, and that is intended; the commit message says so. If the PSE
driver's probe fails, the controller cannot be used, so switching its
ports off is the safe result.

> [Severity: High]
> This isn't a bug introduced by this patch, but the new pse_phy_lock()
> scheme does not cover psec->attached_phydev. Can pse_send_ntf_worker()
> read a freed phy_device here?

Yes. That is an older bug; its fix goes to net: the worker now looks up
the handle and uses attached_phydev while it holds pse_list_mutex, so
the PHY cannot be freed in between.

> [Severity: High]
> This is a pre-existing issue, but pse_release_pis() still frees pcdev->pi
> here while the PI regulators that index it are registered.

Yes. That is an older bug. It is addressed by a separate net series:
https://lore.kernel.org/netdev/20260813200653.980170-1-github@xxxxxxxxxxxx/

pw-bot: cr

Carlo