Re: [RFC PATCH net-next 1/2] dt-bindings: net: ethernet-controller: add phy-needs-host-firmware
flat view
From: Aleksei Sviridkin <hidden>
Date: 2026-09-10 15:38:20
Also in:
linux-devicetree, lkml
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?