linux/Documentation/leds, branch v4.15

Documentation: leds: Update 00-INDEX file

2017-10-23T18:17:03Z

Add missing entries for the following documentation files: - leds-class-flash.txt - leds-lm3556.txt - leds-mlxcpld.txt - ledtrig-usbport.txt - uleds.txt Signed-off-by: Jacek Anaszewski Acked-by: Pavel Machek

Documentaion: leds: leds-lp55xx.txt: Fix typos

2017-03-17T19:06:14Z

Fix spelling mistakes in leds-lp55xx.txt file to make documentation clear. Signed-off-by: Tamara Diaconita Signed-off-by: Jonathan Corbet

leds: class: Add new optional brightness_hw_changed attribute

2017-01-29T18:59:42Z

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//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 Acked-by: Pavel Machek Signed-off-by: Jacek Anaszewski

leds/leds-lp5523.txt: make documentation match reality

2016-11-22T11:07:02Z

Files are visible all the time, so remove incorrect notes. Signed-off-by: Pavel Machek Signed-off-by: Jacek Anaszewski

leds: Introduce userspace LED class driver

2016-11-22T11:07:02Z

This driver creates a userspace leds driver similar to uinput. New LEDs are created by opening /dev/uleds and writing a uleds_user_dev struct. A new LED class device is registered with the name given in the struct. Reading will return a single byte that is the current brightness. The poll() syscall is also supported. It will be triggered whenever the brightness changes. Closing the file handle to /dev/uleds will remove the leds class device. Signed-off-by: David Lechner Signed-off-by: Jacek Anaszewski

Merge branch 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds

2016-10-04T17:25:53Z

Pull LED driver updates from Jacek Anaszewski: "Three new LED class drivers and some minor fixes and improvementes to the leds-gpio driver, LED Trigger core and documentation" * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds: leds: triggers: Check return value of kobject_uevent_env() leds: triggers: Return from led_trigger_set() if there is nothing to do leds: gpio: fix and simplify error handling in gpio_leds_create leds: gpio: switch to managed version of led_classdev_register leds: gpio: fix and simplify reading property "label" leds: gpio: simplify gpio_leds_create leds: gpio: add helper cdev_to_gpio_led_data leds: gpio: fix an unhandled error case in create_gpio_led leds: gpio: introduce gpio_blink_set_t leds: add driver for Mellanox systems LEDs Documentation: move oneshot trigger attributes documentation to ABI leds: centralize definition of "default-state" property leds: add PM8058 LEDs driver leds: pm8058: add device tree bindings leds: do not overflow sysfs buffer in led_trigger_show leds: make triggers explicitly non-modular DT: leds: Add bindings for ISSI is31fl319x leds: is31fl319x: 1/3/6/9-channel light effect led driver

usb: core: Introduce a USB port LED trigger

2016-09-27T10:20:17Z

This commit adds a new trigger responsible for turning on LED when USB device gets connected to the selected USB port. This can can useful for various home routers that have USB port(s) and a proper LED telling user a device is connected. The trigger gets its documentation file but basically it just requires enabling it and selecting USB ports (e.g. echo 1 > ports/usb1-1). There was a long discussion on design of this driver. Its current state is a result of picking them most adjustable solution as others couldn't handle all cases. 1) It wasn't possible for the driver to register separated trigger for each USB port. Some physical USB ports are handled by more than one controller and so by more than one USB port. E.g. USB 2.0 physical port may be handled by OHCI's port and EHCI's port. It's also not possible to assign more than 1 trigger to a single LED and implementing such feature would be tricky due to syncing triggers and sysfs conflicts with old triggers. 2) Another idea was to register trigger per USB hub. This wouldn't allow handling devices with multiple USB LEDs and controllers (hubs) controlling more than 1 physical port. It's common for hubs to have few ports and each may have its own LED. This final trigger is highly flexible. It allows selecting any USB ports for any LED. It was also modified (comparing to the initial version) to allow choosing ports rather than having user /guess/ proper names. It was successfully tested on SmartRG SR400ac which has 3 USB LEDs, 2 physical ports and 3 controllers. It was noted USB subsystem already has usb-gadget and usb-host triggers but they are pretty trivial ones. They indicate activity only and can't have ports specified. In future it may be good idea to consider adding activity support to usbport as well. This should allow switching to this more generic driver and maybe marking old ones as obsolete. This can be implemented with another sysfs file for setting mode. The default mode wouldn't change so there won't be ABI breakage and so such feature can be safely implemented later. There was also an idea of supporting other devices (PCI, SDIO, etc.) but as this driver already contains some USB specific code (and will get more) these should be probably separated drivers (triggers). Signed-off-by: Rafał Miłecki Signed-off-by: Greg Kroah-Hartman

leds: add driver for Mellanox systems LEDs

2016-09-15T14:49:39Z

This makes it possible to create a set of LEDs for Mellanox systems: "msx6710", "msx6720", "msb7700", "msn2700", "msx1410", "msn2410", "msb7800", "msn2740", "msn2100". Driver obtains LED devices according to system configuration, provided through system DMI data, like mlxcpld:fan1:green, mlxcpld:fan1:red and creates devices in form: "devicename:colour:function". LED setting is controlled through on board CPLD Lattice device. For setting particular LED off, solid, blink: echo 0 > /sys/class/leds/mlxcpld\:status\:green/brightness echo 1 > /sys/class/leds/mlxcpld\:status\:green/brightness echo timer > /sys/class/leds/mlxcpld\:status\:green/trigger On module probing all LEDs are set green, on removing - off. Last setting overwrites previous, f.e. sequence for changing LED from green - red - green: echo 1 > /sys/class/leds/mlxcpld\:psu\:green/brightness echo 1 > /sys/class/leds/mlxcpld\:psu\:red/brightness echo 1 > /sys/class/leds/mlxcpld\:psu\:green/brightness Note: LEDs cannot be turned on/off simultaneously. The Kconfig currently controlling compilation of this code is: drivers/leds/Kconfig:config LEDS_MLXCPLD Signed-off-by: Vadim Pasternak Reviewed-by: Jiri Pirko Reviewed-by: Wei Yongjun Signed-off-by: Jacek Anaszewski

Documentation: move oneshot trigger attributes documentation to ABI

2016-08-29T13:06:32Z

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 Signed-off-by: Jacek Anaszewski

leds: documentation: 'ide-disk' to 'disk-activity'

2016-06-27T06:58:35Z

Signed-off-by: Stephan Linz Cc: Joseph Jezak Cc: Jörg Sommer Acked-by: Mark Rutland Signed-off-by: Jacek Anaszewski