Hi, On 9-Sep-25 6:57 PM, Aleksandrs Vinarskis wrote: > > > > > > On Monday, September 8th, 2025 at 01:18, Aleksandrs Vinarskis > <a...@vinarskis.com> wrote: > >> >> >> Introduce common generic led consumer binding, where consumer defines >> led(s) by phandle, as opposed to trigger-source binding where the >> trigger source is defined in led itself. >> >> Add already used in some schemas 'leds' parameter which expects >> phandle-array. Additionally, introduce 'led-names' which could be used >> by consumers to map LED devices to their respective functions. >> >> Signed-off-by: Aleksandrs Vinarskis a...@vinarskis.com >> >> --- >> .../devicetree/bindings/leds/leds-consumer.yaml | 89 ++++++++++++++++++++++ >> 1 file changed, 89 insertions(+) >> >> diff --git a/Documentation/devicetree/bindings/leds/leds-consumer.yaml >> b/Documentation/devicetree/bindings/leds/leds-consumer.yaml >> new file mode 100644 >> index >> 0000000000000000000000000000000000000000..d50a3850f6336e9e3a52eb1374e36ea50de27f47 >> --- /dev/null >> +++ b/Documentation/devicetree/bindings/leds/leds-consumer.yaml >> @@ -0,0 +1,89 @@ >> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: http://devicetree.org/schemas/leds/leds-consumer.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: Common leds consumer >> + >> +maintainers: >> + - Aleksandrs Vinarskis a...@vinarskis.com >> >> + >> +description: >> + Some LED defined in DT are required by other DT consumers, for example >> + v4l2 subnode may require privacy or flash LED. Unlike trigger-source >> + approach which is typically used as 'soft' binding, referencing LED >> + devices by phandle makes things simpler when 'hard' binding is desired. >> + >> + Document LED properties that its consumers may define. >> + >> +select: true >> + >> +properties: >> + leds: >> + oneOf: >> + - type: object >> + - $ref: /schemas/types.yaml#/definitions/phandle-array >> + description: >> + A list of LED device(s) required by a particular consumer. >> + items: >> + maxItems: 1 >> + >> + led-names: > > While going over the feedback I realized `leds` and `led-names` do > not follow `property`, `property-names` convention. Any objections > if I rename `led-names` to `leds-names` for consistency?
No objections from me, `leds-names` indeed is better. Regards, Hans
