Re: [PATCH net-next 1/9] dt-bindings: net: ti,dp83867: add supply properties

[netdev-bot+sashiko]

Thank you for your contribution! Sashiko AI review found 1 potential
issue(s) to consider:

Critical: 0 · High: 0 · Medium: 0 · Low: 1

- [Low] Concern (invalidated): the four newly documented supply
  properties (vdda-2p5-supply, vdd-1p0-supply, vdda-1p8-supply, vddio-…

--

dt-bindings: net: ti,dp83867: add supply properties

This documents four power supply properties for the DP83867 PHY
(vdda-2p5-supply, vdd-1p0-supply, vdda-1p8-supply and vddio-supply),
matching the two-supply and three-supply configurations described in the
datasheet plus the separate VDDIO rail.

> diff --git a/Documentation/devicetree/bindings/net/ti,dp83867.yaml b/Documentation/devicetree/bindings/net/ti,dp83867.yaml
> index 4bc1f98fd9fe5..e78f08ded3d0d 100644
> --- a/Documentation/devicetree/bindings/net/ti,dp83867.yaml
> +++ b/Documentation/devicetree/bindings/net/ti,dp83867.yaml
> @@ -118,6 +118,20 @@ properties:
>        Transmitt FIFO depth- see dt-bindings/net/ti-dp83867.h for applicable
>        values.
>  
> +  vdda-2p5-supply:
> +    description: 2.5V analog supply (connected to the VDDA2P5 pins).
> +
> +  vdd-1p0-supply:
> +    description: 1.0V digital core supply (connected to the VDD1P0 pins).
> +
> +  vdda-1p8-supply:
> +    description: 1.8V analog supply (connected to the VDDA1P8 pins).
> +
> +  vddio-supply:
> +    description: |
> +      I/O supply (connected to the VDDIO pins). The supply can be 1.8V,
> +      2.5V or 3.3V.
> +

[Severity: Low]
One question came up while reviewing this in isolation: do these four
property names have a consumer anywhere?

Looking at the rest of the series, they do. The following patch,
"net: phy: dp83867: add regulator supply management", adds
dp83867_power_on() in drivers/net/phy/dp83867.c, which walks exactly
these names:

  static const char * const supply_names[] = {
          "vdda-2p5", "vdd-1p0", "vdda-1p8", "vddio",
  };
  ...
          ret = devm_regulator_get_enable_optional(dev, supply_names[i]);

and dp83867_probe() calls it:

          ret = dp83867_power_on(phydev);
          if (ret)
                  return ret;

So the names match and devm_regulator_get_enable_optional() handles the
disable/put on teardown. No change requested here; noting it only so the
binding-only patch is not read as documenting unused properties.

One remaining observation, and it belongs to the driver patch rather than
this one: a rail such as VDDIO that gates the MDIO interface itself cannot
be brought up from a PHY probe callback, since probe only runs after the
PHY ID has already been read over MDIO. Is that ordering expected to be
handled by the MDIO bus or board regulator-always-on instead?

-- 
Sashiko AI review · https://netdev-ai.bots.linux.dev/sashiko/#/patchset/20260904-shikra_ethernet-v1-0-a50765996035%40oss.qualcomm.com