Re: [PATCH net] net: ixp4xx_eth: handle probe deferral from of_get_mac_address()

[Jakub Kicinski <kuba@kernel.org>]

On Wed, 26 Aug 2026 18:36:34 -0700 Rosen Penev wrote:
> ixp4xx_of_get_platdata() returns NULL on failure, which the probe converts
> to -ENODEV, discarding the real cause of the failure. Return ERR_PTR()
> with the appropriate error so callers can distinguish cases such as
> missing DT properties (-EINVAL) and, importantly, handle -EPROBE_DEFER
> from of_get_mac_address().

Doesn't seem like this should be treated as a fix, AI says:

Can a device tree that actually reaches this new code path pass
dtbs_check? -EPROBE_DEFER out of of_get_mac_address() only comes from
the nvmem lookup:

net/core/of_net.c:of_get_mac_address() {
	...
	return of_get_mac_address_nvmem(np, addr);
}

which needs nvmem-cells and nvmem-cell-names = "mac-address" in the node.
Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml ends with
additionalProperties: false and pulls in ethernet-controller.yaml only via
allOf/$ref, re-listing just phy-mode, phy-handle and fixed-link. It never
lists nvmem-cells, nvmem-cell-names, mac-address or local-mac-address.

Should the binding gain those properties (or switch to
unevaluatedProperties: false) so the configuration this patch handles
can be described?


And if this goes to net-next there's a bunch of pre-existing
bugs in the area which will conflict, so frankly let's just leave 
this be.