Re: [RFC PATCH net-next 1/2] dt-bindings: net: ethernet-controller: add phy-needs-host-firmware

[Aleksei Sviridkin]

On Mon, Sep 07, 2026 at 06:26:31PM +0100, Conor Dooley wrote:
> That doesn't seem right, sounds like it should be on the phy if the
> behaviour is caused by the phy.
> In fact, it seems like something that should be determined when the
> phy is identified, not really sure why it needs a property at all? Or
> based on the fact that the phy has firmware-name.

firmware-name it is. marvell,aquantia and aeonsemi,as21xxx already
describe a firmware loading PHY that way, and as21xxx requires the
property for the compatible the chip answers before its firmware runs.
The node on my board already carries that pre-firmware compatible,
ethernet-phy-id03a2.a411. So the new property goes away and the wait
keys off firmware-name.

Measured on the board today, same kernel, one line of device tree apart.
With firmware-name on the PHY node the port survives setup and the PHY
attaches at 7.1s with the interrupt from its node, link up. Without it
the connect fails at 1.83s, validation -EINVAL, "error -22 setting up
PHY", and the interface never appears; the firmware still lands at 6.37s
with nobody waiting for it.

Identification is not what is missing. The chip answers 03a2.a411 before
any firmware runs and the generic driver binds to it. What the kernel
cannot see is that a driver for that ID sits in a module the rootfs has
not offered yet. In the other topology, where an MCU driver registers
the PHY's bus, there is no device to identify when the controller
probes.

One thing I do not know how you want it: this chip takes two blobs, DM
and DSP, and the bindings that use firmware-name allow one name. Name
the first and leave the second in the driver, or allow two entries?