summaryrefslogtreecommitdiff
path: root/Documentation/ABI/testing/sysfs-class-led
AgeCommit message (Collapse)Author
2025-04-15leds: led-triggers: Improvements for default triggerCraig McQueen
Accept "default" written to sysfs trigger attr. If the text "default" is written to the LED's sysfs 'trigger' attr, then call led_trigger_set_default() to set the LED to its default trigger. If the default trigger is set to "none", then led_trigger_set_default() will remove a trigger. This is in contrast to the default trigger being unset, in which case led_trigger_set_default() does nothing. Signed-off-by: Craig McQueen <craig@mcqueen.au> Reviewed-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Link: https://lore.kernel.org/r/20250317022630.424015-1-craig@mcqueen.au Signed-off-by: Lee Jones <lee@kernel.org>
2023-11-22leds: class: Don't expose color sysfs entryTakashi Iwai
The commit c7d80059b086 ("leds: class: Store the color index in struct led_classdev") introduced a new sysfs entry "color" that is commonly created for the led classdev. Unfortunately, this conflicts with the "color" sysfs entry of already existing drivers such as Logitech HID or System76 ACPI drivers. The driver probe fails due to the conflict, hence it leads to a severe regression with the missing keyboard, for example. This patch reverts partially the change in the commit above for removing the led class color sysfs entries again for addressing the regressions. The newly introduced led_classdev.color field is kept as it's already used by other driver. Fixes: c7d80059b086 ("leds: class: Store the color index in struct led_classdev") Reported-by: Johannes Penßel <johannes.penssel@gmail.com> Closes: https://lore.kernel.org/r/b5646db3-acff-45aa-baef-df3f660486fb@gmail.com Link: https://bugzilla.kernel.org/show_bug.cgi?id=218045 Link: https://bugzilla.kernel.org/show_bug.cgi?id=218155 Link: https://bugzilla.suse.com/show_bug.cgi?id=1217172 Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20231121162359.9332-1-tiwai@suse.de Signed-off-by: Lee Jones <lee@kernel.org>
2023-08-17leds: class: Store the color index in struct led_classdevJean-Jacques Hiblot
Store the color of the LED so that it is not lost after the LED's name has been composed. This color information can then be exposed to the user space or used by the LED consumer. Signed-off-by: Jean-Jacques Hiblot <jjhiblot@traphandler.com> Link: https://lore.kernel.org/r/20230728153731.3742339-3-jjhiblot@traphandler.com Signed-off-by: Lee Jones <lee@kernel.org>
2020-10-30docs: ABI: unify /sys/class/leds/<led>/brightness documentationMauro Carvalho Chehab
This ABI is defined twice, one for normal leds and another one for multicolor ones. Ensure that just one definition is there at ABI. Acked-by: Pavel Machek <pavel@ucw.cz> Acked-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/1115022e7f172b19ee8610f2ad28cc2f0ca93592.1604042072.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-30docs: ABI: cleanup several ABI documentsMauro Carvalho Chehab
There are some ABI documents that, while they don't generate any warnings, they have issues when parsed by get_abi.pl script on its output result. Address them, in order to provide a clean output. Reviewed-by: Tom Rix <trix@redhat.com> # for fpga-manager Reviewed-By: Kajol Jain<kjain@linux.ibm.com> # for sysfs-bus-event_source-devices-hv_gpci and sysfs-bus-event_source-devices-hv_24x7 Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> #for IIO Acked-by: Oded Gabbay <oded.gabbay@gmail.com> # for Habanalabs Acked-by: Vaibhav Jain <vaibhav@linux.ibm.com> # for sysfs-bus-papr-pmem Acked-by: Cezary Rojewski <cezary.rojewski@intel.com> # for catpt Acked-by: Suzuki K Poulose <suzuki.poulose@arm.com> Acked-by: Ilya Dryomov <idryomov@gmail.com> # for rbd Acked-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/5bc78e5b68ed1e9e39135173857cb2e753be868f.1604042072.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2020-10-30docs: ABI: testing: make the files compatible with ReST outputMauro Carvalho Chehab
Some files over there won't parse well by Sphinx. Fix them. Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com> # for IIO Acked-by: Fabrice Gasnier <fabrice.gasnier@st.com> Acked-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/58cf3c2d611e0197fb215652719ebd82ca2658db.1604042072.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-01-29leds: class: Add new optional brightness_hw_changed attributeHans de Goede
Some LEDs may have their brightness level changed autonomously (outside of kernel control) by hardware / firmware. This commit adds support for an optional brightness_hw_changed attribute to signal such changes to userspace (if a driver can detect them): What: /sys/class/leds/<led>/brightness_hw_changed Date: January 2017 KernelVersion: 4.11 Description: Last hardware set brightness level for this LED. Some LEDs may be changed autonomously by hardware/firmware. Only LEDs where this happens and the driver can detect this, will have this file. This file supports poll() to detect when the hardware changes the brightness. Reading this file will return the last brightness level set by the hardware, this may be different from the current brightness. Drivers which want to support this, simply add LED_BRIGHT_HW_CHANGED to their flags field and call led_classdev_notify_brightness_hw_changed() with the hardware set brightness when they detect a hardware / firmware triggered brightness change. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
2016-11-22cleanup LED documentation and make it match realityPavel Machek
sysfs-class-led fails to mention some important details. Also fix led vs LED and english. Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2016-08-29Documentation: move oneshot trigger attributes documentation to ABIRafał Miłecki
Documentation of sysfs interface should be in ABI in the first place. This moves relevant part of documentation and mentions where to look for it. Fix trivial typos whilst we are at it. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
2011-03-31Fix common misspellingsLucas De Marchi
Fixes generated by 'codespell' and manually reviewed. Signed-off-by: Lucas De Marchi <lucas.demarchi@profusion.mobi>
2011-01-13leds: add output inversion option to backlight triggerJanusz Krzysztofik
Extend the LED backlight tirgger driver with an option that allows for inverting the trigger output polarity. With the invertion option provided, I (ab)use the backlight trigger for driving a LED that indicates LCD display blank condtition on my Amstrad Delta videophone. Since the machine has no dedicated power LED, it was not possible to distinguish if the display was blanked, or the machine was turned off, without touching it. The invert sysfs control is patterned after a similiar function of the GPIO trigger driver. [akpm@linux-foundation.org: make output match input, tighten input checking] [akpm@linux-foundation.org: make output match input, tighten input checking] Signed-off-by: Janusz Krzysztofik <jkrzyszt@tis.icnet.pl> Cc: Paul Mundt <lethal@linux-sh.org> Acked-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2009-08-28led: document sysfs interfaceCorentin Chary
Also fix Documentation/led-class.txt, the acceptable range of values for brightness is 0-max_brightness, not 0-255. Cc: Richard Purdie <rpurdie@rpsys.net> Signed-off-by: Corentin Chary <corentincj@iksaif.net> Signed-off-by: Len Brown <len.brown@intel.com>