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

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] dt-bindings: net: needs-host-firmware encodes OS policy in DT
--

commit edf86867db27d83679811b06ea7e2a94b9b02fb8
Author: Aleksei Sviridkin <f@lex.la>

dt-bindings: net: ethernet-phy: add needs-host-firmware

This commit introduces a new needs-host-firmware property to the Ethernet PHY
bindings. It aims to delay MAC connections to PHYs that require host-loaded
firmware until their specific driver is available. This addresses an issue
where a generic driver binds early and fails to initialize a PHY needing
firmware from the root filesystem.

> diff --git a/Documentation/devicetree/bindings/net/ethernet-phy.yaml b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> --- a/Documentation/devicetree/bindings/net/ethernet-phy.yaml
> +++ b/Documentation/devicetree/bindings/net/ethernet-phy.yaml
[ ... ]
> @@ -215,6 +215,12 @@ properties:
>        used. The absence of this property indicates the muxers
>        should be configured so that the external PHY is used.
>  
> +  needs-host-firmware:

[Severity: Medium]
Does this property encode an OS-specific driver binding workaround into the
device tree ABI?

The commit message explicitly states the flag is needed because the PHY driver
"is a module not yet loaded when the MAC connects".

Device tree should describe hardware, not software policy or OS module loading
sequences.

The hardware's need for firmware is intrinsically linked to its PHY ID, which
is identical regardless of whether the driver is built-in or a module.

Can this be handled internally by the core PHY library instead of relying on a
custom DT flag to manage driver binding behavior? For example, by maintaining
a list of PHY IDs that require firmware to bypass the generic PHY driver
fallback.

> +    $ref: /schemas/types.yaml#/definitions/flag
> +    description:
> +      This PHY runs firmware that the host must load before it can be
> +      driven, and is not usable until then.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260925001209.2334139-1-f@lex.la?part=1