Re: [net-next PATCH v5 10/15] dt-bindings: net: ethernet-controller: Document support for LEDs node

[Rob Herring <robh@kernel.org>]

On Sun, Mar 19, 2023 at 08:18:09PM +0100, Christian Marangi wrote:
> Document support for LEDs node in ethernet-controller.
> Ethernet Controller may support different LEDs that can be configured
> for different operation like blinking on traffic event or port link.
> 
> Also add some Documentation to describe the difference of these nodes
> compared to PHY LEDs, since ethernet-controller LEDs are controllable
> by the ethernet controller regs and the possible intergated PHY doesn't
> have control on them.
> 
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
>  .../bindings/net/ethernet-controller.yaml     | 21 +++++++++++++++++++
>  1 file changed, 21 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> index 00be387984ac..a93673592314 100644
> --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml
> @@ -222,6 +222,27 @@ properties:
>          required:
>            - speed
>  
> +  leds:
> +    type: object
> +    description:
> +      Describes the LEDs associated by Ethernet Controller.
> +      These LEDs are not integrated in the PHY and PHY doesn't have any
> +      control on them. Ethernet Controller regs are used to control
> +      these defined LEDs.
> +
> +    properties:
> +      '#address-cells':
> +        const: 1
> +
> +      '#size-cells':
> +        const: 0
> +
> +    patternProperties:
> +      '^led(@[a-f0-9]+)?$':
> +        $ref: /schemas/leds/common.yaml#

Are specific ethernet controllers allowed to add their own properties in 
led nodes? If so, this doesn't work. As-is, this allows any other 
properties. You need 'unevaluatedProperties: false' here to prevent 
that. But then no one can add properties. If you want to support that, 
then you need this to be a separate schema that devices can optionally 
include if they don't extend the properties, and then devices that 
extend the binding would essentially have the above with:

$ref: /schemas/leds/common.yaml#
unevaluatedProperties: false
properties:
  a-custom-device-prop: ...


If you wanted to define both common ethernet LED properties and 
device specific properties, then you'd need to replace leds/common.yaml 
above  with the ethernet one.

This is all the same reasons the DSA/switch stuff and graph bindings are 
structured the way they are.

Rob