On 9/9/25 10:39 PM, Hans de Goede wrote:

Hi,

On 9-Sep-25 6:57 PM, Aleksandrs Vinarskis wrote:

quoted

On Monday, September 8th, 2025 at 01:18, Aleksandrs Vinarskis [off-list ref] wrote:

quoted

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 alex@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 alex@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.

FWIW we have "clocks"/"clock-names", "resets"/"reset-names" etc.

I sometimes refer to "property"/"property-names" during review to
bring attention to the preferred style (ordering of such entries),
which is maybe what confused you

Konrad