Re: [PATCH net-next 0/3] net: survive a PHY whose driver arrives after the switch probes

[Aleksei Sviridkin <f@lex.la>]

Hi Andrew

I built it: both halves, as an MVP on my board. The MDIO device with a
nested pass-through bus for one address, and slow-to-probe in phylink
with a poller modeled on the SFP path. The port survives the switch
probe, the poller connects the real driver a few seconds later with its
interrupt from DT, and it held across reboots in both topologies. Holes
I hit, all on real boots:

1. "Polls until it resolves" needs a stricter resolve than the device
existing. A phy_device with no driver gets genphy bound by
phy_attach_direct(), which cannot drive this PHY;
phylink_sfp_connect_phy() already refuses a driverless PHY for the same
reason. And "driver bound" is still not enough, because the core
assigns dev->driver before probe runs. A poll tick landing mid-probe
connected a PHY with an all-zero supported mask:

  lan4: validation of 2500base-x with support 0000000,00000000,00000000,00000000 ... failed: -EINVAL

What survived hardware: driver bound, not genphy, state past PHY_DOWN.

2. The poller needs rtnl to connect, and phylink_disconnect_phy() runs
under rtnl, so a synchronous cancel there deadlocks. Trylock plus
requeue in the worker, non-sync cancel at disconnect, sync cancel only
in phylink_destroy(). A failed connect must not stop the polling, errno
cannot tell the race above from a permanent failure. The retry needs
backoff though: failed bringup goes through phy_detach(), which pulses
the reset line, and this chip's firmware lives behind that line.

3. Returning 0 for the armed case matters beyond the error code: on
-ENODEV, DSA goes looking on the switch's internal MDIO bus and
attaches the internal GbE PHY to the 2500base-x port, which then fails
validation.

4. Polling costs one interval of latency. The tick phase is set when
the port arms, so the attach lands anywhere in [0, interval) after the
PHY becomes ready; I measured 0.7s of a 1s interval. The exact event
exists, BUS_NOTIFY_BOUND_DRIVER fires at probe completion, but
mdio_bus_type is internal to phylib, so the notifier has to live there
behind a small API, it still needs the genphy filter, and the callback
runs under device_lock so it still defers to a workqueue. My plan is
polling first and the notifier as a follow-up, unless you want it
event-driven from the start.

Two questions before I send the series.

My MCU driver only waits for the firmware files and registers the
nested bus; the download stays in the PHY driver, which already does
it. Moving it into the MDIO driver duplicates the loader for a quad-PHY
case no board has yet. Is the MCU-side download a hard part of the
design for you?

On this board the minimal variant, slow-to-probe alone with the PHY
node directly on the bus, carries everything by itself: the chip
answers its ID from the bootloader, and the driver and firmware arrive
together. The MDIO-device layer buys the general case (chips silent
before firmware, quad PHY, reset ownership). Both layers in one series,
or slow-to-probe first?

	Aleksei