Re: [PATCH net-next 3/3] net: dsa: connect a late-arriving PHY at ifup

[Aleksei Sviridkin <f@lex.la>]

> The problem is, this is not guaranteed to work. The driver might still
> not be loaded, or it is still downloading firmware to the PHY.

These are two separate halves, and the driver can only reach one of
them. When the firmware is late, your scheme works, and I want to do it
as a follow-up. When the module itself is still on an unmounted rootfs,
there is no probe to return success from, so the connect at switch
setup still gets the genphy fallback and the port is gone for good.
This patch is for that half, and it is the half the board in the
commit message hits: the driver is a module on the rootfs.

> Think about the case of NFS root. The kernel will open() the interface
> as soon as netdev_register() is called.

With NFS root the module and the firmware sit behind the network they
are supposed to bring up, so that setup already requires building them
in or an initramfs. With those in place the connect at setup succeeds
and this patch stays out of the way. Without them, today's kernel drops
the port at setup and NFS root is just as dead, so this does not
regress it.

> I think you need to look at the PHY driver. Make its probe function
> return success, but start a thread downloading the firmware. While
> firmware is downloading, either soft_reset() or config_init() needs to
> block.

I would rather not block: config_init runs inside phy_attach_direct, so
on a DSA switch the blocked port holds up the whole switch probe and
every other port with it. For the follow-up I want to attach with the
real driver's features immediately and keep the link down until the
firmware lands, then trigger aneg, the way an SFP port sits linkless
without a module. aquantia and mscc load firmware from probe too, so a
phylib helper for this would have three users.

If the async firmware part should come first and this patch second, I
can reorder.