Add default-brightness property to leds/common.yaml to establish a single
canonical definition for LED brightness initialization.
The property is currently defined locally in leds/leds-pwm.yaml and is
needed by auxdisplay/titanmec,tm16xx.yaml. Properties should be defined
in only one location to avoid type inconsistencies across bindings.
Signed-off-by: Jean-François Lessard <jefflessard3@gmail.com>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Lee Jones <lee@kernel.org>
Other than described in commit c94d178313 ("dt-bindings: net: phy:
Make LED active-low property common") the absence of the 'active-low'
property means not to touch the polarity settings which are inherited
from reset defaults, the bootloader or bootstrap configuration. Hence,
in order to override a LED pin being active-high in case of the default,
bootloader or bootstrap setting being active-low an additional property
'active-high' is required. Document that property and make it mutually
exclusive to the existing 'active-low' property.
Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/e9b15613a81129ceecb07ec51f71bbe75425ad2e.1728558223.git.daniel@makrotopia.org
Signed-off-by: Lee Jones <lee@kernel.org>
Document the "rc-feedback" trigger which is used to control LEDs by
remote control device activity. This is an existing trigger used in
existing DTs, document it so validation of those DTs would pass.
It was originally introduced into the Linux kernel in 2013 with
commit 153a60bb0f ("[media] rc: add feedback led trigger for rc keypresses")
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Acked-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
Link: https://lore.kernel.org/r/20241007205315.2477060-1-heiko@sntech.de
Signed-off-by: Lee Jones <lee@kernel.org>
Move LED active-low property to common.yaml. This property is currently
defined multiple times by bcm LEDs. This property will now be supported
in a generic way for PHY LEDs with the use of a generic function.
With active-low bool property not defined, active-high is always
assumed.
Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Acked-by: Lee Jones <lee@kernel.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/20240125203702.4552-2-ansuelsmth@gmail.com
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Normally, the maximum brightness is determined by the hardware, and this
property is not required. This property is used to set a software limit.
It could happen that an LED is made so bright that it gets damaged or
causes damage due to restrictions in a specific system, such as mounting
conditions.
Note that this flag is mainly used for PWM-LEDs, where it is not possible
to map brightness to current. Drivers for other controllers should use
led-max-microamp.
Signed-off-by: Astrid Rost <astrid.rost@axis.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Link: https://lore.kernel.org/r/20230703130313.548519-2-astrid.rost@axis.com
Signed-off-by: Lee Jones <lee@kernel.org>
Commit e91a4d5deb ("dt-bindings: leds: Document commonly used
LED triggers") introduced a enum match for cpu, while a pattern
'^cpu[0-9]*$' already exists.
This causes linux,default-trigger = "cpu" to have more than one match
and generates the following dtbs_check warning:
arch/arm64/boot/dts/ti/k3-j721e-beagleboneai64.dtb: leds: led-2:linux,default-trigger: More than one condition true in oneOf schema:
{'$ref': '/schemas/types.yaml#/definitions/string',
'oneOf': [{'items': [{'enum': ['backlight',
'default-on',
'heartbeat',
'disk-activity',
'disk-read',
'disk-write',
'timer',
'pattern',
'audio-micmute',
'audio-mute',
'bluetooth-power',
'cpu',
'flash',
'kbd-capslock',
'mtd',
'nand-disk',
'none',
'torch',
'usb-gadget',
'usb-host',
'usbport']}],
'maxItems': 1,
'minItems': 1,
'type': 'array'},
{'items': [{'pattern': '^cpu[0-9]*$'}],
'maxItems': 1,
'minItems': 1,
'type': 'array'},
{'items': [{'pattern': '^hci[0-9]+-power$'}],
'maxItems': 1,
'minItems': 1,
'type': 'array'},
{'items': [{'pattern': '^mmc[0-9]+$'}],
'maxItems': 1,
'minItems': 1,
'type': 'array'},
{'items': [{'pattern': '^phy[0-9]+tx$'}],
'maxItems': 1,
'minItems': 1,
'type': 'array'}]}
Drop the explicit match against cpu since the pattern match already
covers the same.
Fixes: e91a4d5deb ("dt-bindings: leds: Document commonly used LED triggers")
Signed-off-by: Nishanth Menon <nm@ti.com>
Acked-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230424151437.256073-1-nm@ti.com
Linux's "usbport" trigger is a bit specific one. It allows LED to follow
state of multiple USB ports which have to be selected additionally
(there isn't a single trigger for each port).
Default list of USB ports to monitor can be specified using
"trigger-sources" DT property. Theoretically it should be possible for
Linux to deduce applicable trigger based on the references nodes in the
"trigger-sources". It hasn't been implemented however (probably due to
laziness).
Milk spilled - we already have DT files specifying "usbport" manually -
allow that value in the binding. This fixes validation of in-kernel and
external DT files.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230316135546.9162-1-zajec5@gmail.com
Document the commonly used LED triggers by the SoCs. Not all triggers
are documented as some of them are very application specific. Most of the
triggers documented here are currently used in devicetrees of many SoCs.
While at it, add missing comments and also place the comment above the
triggers (hci, mmc, wlan) to match the rest of the binding.
Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Lee Jones <lee@kernel.org>
Link: https://lore.kernel.org/r/20230303122925.6610-1-manivannan.sadhasivam@linaro.org
Add 'cpu' and 'cpuN' to possible values for 'linux,default-trigger'.
There's 45 cases of them in upstream dts files.
Signed-off-by: Rob Herring <robh@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
The max77693 LED device node should not take an unit address, because it
is instantiated from a max77693 I2C parent device node. This also
splits all examples to separate DTS examples because they are actually
independent.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Reviewed-by: Javier Martinez Canillas <javierm@redhat.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
Document the retain-state-shutdown property that indicates that a LED
should not be turned off or changed during system shutdown.
Signed-off-by: Eddie James <eajames@linux.ibm.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
json-schema versions draft7 and earlier have a weird behavior in that
any keywords combined with a '$ref' are ignored (silently). The correct
form was to put a '$ref' under an 'allOf'. This behavior is now changed
in the 2019-09 json-schema spec and '$ref' can be mixed with other
keywords. The json-schema library doesn't yet support this, but the
tooling now does a fixup for this and either way works.
This has been a constant source of review comments, so let's change this
treewide so everyone copies the simpler syntax.
Scripted with ruamel.yaml with some manual fixups. Some minor whitespace
changes from the script.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Maxime Ripard <mripard@kernel.org>
Acked-by: Lee Jones <lee.jones@linaro.org>
Acked-By: Vinod Koul <vkoul@kernel.org>
Acked-by: Mark Brown <broonie@kernel.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Wolfram Sang <wsa@the-dreams.de> # for I2C
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> #for-iio
Reviewed-by: Stephen Boyd <sboyd@kernel.org> # clock
Signed-off-by: Rob Herring <robh@kernel.org>
The preferred form for gpio-leds compatible subnodes is:
^led-[0-9a-f]$
Fix example by changing led0 and led1 to led-0 and led-1.
Signed-off-by: Johan Jonker <jbx6244@gmail.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Rob Herring <robh@kernel.org>
Several DT references got broken due to txt->yaml conversion.
Those are auto-fixed by running:
scripts/documentation-file-ref-check --fix
Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org>
Acked-by: Andrew Jeffery <andrew@aj.id.au>
Reviewed-by: Dan Murphy <dmurphy@ti.com>
Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
Convert the common LEDs properties bindings to a schema. As trigger source
providers are different nodes, we need to split trigger source properties
to a separate file.
Bindings for LED controllers can reference the common schema for the LED
child nodes:
patternProperties:
"^led@[0-4]":
type: object
allOf:
- $ref: common.yaml#
Cc: Pavel Machek <pavel@ucw.cz>
Cc: Dan Murphy <dmurphy@ti.com>
Cc: linux-leds@vger.kernel.org
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Rob Herring <robh@kernel.org>
