On Mon, Mar 27, 2023 at 04:10:25PM +0200, Christian Marangi wrote: > Add documentation for support of generic ethernet LEDs. > These LEDs are ethernet port LED and are controllable by the ethernet > controller or the ethernet PHY. > > A port may expose multiple LEDs and reg is used to provide an index to > differentiate them. > Ethernet port LEDs follow generic LED implementation. > > Signed-off-by: Christian Marangi <ansuelsmth@xxxxxxxxx> > --- > .../bindings/leds/leds-ethernet.yaml | 76 +++++++++++++++++++ > 1 file changed, 76 insertions(+) > create mode 100644 Documentation/devicetree/bindings/leds/leds-ethernet.yaml > > diff --git a/Documentation/devicetree/bindings/leds/leds-ethernet.yaml b/Documentation/devicetree/bindings/leds/leds-ethernet.yaml > new file mode 100644 > index 000000000000..0a03d65beea0 > --- /dev/null > +++ b/Documentation/devicetree/bindings/leds/leds-ethernet.yaml > @@ -0,0 +1,76 @@ > +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/leds/leds-ethernet.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Common properties for the ethernet port LED. > + > +maintainers: > + - Christian Marangi <ansuelsmth@xxxxxxxxx> > + > +description: > + Bindings for the LEDs present in ethernet port and controllable by > + the ethernet controller or the ethernet PHY regs. > + > + These LEDs provide the same feature of a normal LED and follow > + the same LED definitions. > + > + An ethernet port may expose multiple LEDs, reg binding is used to > + differentiate them. > + > +properties: > + '#address-cells': > + const: 1 > + > + '#size-cells': > + const: 0 > + > +patternProperties: > + '^led@[a-f0-9]+$': > + $ref: /schemas/leds/common.yaml# > + > + properties: > + reg: > + maxItems: 1 > + description: > + This define the LED index in the PHY or the MAC. It's really > + driver dependent and required for ports that define multiple > + LED for the same port. > + > + required: > + - reg > + > + unevaluatedProperties: false This does nothing to help the issues I raised. If the 'led' nodes have custom properties, then you need a schema for the 'led' nodes and just the 'led' nodes. Not a schema for the 'leds' container node. If your not going to allow extending, then this can all be 1 file like you had (with unevaluatedProperties added of course). Rob