Lines Matching +full:activate +full:- +full:to +full:- +full:activate
8 of the LED (taking a value 0-max_brightness). Most LEDs don't have hardware
9 brightness support so will just be turned on for non-zero brightness settings.
13 complex. A simple trigger isn't configurable and is designed to slot into
14 existing subsystems with minimal additional code. Examples are the disk-activity,
15 nand-disk and sharpsl-charge triggers. With led triggers disabled, the code
18 Complex triggers while available to all LEDs have LED specific
24 trigger. However, if you set the brightness value to LED_OFF it will
27 You can change triggers in a similar manner to the way an IO scheduler
37 and the aim is to keep a small amount of code giving as much functionality
48 - devicename:
49 it should refer to a unique identifier created by the kernel,
51 than to the hardware; the information related to the product and the bus
52 to which given device is hooked is available in sysfs and can be
57 - color:
59 include/dt-bindings/leds/common.h.
61 - function:
63 include/dt-bindings/leds/common.h.
66 to linux-leds@vger.kernel.org.
70 In this case it is preferable to just concatenate the predefined LED_FUNCTION_*
71 name with required "-N" suffix in the driver. fwnode based drivers can use
72 function-enumerator property for that and then the concatenation will be handled
76 when LED class device is created by a driver of hot-pluggable device and
78 suffix (e.g. "_1", "_2", "_3" etc.) is added to the requested LED class
88 - "red:disk"
89 - "white:flash"
90 - "red:indicator"
91 - "phy1:green:wlan"
92 - "phy3::wlan"
93 - ":kbd_backlight"
94 - "input5::kbd_backlight"
95 - "input3::numlock"
96 - "input3::scrolllock"
97 - "input3::capslock"
98 - "mmc1::status"
99 - "white:status"
107 - input devices
108 - ieee80211 compliant USB devices
110 The script is open to extensions.
112 There have been calls for LED properties such as color to be exported as
124 - led_set_brightness:
125 it is guaranteed not to sleep, passing LED_OFF stops
128 - led_set_brightness_sync:
129 for use cases when immediate effect is desired -
132 blinking, returns -EBUSY if software blink fallback is enabled.
138 A driver wanting to register a LED classdev for use by other drivers /
139 userspace needs to allocate and fill a led_classdev struct and then call
142 free-ing the led_classdev struct.
145 wants to have a brightness_hw_changed attribute then the LED_BRIGHT_HW_CHANGED
153 Some LEDs can be programmed to blink without any CPU interaction. To
155 blink_set() function (see <linux/leds.h>). To set an LED to blinking,
156 however, it is better to use the API function led_blink_set(), as it
159 To turn off blinking, use the API function led_brightness_set()
166 delay_off parameters to the leds subsystem.
168 Setting the brightness to zero with brightness_set() callback function
175 Some LEDs can be programmed to be driven by hardware. This is not
176 limited to blink but also to turn off or on autonomously.
177 To support this feature, a LED needs to implement various additional
178 ops and needs to declare specific support for the supported triggers.
180 With hw control we refer to the LED driven by hardware.
182 LED driver must define the following value to support hw control:
184 - hw_control_trigger:
188 LED driver must implement the following API to support hw control:
189 - hw_control_is_supported:
191 be parsed and activate hw control on the LED.
196 If the passed flags mask is not supported -EOPNOTSUPP
203 - hw_control_set:
204 activate hw control. LED driver will use the provided
205 flags passed from the supported trigger, parse them to
206 a set of mode and setup the LED to be driven by hardware
209 Set LED_OFF via the brightness_set to deactivate hw control.
211 Return 0 on success, a negative error number on failing to
214 - hw_control_get:
225 - hw_control_get_device:
227 hw control. A trigger might use this to match the
231 (example a netdev trigger configured to blink for a
233 to set hw control)
235 Returns a pointer to a struct device or NULL if nothing
238 LED driver can activate additional modes by default to workaround the
240 Examples are hardcoding the blink speed to a set interval, enable special
244 driver and check if the trigger is supported to verify if hw control is possible,
245 use hw_control_is_supported to check if the flags are supported and only at
246 the end use hw_control_set to activate hw control.
248 A trigger can use hw_control_get to check if a LED is already in hw control
259 compared to the benefits the simple trigger functionality brings. The