Re: [PATCH net-next v6 0/3] net: phylink: wait for a PHY that probes after the MAC

On 10/6/26 14:47, Aleksei Sviridkin wrote:

On the Keenetic KN-1012 (MT7981B with an MT7531 switch), the Airoha
EN8811H behind lan4 has its PHY driver built as a module on the root
filesystem. The switch sets up its ports before that filesystem is
mounted, so the port is validated against the generic driver, fails its
phy-mode and stays dead for the uptime. DSA does not retry it.

Patch 1 lets the PHY node say so with needs-host-firmware. Patch 2 makes
phylink poll for such a PHY instead of giving up, for a MAC that opts
in. Patch 3 opts in DSA user ports of switch drivers that set a flag,
and sets it in mt7530.

The poller can still lose a race against an unbind of the PHY driver,
between its readiness check and the attach. That window is phylib's:
any phy_attach_direct() caller racing an unbind has it. The attach
guard series [1] closes it.

Tested on that board with the series backported to its OpenWrt 6.18
kernel, together with a940003f44e7 and 07d995873960 (the mt7530
.get_stats64 atomic-context fix). The kernel had lockdep and
DEBUG_ATOMIC_SLEEP on. Local debug parameters, not part of the series,
drove the error paths. They fail the connect after a successful attach,
ignore the opt-in, fail the generic attach of a PHY with no driver, and
add a sleep after the switch shutdown.

  - boot: the PHY driver loaded its firmware at 8.7 s. lan4 attached at
    26.3 s, when the port was brought up. Link up at 1 Gb/s.
  - port kept down for 10 s with the PHY driver bound: no poll and no
    attach. "ip link set lan4 up" attached it a second later.
  - opt-in ignored: the old behaviour, the generic driver took the PHY.
  - two injected failures: "failed to connect late PHY: -EIO" twice, a
    second apart, and the third attempt attached. Link up at 1 Gb/s.
  - failures that do not stop: four attempts and one "giving up". No
    poll after that, also not after a down/up.
  - four failed generic attaches with no driver bound: nothing logged as
    a failure and no retry spent. The port attached once the driver
    bound.
  - switch unbound while the poller waited: nothing oopsed.
  - reboot with a 3 s sleep after the switch shutdown: the poll ran
    every second up to the shutdown and not once in the sleep. On v5 the
    same test polled 3 times in the sleep.

No in-tree device tree sets needs-host-firmware yet. The board is
supported out of tree, in OpenWrt.

I'm sorry to give this feedback this late, but AI flood forces this
workflow on us.

The above looks like a significant amount of complexity for OoT driver,
and I understand it could be solved with a different kconf?

/P