Re: [PATCH RFC net-next 0/4] net: pse-pd: decouple controller lookup from MDIO probe

[Corey Leavitt <corey@leavitt.info>]

Hi Carlo,

Thanks for testing, and for the clear writeup of the rmmod path.
Will add your Tested-by to v2.

On the rmmod / module_get question: I think you are right that the
per-consumer try_module_get is structurally redundant once the
notifier exists, since PSE_UNREGISTERED already gives us a
synchronous invalidation point at unregister time. The reason I
did not strip it in v1 was caution: I want to walk every
pse_control_get / pse_control_put consumer and confirm no path
holds a transient reference outside of rtnl-lock (or some
equivalent serialization) such that an in-flight use could race
the unregister notifier.

That audit is on my plate now. I will share findings on this
thread before v2, and let the result drive whether the removal
lands in v2 or as a separate discussion.

Glad to hear the probe loop is gone on your bench and that ethtool
plus PD power are behaving. I expect to have an SFP-capable board
on my own bench later this week, so I will cover the sfp.c path
change before sending v2; a retest from you on the SFP chassis
whenever it is convenient is still very welcome as independent
confirmation.

Kory, Jakub, Russell, others: input welcome on whether dropping
try_module_get in favor of pure notifier-based invalidation is the
direction you would prefer here, or whether the belt-and-suspenders
refcount is worth keeping.

Thanks,
Corey