From: Chen-Yu Tsai <[email protected]>
The bindings currently list a very small subset of valid triggers for
LEDs. Since many drivers or subsystems in Linux register custom
triggers, the list would become very hard to maintain.
Instead, just drop the list and allow free form strings.
Signed-off-by: Chen-Yu Tsai <[email protected]>
---
.../devicetree/bindings/leds/common.yaml | 21 +------------------
1 file changed, 1 insertion(+), 20 deletions(-)
diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
index 4c270fde4567..3b3cdab3fc15 100644
--- a/Documentation/devicetree/bindings/leds/common.yaml
+++ b/Documentation/devicetree/bindings/leds/common.yaml
@@ -79,26 +79,7 @@ properties:
description:
This parameter, if present, is a string defining the trigger assigned to
the LED.
- allOf:
- - $ref: /schemas/types.yaml#definitions/string
- enum:
- # LED will act as a back-light, controlled by the framebuffer system
- - backlight
- # LED will turn on (but for leds-gpio see "default-state" property in
- # Documentation/devicetree/bindings/leds/leds-gpio.yaml)
- - default-on
- # LED "double" flashes at a load average based rate
- - heartbeat
- # LED indicates disk activity
- - disk-activity
- # LED indicates IDE disk activity (deprecated), in new implementations
- # use "disk-activity"
- - ide-disk
- # LED flashes at a fixed, configurable rate
- - timer
- # LED alters the brightness for the specified duration with one software
- # timer (requires "led-pattern" property)
- - pattern
+ $ref: /schemas/types.yaml#definitions/string
led-pattern:
description: |
--
2.26.0
Hi Chen-Yu,
> From: Chen-Yu Tsai <[email protected]>
>
> The bindings currently list a very small subset of valid triggers for
> LEDs. Since many drivers or subsystems in Linux register custom
> triggers, the list would become very hard to maintain.
>
> Instead, just drop the list and allow free form strings.
>
> Signed-off-by: Chen-Yu Tsai <[email protected]>
> ---
> .../devicetree/bindings/leds/common.yaml | 21 +------------------
> 1 file changed, 1 insertion(+), 20 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
> index 4c270fde4567..3b3cdab3fc15 100644
> --- a/Documentation/devicetree/bindings/leds/common.yaml
> +++ b/Documentation/devicetree/bindings/leds/common.yaml
> @@ -79,26 +79,7 @@ properties:
> description:
> This parameter, if present, is a string defining the trigger assigned to
> the LED.
> - allOf:
> - - $ref: /schemas/types.yaml#definitions/string
> - enum:
> - # LED will act as a back-light, controlled by the framebuffer system
> - - backlight
> - # LED will turn on (but for leds-gpio see "default-state" property in
> - # Documentation/devicetree/bindings/leds/leds-gpio.yaml)
> - - default-on
> - # LED "double" flashes at a load average based rate
> - - heartbeat
> - # LED indicates disk activity
> - - disk-activity
> - # LED indicates IDE disk activity (deprecated), in new implementations
> - # use "disk-activity"
> - - ide-disk
> - # LED flashes at a fixed, configurable rate
> - - timer
> - # LED alters the brightness for the specified duration with one software
> - # timer (requires "led-pattern" property)
> - - pattern
> + $ref: /schemas/types.yaml#definitions/string
This makes it free form, but deletes the documentation of options that
are standard available for people without custom driver.
Where should that info go?
>
> led-pattern:
> description: |
> --
> 2.26.0
On Mon, Apr 27, 2020 at 4:33 PM Johan Jonker <[email protected]> wrote:
>
> Hi Chen-Yu,
>
> > From: Chen-Yu Tsai <[email protected]>
> >
> > The bindings currently list a very small subset of valid triggers for
> > LEDs. Since many drivers or subsystems in Linux register custom
> > triggers, the list would become very hard to maintain.
> >
> > Instead, just drop the list and allow free form strings.
> >
> > Signed-off-by: Chen-Yu Tsai <[email protected]>
> > ---
> > .../devicetree/bindings/leds/common.yaml | 21 +------------------
> > 1 file changed, 1 insertion(+), 20 deletions(-)
> >
> > diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
> > index 4c270fde4567..3b3cdab3fc15 100644
> > --- a/Documentation/devicetree/bindings/leds/common.yaml
> > +++ b/Documentation/devicetree/bindings/leds/common.yaml
> > @@ -79,26 +79,7 @@ properties:
> > description:
> > This parameter, if present, is a string defining the trigger assigned to
> > the LED.
> > - allOf:
> > - - $ref: /schemas/types.yaml#definitions/string
> > - enum:
> > - # LED will act as a back-light, controlled by the framebuffer system
> > - - backlight
> > - # LED will turn on (but for leds-gpio see "default-state" property in
> > - # Documentation/devicetree/bindings/leds/leds-gpio.yaml)
> > - - default-on
> > - # LED "double" flashes at a load average based rate
> > - - heartbeat
> > - # LED indicates disk activity
> > - - disk-activity
> > - # LED indicates IDE disk activity (deprecated), in new implementations
> > - # use "disk-activity"
> > - - ide-disk
> > - # LED flashes at a fixed, configurable rate
> > - - timer
> > - # LED alters the brightness for the specified duration with one software
> > - # timer (requires "led-pattern" property)
> > - - pattern
> > + $ref: /schemas/types.yaml#definitions/string
>
> This makes it free form, but deletes the documentation of options that
> are standard available for people without custom driver.
> Where should that info go?
As far as I know, there is no canonical list of standard triggers.
In addition, what triggers are available also depend on the kernel
configuration, so there really is no "standard".
Since this is also configurable via sysfs, maybe it should be part
of the sysfs ABI document? Either way I believe this will be up to
the LED subsystem maintainers.
ChenYu
> >
> > led-pattern:
> > description: |
> > --
> > 2.26.0
>
On Mon, Apr 27, 2020 at 03:31:30PM +0800, Chen-Yu Tsai wrote:
> From: Chen-Yu Tsai <[email protected]>
>
> The bindings currently list a very small subset of valid triggers for
> LEDs. Since many drivers or subsystems in Linux register custom
> triggers, the list would become very hard to maintain.
The idea was we'll consolidate around standardized names and that new
users should use 'function' instead.
There was discussion around this when adding 'function'.
>
> Instead, just drop the list and allow free form strings.
>
> Signed-off-by: Chen-Yu Tsai <[email protected]>
> ---
> .../devicetree/bindings/leds/common.yaml | 21 +------------------
> 1 file changed, 1 insertion(+), 20 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml
> index 4c270fde4567..3b3cdab3fc15 100644
> --- a/Documentation/devicetree/bindings/leds/common.yaml
> +++ b/Documentation/devicetree/bindings/leds/common.yaml
> @@ -79,26 +79,7 @@ properties:
> description:
> This parameter, if present, is a string defining the trigger assigned to
> the LED.
> - allOf:
> - - $ref: /schemas/types.yaml#definitions/string
> - enum:
> - # LED will act as a back-light, controlled by the framebuffer system
> - - backlight
> - # LED will turn on (but for leds-gpio see "default-state" property in
> - # Documentation/devicetree/bindings/leds/leds-gpio.yaml)
> - - default-on
> - # LED "double" flashes at a load average based rate
> - - heartbeat
> - # LED indicates disk activity
> - - disk-activity
> - # LED indicates IDE disk activity (deprecated), in new implementations
> - # use "disk-activity"
> - - ide-disk
> - # LED flashes at a fixed, configurable rate
> - - timer
> - # LED alters the brightness for the specified duration with one software
> - # timer (requires "led-pattern" property)
> - - pattern
> + $ref: /schemas/types.yaml#definitions/string
>
> led-pattern:
> description: |
> --
> 2.26.0
>