lkml.org 
[lkml]   [2023]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [net-next PATCH v5 10/15] dt-bindings: net: ethernet-controller: Document support for LEDs node
    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

    \
     
     \ /
      Last update: 2023-03-27 01:11    [W:2.787 / U:0.176 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site