user/sven/linux.git/Documentation/leds, branch v6.3.3

Merge tag 'leds-next-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds

2023-02-23T23:09:31Z

Pull LED updates from Lee Jones: "Removed Drivers: - HTC ASIC3 LED New Functionality: - Provide generic led_get() which can be used by both DT and !DT platforms Fix-ups: - Convert a bunch of I2C subsystem users to the new probing API - Explicitly provide missing include files - Make use of led_init_default_state_get() and rid the custom variants - Use simplified fwnode_device_is_compatible() API - Provide some Device Tree additions / adaptions - Fix some trivial spelling issues Bug Fixes: - Prevent device refcount leak during led_put() and of_led_get() - Clear previous data from temporary led_pwm structure before processing next child - Fix Clang's warning about incompatible function types when using devm_add_action*()" * tag 'leds-next-6.3' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (41 commits) leds: Remove ide-disk trigger dt-bindings: leds: Add disk write/read and usb-host/usb-gadget Documentation: leds: Correct spelling dt-bindings: leds: Document Bluetooth and WLAN triggers leds: Remove asic3 driver leds: simatic-ipc-leds-gpio: Make sure we have the GPIO providing driver leds: tca6507: Convert to use fwnode_device_is_compatible() leds: syscon: Get rid of custom led_init_default_state_get() leds: pm8058: Get rid of custom led_init_default_state_get() leds: pca955x: Get rid of custom led_init_default_state_get() leds: mt6360: Get rid of custom led_init_default_state_get() leds: mt6323: Get rid of custom led_init_default_state_get() leds: bcm6358: Get rid of custom led_init_default_state_get() leds: bcm6328: Get rid of custom led_init_default_state_get() leds: an30259a: Get rid of custom led_init_default_state_get() leds: Move led_init_default_state_get() to the global header leds: Add missing includes and forward declarations in leds.h leds: is31fl319x: Wrap mutex_destroy() for devm_add_action_or_rest() leds: turris-omnia: Convert to i2c's .probe_new() leds: tlc591xx: Convert to i2c's .probe_new() ...

Documentation: leds: Correct spelling

2023-01-30T08:03:46Z

Correct spelling problems for Documentation/leds/ as reported by codespell. Signed-off-by: Randy Dunlap Signed-off-by: Lee Jones Link: https://lore.kernel.org/r/20230127064005.1558-15-rdunlap@infradead.org

docs: leds: fix the following docu build warning

2023-01-26T18:19:53Z

Add leds-qcom-lpg to Documentation/leds/index.rst to fix the following doc build warning. Documentation/leds/leds-qcom-lpg.rst: WARNING: document isn't included in any toctree Signed-off-by: Shuah Khan Link: https://lore.kernel.org/r/20230125154426.12464-1-skhan@linuxfoundation.org Signed-off-by: Jonathan Corbet

leds: qcom-lpg: Require pattern to follow documentation

2022-05-24T20:08:10Z

The leds-trigger-pattern documentation describes how the brightness of the LED should transition linearly from one brightness value to the next, over the given delta_t. But the pattern engine in the Qualcomm LPG hardware only supports holding the brightness for each entry for the period. This subset of patterns can be represented in the leds-trigger-pattern by injecting zero-time transitions after each entry in the pattern, resulting in a pattern that pattern that can be rendered by the LPG. Rework LPG pattern interface to require these zero-time transitions, to make it comply with this subset of patterns and reject the patterns it can't render. Fixes: 24e2d05d1b68 ("leds: Add driver for Qualcomm LPG") Signed-off-by: Bjorn Andersson Signed-off-by: Pavel Machek

leds: Add driver for Qualcomm LPG

2022-05-04T07:17:31Z

The Light Pulse Generator (LPG) is a PWM-block found in a wide range of PMICs from Qualcomm. These PMICs typically comes with 1-8 LPG instances, with their output being routed to various other components, such as current sinks or GPIOs. Each LPG instance can operate on fixed parameters or based on a shared lookup-table, altering the duty cycle over time. This provides the means for hardware assisted transitions of LED brightness. A typical use case for the fixed parameter mode is to drive a PWM backlight control signal, the driver therefor allows each LPG instance to be exposed to the kernel either through the LED framework or the PWM framework. A typical use case for the LED configuration is to drive RGB LEDs in smartphones etc, for which the driver supports multiple channels to be ganged up to a MULTICOLOR LED. In this configuration the pattern generators will be synchronized, to allow for multi-color patterns. The idea of modelling this as a LED driver ontop of a PWM driver was considered, but setting the properties related to patterns does not fit in the PWM API. Similarly the idea of just duplicating the lower bits in a PWM and LED driver separately was considered, but this would not allow the PWM channels and LEDs to be configured on a per-board basis. The driver implements the more complex LED interface, and provides a PWM interface on the side of that, in the same driver. Signed-off-by: Bjorn Andersson Tested-by: Douglas Anderson Tested-by: Luca Weiss Reviewed-by: Marijn Suijten Tested-by: Marijn Suijten [On the Sony Xperia Nile Discovery, SDM630] Signed-off-by: Pavel Machek

leds: add new LED_FUNCTION_PLAYER for player LEDs for game controllers.

2021-10-27T07:49:29Z

Player LEDs are commonly found on game controllers from Nintendo and Sony to indicate a player ID across a number of LEDs. For example, "Player 2" might be indicated as "-x--" on a device with 4 LEDs where "x" means on. This patch introduces LED_FUNCTION_PLAYER1-5 defines to properly indicate player LEDs from the kernel. Until now there was no good standard, which resulted in inconsistent behavior across xpad, hid-sony, hid-wiimote and other drivers. Moving forward new drivers should use LED_FUNCTION_PLAYERx. Note: management of Player IDs is left to user space, though a kernel driver may pick a default value. Signed-off-by: Roderick Colenbrander Acked-by: Pavel Machek Signed-off-by: Jiri Kosina

Documentation: leds: standartizing LED names

2021-08-20T08:26:24Z

We have a list of valid functions, but LED names in sysfs are still far from being consistent. Create list of "well known" LED names so we nudge people towards using same LED names (except color) for same functionality. Signed-off-by: Pavel Machek

Documentation: Add leading slash to some paths

2021-03-31T19:49:19Z

Change multiple sys/xyz to /sys/xyz Signed-off-by: Mark O'Donovan Link: https://lore.kernel.org/r/20210328152837.73347-1-shiftee@posteo.net Signed-off-by: Jonathan Corbet

Merge tag 'leds-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds

2020-12-16T22:56:29Z

Pull LED updates from Pavel Machek: "Small cleanups/fixes mostly thanks to Marek, nothing major made it in this time" * tag 'leds-5.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: leds: turris-omnia: check for LED_COLOR_ID_RGB instead LED_COLOR_ID_MULTI leds: turris-omnia: fix checkpatch warning leds: turris-omnia: wrap to 80 columns leds: turris-omnia: use constants instead of macros for color command dt-bindings: leds: Convert pwm to yaml leds: lp50xx: Fix an error handling path in 'lp50xx_probe_dt()' leds: netxbig: add missing put_device() call in netxbig_leds_get_of_pdata() Documentation: leds: remove invalidated information

docs: leds: index.rst: add a missing file

2020-11-02T12:45:37Z

Changeset 26a07553041e ("docs: ABI: sysfs-class-led-trigger-pattern: remove hw_pattern duplication") didn't include the needed changes at index.rst. Fixes: 26a07553041e ("docs: ABI: sysfs-class-led-trigger-pattern: remove hw_pattern duplication") Signed-off-by: Mauro Carvalho Chehab Link: https://lore.kernel.org/r/36a6e3aef6e57ea349f1b47c7731d4cd1e03ca77.1604312590.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman