Date:   Tue, 21 Mar 2023 16:19:53 -0500
From:   Rob Herring <robh@kernel.org>
To:     Christian Marangi <ansuelsmth@gmail.com>
Cc:     Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Vladimir Oltean <olteanv@gmail.com>,
        "David S. Miller" <davem@davemloft.net>,
        Eric Dumazet <edumazet@google.com>,
        Jakub Kicinski <kuba@kernel.org>,
        Paolo Abeni <pabeni@redhat.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Heiner Kallweit <hkallweit1@gmail.com>,
        Russell King <linux@armlinux.org.uk>,
        Gregory Clement <gregory.clement@bootlin.com>,
        Sebastian Hesselbarth <sebastian.hesselbarth@gmail.com>,
        Andy Gross <agross@kernel.org>,
        Bjorn Andersson <andersson@kernel.org>,
        Konrad Dybcio <konrad.dybcio@linaro.org>,
        Pavel Machek <pavel@ucw.cz>, Lee Jones <lee@kernel.org>,
        John Crispin <john@phrozen.org>, netdev@vger.kernel.org,
        devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org,
        linux-arm-msm@vger.kernel.org, linux-leds@vger.kernel.org
Subject: Re: [net-next PATCH v5 10/15] dt-bindings: net: ethernet-controller:
 Document support for LEDs node
Message-ID: <20230321211953.GA1544549-robh@kernel.org>
References: <20230319191814.22067-1-ansuelsmth@gmail.com>
 <20230319191814.22067-11-ansuelsmth@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230319191814.22067-11-ansuelsmth@gmail.com>
Precedence: bulk

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