The led child reg node is the index within the bank, document that
and update the example accordingly.
Signed-off-by: Johan Adolfsson <johan.adolfsson@axis.com>
---
.../devicetree/bindings/leds/leds-lp50xx.yaml | 19 ++++++++++++-------
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
index 402c25424525..a7b2d87cc39d 100644
--- a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
+++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
@@ -81,7 +81,12 @@ patternProperties:
properties:
reg:
- maxItems: 1
+ minimum: 0
+ maximum: 2
+ description:
+ This property denotes the index within the LED bank.
+ The value will act as the index in the multi_index file to give
+ consistent result independent of devicetree processing order.
required:
- reg
@@ -138,18 +143,18 @@ examples:
color = <LED_COLOR_ID_RGB>;
function = LED_FUNCTION_STANDBY;
- led@3 {
- reg = <0x3>;
+ led@0 {
+ reg = <0x0>;
color = <LED_COLOR_ID_RED>;
};
- led@4 {
- reg = <0x4>;
+ led@1 {
+ reg = <0x1>;
color = <LED_COLOR_ID_GREEN>;
};
- led@5 {
- reg = <0x5>;
+ led@2 {
+ reg = <0x2>;
color = <LED_COLOR_ID_BLUE>;
};
};
--
2.30.2
On 26/05/2025 16:54, Johan Adolfsson wrote:
> The led child reg node is the index within the bank, document that
> and update the example accordingly.
>
> Signed-off-by: Johan Adolfsson <johan.adolfsson@axis.com>
> ---
> .../devicetree/bindings/leds/leds-lp50xx.yaml | 19 ++++++++++++-------
> 1 file changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
> index 402c25424525..a7b2d87cc39d 100644
> --- a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
> +++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml
> @@ -81,7 +81,12 @@ patternProperties:
>
> properties:
> reg:
> - maxItems: 1
> + minimum: 0
> + maximum: 2
"not compatible with minimum
and maximum."
No, it is compatible. Just do:
items:
- minimum: 0
maximum: 2
You call this patchset still an RFC, which usually means - do not
review, not ready. Usually when I review RFC I received negative
response that why do I review it... Therefore I tend to don't care about
RFC. Some maintainers completely ignore RFC.
Please EXPLICITLY document in cover letter why this is RFC and what you
expect from us (IOW, why this is not ready for review).
If dropping RFC, keep versioning (people also tend to do it wrong
completely messing up the tools), although I see you use b4, so this
should be without problem.
Best regards,
Krzysztof
© 2016 - 2025 Red Hat, Inc.