From: Marek Vasut <marex@denx.de> Date: 2021-10-24 00:24:23
There is a trigger called "none" which triggers never, add it to the
list of valid trigger values.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Pavel Machek <redacted>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
To: linux-leds@vger.kernel.org
---
Documentation/devicetree/bindings/leds/common.yaml | 2 ++
1 file changed, 2 insertions(+)
@@ -92,6 +92,8 @@ properties:# LED indicates IDE disk activity (deprecated), in new implementations# use "disk-activity"-ide-disk+# LED is not triggered+-none# LED flashes at a fixed, configurable rate-timer# LED alters the brightness for the specified duration with one software
From: Marek Vasut <marex@denx.de> Date: 2021-10-24 00:24:23
The mmc subsystem supports triggering leds on card activity, document
the trigger value here. The value is a pattern in this case.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Pavel Machek <redacted>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
To: linux-leds@vger.kernel.org
---
.../devicetree/bindings/leds/common.yaml | 43 ++++++++++---------
1 file changed, 23 insertions(+), 20 deletions(-)
@@ -79,26 +79,29 @@ properties:the LED.$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 is not triggered--none-# 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+oneOf:+-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 is not triggered+-none+# 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+# LED is triggered by SD/MMC activity+-pattern:"^mmc[0-9]+$"led-pattern:description:|
From: Pavel Machek <hidden> Date: 2021-10-24 08:41:37
Hi!
There is a trigger called "none" which triggers never, add it to the
list of valid trigger values.
We can do this, but is it useful? If you avoid putting trigger
property, it will do the same thing.
Best regards,
Pavel
--
http://www.livejournal.com/~pavelmachek
From: Rob Herring <robh@kernel.org> Date: 2021-10-24 14:27:33
On Sun, 24 Oct 2021 02:23:58 +0200, Marek Vasut wrote:
The mmc subsystem supports triggering leds on card activity, document
the trigger value here. The value is a pattern in this case.
Signed-off-by: Marek Vasut <marex@denx.de>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Pavel Machek <redacted>
Cc: Rob Herring <robh+dt@kernel.org>
Cc: devicetree@vger.kernel.org
To: linux-leds@vger.kernel.org
---
.../devicetree/bindings/leds/common.yaml | 43 ++++++++++---------
1 file changed, 23 insertions(+), 20 deletions(-)
My bot found errors running 'make DT_CHECKER_FLAGS=-m dt_binding_check'
on your patch (DT_CHECKER_FLAGS is new in v5.13):
yamllint warnings/errors:
./Documentation/devicetree/bindings/leds/common.yaml:85:9: [warning] wrong indentation: expected 10 but found 8 (indentation)
dtschema/dtc warnings/errors:
doc reference errors (make refcheckdocs):
See https://patchwork.ozlabs.org/patch/1545330
This check can fail if there are any dependencies. The base for a patch
series is generally the most recent rc1.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit.
From: Marek Vasut <marex@denx.de> Date: 2021-10-24 18:03:36
On 10/24/21 10:40 AM, Pavel Machek wrote:
Hi!
quoted
The mmc subsystem supports triggering leds on card activity, document
the trigger value here. The value is a pattern in this case.
I don't believe this is suitable as devicetree does not know about mmc
numbers.
There are multiple instances of this trigger type in existing DTs, see:
$ git grep linux.default-trigger.=..mmc | wc -l
85
So what alternative do you suggest ?
From: Marek Vasut <marex@denx.de> Date: 2021-10-24 18:05:59
On 10/24/21 10:41 AM, Pavel Machek wrote:
Hi!
quoted
There is a trigger called "none" which triggers never, add it to the
list of valid trigger values.
We can do this, but is it useful? If you avoid putting trigger
property, it will do the same thing.
It's not that simple. If you have a DT which specifies a trigger type
and a DTO which overrides that trigger type, then the DTO cannot remove
the trigger from the base DT, it has to set trigger type to "none". So I
believe there is a valid use case for existence of the "none" type.
From: Rob Herring <robh@kernel.org> Date: 2021-11-08 17:51:23
On Sun, Oct 24, 2021 at 08:05:55PM +0200, Marek Vasut wrote:
On 10/24/21 10:41 AM, Pavel Machek wrote:
quoted
Hi!
quoted
There is a trigger called "none" which triggers never, add it to the
list of valid trigger values.
We can do this, but is it useful? If you avoid putting trigger
property, it will do the same thing.
It's not that simple. If you have a DT which specifies a trigger type and a
DTO which overrides that trigger type, then the DTO cannot remove the
trigger from the base DT, it has to set trigger type to "none". So I believe
there is a valid use case for existence of the "none" type.
Sounds like an incorrect partitioning of base and overlays IMO.
There's also already /delete-property/ directive though I'm not sure if
that's supported in overlays.
Rob
From: Marek Vasut <marex@denx.de> Date: 2021-11-08 22:49:15
On 11/8/21 6:51 PM, Rob Herring wrote:
On Sun, Oct 24, 2021 at 08:05:55PM +0200, Marek Vasut wrote:
quoted
On 10/24/21 10:41 AM, Pavel Machek wrote:
quoted
Hi!
quoted
There is a trigger called "none" which triggers never, add it to the
list of valid trigger values.
We can do this, but is it useful? If you avoid putting trigger
property, it will do the same thing.
It's not that simple. If you have a DT which specifies a trigger type and a
DTO which overrides that trigger type, then the DTO cannot remove the
trigger from the base DT, it has to set trigger type to "none". So I believe
there is a valid use case for existence of the "none" type.
Sounds like an incorrect partitioning of base and overlays IMO.
Note that you might not have control over the base DT.
There's also already /delete-property/ directive though I'm not sure if
that's supported in overlays.
How do you encode /delete-property/ into the DT overlay blob .dtbo ?
I thought that /delete-property/ and /delete-node/ was a DTC directive
and the DT blob has no way to represent either ?