summaryrefslogtreecommitdiffstats
path: root/Documentation/leds
Commit message (Collapse)AuthorAgeFilesLines
* Merge tag 'leds-next-6.5' of ↵Linus Torvalds2023-07-033-1/+41
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds Pull LED updates from Lee Jones: "New Drivers: - Add support for Intel Cherry Trail Whiskey Cove PMIC LEDs - Add support for Awinic AW20036/AW20054/AW20072 LEDs New Device Support: - Add support for PMI632 LPG to QCom LPG - Add support for PMI8998 to QCom Flash - Add support for MT6331, WLEDs and MT6332 to Mediatek MT6323 PMIC New Functionality: - Implement the LP55xx Charge Pump - Add support for suspend / resume to Intel Cherry Trail Whiskey Cove PMIC - Add support for breathing mode to Intel Cherry Trail Whiskey Cove PMIC - Enable per-pin resolution Pinctrl in LEDs GPIO Fix-ups: - Allow thread to sleep by switching from spinlock to mutex - Add lots of Device Tree bindings / support - Adapt relationships / dependencies driven by Kconfig - Switch I2C drivers from .probe_new() to .probe() - Remove superfluous / duplicate code - Replace strlcpy() with strscpy() for efficiency and overflow prevention - Staticify various functions - Trivial: Fixing coding style - Simplify / reduce code Bug Fixes: - Prevent NETDEV_LED_MODE_LINKUP from being cleared on rename - Repair race between led_set_brightness(LED_{OFF,FULL}) - Fix Oops relating to sleeping in critical sections - Clear LED_INIT_DEFAULT_TRIGGER flag when clearing the current trigger - Do not leak resources in error handling paths - Fix unsigned comparison which can never be negative - Provide missing NULL terminating entries in tables - Fix misnaming issues" * tag 'leds-next-6.5' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (53 commits) leds: leds-mt6323: Adjust return/parameter types in wled get/set callbacks leds: sgm3140: Add richtek,rt5033-led compatible dt-bindings: leds: sgm3140: Document richtek,rt5033 compatible dt-bindings: backlight: kinetic,ktz8866: Add missing type for "current-num-sinks" dt-bindings: leds: Drop unneeded quotes leds: Fix config reference for AW200xx driver leds: leds-mt6323: Add support for WLEDs and MT6332 leds: leds-mt6323: Add support for MT6331 leds leds: leds-mt6323: Open code and drop MT6323_CAL_HW_DUTY macro leds: leds-mt6323: Drop MT6323_ prefix from macros and defines leds: leds-mt6323: Specify registers and specs in platform data dt-bindings: leds: leds-mt6323: Document mt6332 compatible dt-bindings: leds: leds-mt6323: Document mt6331 compatible leds: simatic-ipc-leds-gpio: Introduce more Kconfig switches leds: simatic-ipc-leds-gpio: Split up into multiple drivers leds: simatic-ipc-leds-gpio: Move two extra gpio pins into another table leds: simatic-ipc-leds-gpio: Add terminating entries to gpio tables leds: flash: leds-qcom-flash: Fix an unsigned comparison which can never be negative leds: cht-wcove: Remove unneeded semicolon leds: cht-wcove: Fix an unsigned comparison which can never be negative ...
| * Documentation: leds: Add "rgb:status" pathLuca Weiss2023-05-251-0/+1
| | | | | | | | | | | | | | | | | | The path /sys/class/leds/rgb:status is already widely used with the qcom-lpg driver and others. Document it. Signed-off-by: Luca Weiss <luca@z3ntu.xyz> Link: https://lore.kernel.org/r/20230414-pmi632-v3-3-079d2cada699@z3ntu.xyz Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: cht-wcove: Add support for breathing mode use hw_pattern sysfs APIHans de Goede2023-05-252-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The hw-blinking of the LED controller in the Whiskey Cove PMIC can also be used for a hw-breathing effect. As discussed during review of v2 of the submission of the new leds-cht-wcove driver, the LED subsystem already supports breathing mode on several other LED controllers using the hw_pattern interface. Implement a pattern_set callback to implement breathing mode modelled after the breathing mode supported by the SC27xx breathing light and Crane EL15203000 LED drivers. The Whiskey Cove PMIC's breathing mode is closer to the EL15203000 one then to the SC27xx one since it does not support staying high / low for a specific time, it only supports rise and fall times. As such the supported hw_pattern and the documentation for this is almost a 1:1 copy of the pattern/docs for the EL15203000 breathing mode. Suggested-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Link: https://lore.kernel.org/all/6beed61c-1fc6-6525-e873-a8978f5fbffb@gmail.com/ Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230430195952.862527-4-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
| * leds: Add Intel Cherry Trail Whiskey Cove PMIC LED driverYauhen Kharuzhy2023-05-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for LEDs connected to the Intel Cherry Trail Whiskey Cove PMIC. Charger and general-purpose LEDs are supported. Hardware blinking is implemented, breathing is not. This driver was tested with Lenovo Yoga Book notebook. Changes by Hans de Goede (in response to review of v2): - Since the PMIC is connected to the battery any changes we make to the LED settings are permanent, even surviving reboot / poweroff. Save LED1 register settings on probe() and if auto-/hw-control was enabled on probe() restore the settings on remove() and shutdown(). - Delay switching LED1 to software control mode to first brightness write. - Use dynamically allocated drvdata instead of a global drvdata variable. - Ensure the LED is on when activating blinking. - Fix CHT_WC_LED_EFF_BREATHING val ((3 << 1) rather then BIT(3)). Link: https://lore.kernel.org/r/20190212205901.13037-2-jekhor@gmail.com Signed-off-by: Yauhen Kharuzhy <jekhor@gmail.com> Co-developed-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Hans de Goede <hdegoede@redhat.com> Link: https://lore.kernel.org/r/20230430195952.862527-2-hdegoede@redhat.com Signed-off-by: Lee Jones <lee@kernel.org>
* | Documentation: leds: leds-class: Document new Hardware driven LEDs APIsChristian Marangi2023-05-311-0/+81
|/ | | | | | | | | | | | | | | | Document new Hardware driven LEDs APIs. Some LEDs can be programmed to be driven by hardware. This is not limited to blink but also to turn off or on autonomously. To support this feature, a LED needs to implement various additional ops and needs to declare specific support for the supported triggers. Add documentation for each required value and API to make hw control possible and implementable by both LEDs and triggers. Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Reviewed-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge tag 'leds-next-6.4' of ↵Linus Torvalds2023-05-023-1/+66
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds Pull LED updates from Lee Jones: "New Drivers: - Add support for MediaTek MT6370 LED Indicator - Add support for MediaTek MT6370 Flashlight - Add support for QCOM PMIC Flash - Add support for Rohm BD2606MVV Charge Pump LED New Device Support: - Add support for PMK8550 PWM to QCOM LPG New Functionality: - Add support for high resolution PWM to QCOM LPG Fix-ups: - Kconfig 'depends' and 'select' dependency changes - Remove unused / irrelevant includes - Remove unnecessary checks (already performed further into the call stack) - Trivial: Fix commentary, simplify error messages - Rid 'defined but not used' warnings - Provide documentation - Explicitly provide include files Bug Fixes: - Mark GPIO LED as BROKEN - Fix Kconfig entries - Fix various Smatch staticify reports - Fix error handling (or a lack there of)" * tag 'leds-next-6.4' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds: (30 commits) leds: bd2606mvv: Driver for the Rohm 6 Channel i2c LED driver dt-bindings: leds: Add ROHM BD2606MVV LED docs: leds: ledtrig-oneshot: Fix spelling mistake leds: pwm-multicolor: Simplify an error message dt-bindings: leds: Convert PCA9532 to dtschema leds: rgb: leds-qcom-lpg: Add support for PMK8550 PWM leds: rgb: leds-qcom-lpg: Add support for high resolution PWM dt-bindings: leds-qcom-lpg: Add qcom,pmk8550-pwm compatible string leds: tca6507: Fix error handling of using fwnode_property_read_string leds: flash: Set variables mvflash_{3,4}ch_regs storage-class-specifier to static leds: rgb: mt6370: Correct config name to select in LEDS_MT6370_RGB MAINTAINERS: Add entry for LED devices documentation Documentation: leds: MT6370: Use bullet lists for timing variables Documentation: leds: mt6370: Properly wrap hw_pattern chart Documentation: leds: Add MT6370 doc to the toctree leds: rgb: mt6370: Fix implicit declaration for FIELD_GET docs: leds: Add MT6370 RGB LED pattern document leds: flash: mt6370: Add MediaTek MT6370 flashlight support leds: rgb: mt6370: Add MediaTek MT6370 current sink type LED Indicator support dt-bindings: leds: spmi-flash-led: Add pm6150l compatible ...
| * docs: leds: ledtrig-oneshot: Fix spelling mistakeAlexander Dahl2023-04-201-1/+1
| | | | | | | | | | | | | | | | | | It's no comparison, but a "first this, then that" situation. Signed-off-by: Alexander Dahl <ada@thorsis.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230418113402.188391-1-ada@thorsis.com
| * Documentation: leds: MT6370: Use bullet lists for timing variablesBagas Sanjaya2023-03-291-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The timing description contains list of timing pattern variables, but it uses code block without indentation instead. Switch to bullet list as it is better fit for this purpose. While at it, substitute "load" for "duty" because the variables control timing for current load into the device. Link: https://lore.kernel.org/oe-kbuild-all/202303182310.tB1mUzU7-lkp@intel.com/ Fixes: 4ba9df04b7ac66 ("docs: leds: Add MT6370 RGB LED pattern document") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230319074903.13075-4-bagasdotme@gmail.com
| * Documentation: leds: mt6370: Properly wrap hw_pattern chartBagas Sanjaya2023-03-231-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pattern diagram (chart) of /sys/class/leds/<led>/hw_pattern is wrapped in literal code block. However, the block indentation is interrupted by Icurr axis label, hence below warnings: Documentation/leds/leds-mt6370-rgb.rst:39: WARNING: Literal block ends without a blank line; unexpected unindent. Documentation/leds/leds-mt6370-rgb.rst:41: WARNING: Line block ends without a blank line. Documentation/leds/leds-mt6370-rgb.rst:46: WARNING: Unexpected indentation. Documentation/leds/leds-mt6370-rgb.rst:44: WARNING: Inline substitution_reference start-string without end-string. Fix the chart indentation by adding 4 more spaces so that the axis label is in the code block. Link: https://lore.kernel.org/oe-kbuild-all/202303182310.tB1mUzU7-lkp@intel.com/ Fixes: 4ba9df04b7ac66 ("docs: leds: Add MT6370 RGB LED pattern document") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230319074903.13075-3-bagasdotme@gmail.com
| * Documentation: leds: Add MT6370 doc to the toctreeBagas Sanjaya2023-03-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 4ba9df04b7ac66 ("docs: leds: Add MT6370 RGB LED pattern document") adds documentation for Mediatek MT6370 RGB LED device, but forgets to include it to leds toctree index. Add the missing entry. Link: https://lore.kernel.org/oe-kbuild-all/202303182310.tB1mUzU7-lkp@intel.com/ Fixes: 4ba9df04b7ac66 ("docs: leds: Add MT6370 RGB LED pattern document") Reported-by: kernel test robot <lkp@intel.com> Signed-off-by: Bagas Sanjaya <bagasdotme@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230319074903.13075-2-bagasdotme@gmail.com
| * docs: leds: Add MT6370 RGB LED pattern documentChiYuan Huang2023-03-231-0/+64
| | | | | | | | | | | | | | | | | | | | | | | | Document the MT6370 RGB LED pattern trigger. This simply describe how the pattern works, each timing period, and the pattern diagram for MT6370 RGB LED. Signed-off-by: ChiYuan Huang <cy_huang@richtek.com> Signed-off-by: ChiaEn Wu <chiaen_wu@richtek.com> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/38f1e863b0f099158a63fb6f95056a1cb30d80a0.1678430444.git.chiaen_wu@richtek.com
* | Documentation: LEDs: Describe good names for network LEDsAndrew Lunn2023-04-191-0/+30
|/ | | | | | | | | | | | | | | | | | | Network LEDs can exist in both the MAC and the PHY. Naming is difficult because the netdev name is neither stable or unique, do to commands like ip link set name eth42 dev eth0, and network namesspaces. Give some example names where the MAC and the PHY have unique names based on device tree nodes, or PCI bus addresses. Since the LED can be used for anything which Linux supports for LEDs, avoid using names like activity or link, rather describe the location on the RJ-45, of what the RJ-45 is expected to be used for, WAN/LAN etc. Signed-off-by: Andrew Lunn <andrew@lunn.ch> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
* Merge tag 'leds-next-6.3' of ↵Linus Torvalds2023-02-231-2/+2
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/lee/leds 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 spellingRandy Dunlap2023-01-301-2/+2
| | | | | | | | | | | | | | | | | | Correct spelling problems for Documentation/leds/ as reported by codespell. Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Lee Jones <lee@kernel.org> Link: https://lore.kernel.org/r/20230127064005.1558-15-rdunlap@infradead.org
* | docs: leds: fix the following docu build warningShuah Khan2023-01-261-0/+1
|/ | | | | | | | | | | 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 <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20230125154426.12464-1-skhan@linuxfoundation.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
* leds: qcom-lpg: Require pattern to follow documentationBjorn Andersson2022-05-241-3/+5
| | | | | | | | | | | | | | | | | | | | 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 <bjorn.andersson@linaro.org> Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: Add driver for Qualcomm LPGBjorn Andersson2022-05-041-0/+76
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <bjorn.andersson@linaro.org> Tested-by: Douglas Anderson <dianders@chromium.org> Tested-by: Luca Weiss <luca@z3ntu.xyz> Reviewed-by: Marijn Suijten <marijn.suijten@somainline.org> Tested-by: Marijn Suijten <marijn.suijten@somainline.org> [On the Sony Xperia Nile Discovery, SDM630] Signed-off-by: Pavel Machek <pavel@ucw.cz>
* leds: add new LED_FUNCTION_PLAYER for player LEDs for game controllers.Roderick Colenbrander2021-10-271-0/+14
| | | | | | | | | | | | | | | | | | 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 <roderick.colenbrander@sony.com> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
* Documentation: leds: standartizing LED namesPavel Machek2021-08-201-0/+58
| | | | | | | | | 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 <pavel@ucw.cz>
* Documentation: Add leading slash to some pathsMark O'Donovan2021-03-311-14/+14
| | | | | | | | Change multiple sys/xyz to /sys/xyz Signed-off-by: Mark O'Donovan <shiftee@posteo.net> Link: https://lore.kernel.org/r/20210328152837.73347-1-shiftee@posteo.net Signed-off-by: Jonathan Corbet <corbet@lwn.net>
* Merge tag 'leds-5.11-rc1' of ↵Linus Torvalds2020-12-161-10/+0
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds 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
| * Documentation: leds: remove invalidated informationMarek Behún2020-10-261-10/+0
| | | | | | | | | | | | | | | | | | | | The contents of the Future Development section of leds-class Documentation was invalidated when support for LED-private triggers was merged. Remove this section. Signed-off-by: Marek Behún <kabel@kernel.org> Fixes: 93690cdf3060 ("leds: trigger: add support for LED-private device...") Signed-off-by: Pavel Machek <pavel@ucw.cz>
* | docs: leds: index.rst: add a missing fileMauro Carvalho Chehab2020-11-021-0/+1
| | | | | | | | | | | | | | | | | | | | 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 <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/36a6e3aef6e57ea349f1b47c7731d4cd1e03ca77.1604312590.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* | docs: ABI: sysfs-class-led-trigger-pattern: remove hw_pattern duplicationMauro Carvalho Chehab2020-10-303-0/+168
|/ | | | | | | | | | | | | | | | The ABI files are supposed to be unique. Yet, in the specific case of hw_pattern, there are some duplicated entries as warned by scripts/get_abi.pl: Warning: /sys/class/leds/<led>/hw_pattern is defined 3 times: Documentation/ABI/testing/sysfs-class-led-trigger-pattern:14 Documentation/ABI/testing/sysfs-class-led-driver-sc27xx:0 Documentation/ABI/testing/sysfs-class-led-driver-el15203000:0 Drop the duplication from the ABI files, moving the specific definitions to files inside Documentation/leds. Acked-by: Jonathan Corbet <corbet@lwn.net> Signed-off-by: Mauro Carvalho Chehab <mchehab+huawei@kernel.org> Link: https://lore.kernel.org/r/038e57881550550b298e598f8f9b7f20515cbe15.1604042072.git.mchehab+huawei@kernel.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* leds: we don't want people to use LED subsystem for vibrationsPavel Machek2020-08-171-7/+0
| | | | | | | Remove notes about vibrations, as that is better done using input subsystem. Signed-off-by: Pavel Machek <pavel@ucw.cz>
* Merge tag 'leds-5.9-rc1' of ↵Linus Torvalds2020-08-052-0/+87
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds Pull LED updates from Pavel Machek: "Okay, so... this one is interesting. RGB LEDs are very common, and we need to have some kind of support for them. Multicolor is for arbitrary set of LEDs in one package, RGB is for LEDs that can produce full range of colors. We do not have real multicolor LED that is not RGB in the pipeline, so that one is disabled for now. You can expect this saga to continue with next pull requests" * tag 'leds-5.9-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds: (37 commits) MAINTAINERS: Remove myself as LED subsystem maintainer leds: disallow /sys/class/leds/*:multi:* for now leds: add RGB color option, as that is different from multicolor. Make LEDS_LP55XX_COMMON depend on I2C to fix build errors: Documentation: ABI: leds-turris-omnia: document sysfs attribute leds: initial support for Turris Omnia LEDs dt-bindings: leds: add cznic,turris-omnia-leds binding leds: pattern trigger -- check pattern for validity leds: Replace HTTP links with HTTPS ones leds: trigger: add support for LED-private device triggers leds: lp5521: Add multicolor framework multicolor brightness support leds: lp5523: Update the lp5523 code to add multicolor brightness function leds: lp55xx: Add multicolor framework support to lp55xx leds: lp55xx: Convert LED class registration to devm_* dt-bindings: leds: Convert leds-lp55xx to yaml leds: multicolor: Introduce a multicolor class definition leds: Add multicolor ID to the color ID list dt: bindings: Add multicolor class dt bindings documention leds: lp5523: Fix various formatting issues in the code leds: lp55xx: Fix file permissions to use DEVICE_ATTR macros ...
| * leds: multicolor: Introduce a multicolor class definitionDan Murphy2020-07-222-0/+87
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a multicolor class that groups colored LEDs within a LED node. The multicolor class groups monochrome LEDs and allows controlling two aspects of the final combined color: hue and lightness. The former is controlled via the intensity file and the latter is controlled via brightness file. Signed-off-by: Dan Murphy <dmurphy@ti.com> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Signed-off-by: Pavel Machek <pavel@ucw.cz> [squashed leds: multicolor: Fix camel case in documentation in]
* | Documentation: leds/ledtrig-transient: eliminate duplicated wordRandy Dunlap2020-07-131-1/+1
|/ | | | | | | | | | | | | | | | Drop the doubled word "for". Signed-off-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz> Cc: Jonathan Corbet <corbet@lwn.net> Cc: linux-doc@vger.kernel.org Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com> Cc: Pavel Machek <pavel@ucw.cz> Cc: Dan Murphy <dmurphy@ti.com> Cc: linux-leds@vger.kernel.org Link: https://lore.kernel.org/r/20200707180414.10467-12-rdunlap@infradead.org Signed-off-by: Jonathan Corbet <corbet@lwn.net>
* leds: core: Add support for composing LED class device namesJacek Anaszewski2019-07-251-3/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add generic support for composing LED class device name. The newly introduced led_compose_name() function composes device name according to either <color:function> or <devicename:color:function> pattern, depending on the configuration of initialization data. Backward compatibility with in-driver hard-coded LED class device names is assured thanks to the default_label and devicename properties of newly introduced struct led_init_data. In case none of the aforementioned properties was found, then, for OF nodes, the node name is adopted for LED class device name. At the occassion of amending the Documentation/leds/leds-class.txt unify spelling: colour -> color. Alongside these changes added is a new tool - tools/leds/get_led_device_info.sh. The tool allows retrieving details of a LED class device's parent device, which proves that using vendor or product name for devicename part of LED name doesn't convey any added value since that information had been already available in sysfs. The script performs also basic validation of a LED class device name. Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com> Cc: Baolin Wang <baolin.wang@linaro.org> Cc: Dan Murphy <dmurphy@ti.com> Cc: Daniel Mack <daniel@zonque.org> Cc: Linus Walleij <linus.walleij@linaro.org> Cc: Oleh Kravchenko <oleg@kaa.org.ua> Cc: Sakari Ailus <sakari.ailus@linux.intel.com> Cc: Simon Shields <simon@lineageos.org> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Acked-by: Pavel Machek <pavel@ucw.cz>
* docs: leds: add it to the driver-api bookMauro Carvalho Chehab2019-07-151-1/+1
| | | | | | | | | | | The contents of leds driver docs is messy: it has lots of admin-guide stuff and kernel internal ones, just like other driver subsystems. I'm opting to keep the dir at the same place and just add a link to it. This makes clearer that this require changes. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
* docs: leds: convert to ReSTMauro Carvalho Chehab2019-06-2820-773/+991
| | | | | | | | | | | | | Rename the leds documentation files to ReST, add an index for them and adjust in order to produce a nice html output via the Sphinx build system. At its new index.rst, let's add a :orphan: while this is not linked to the main index.rst file, in order to avoid build warnings. Signed-off-by: Mauro Carvalho Chehab <mchehab+samsung@kernel.org> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
* Documentation: Use "while" instead of "whilst"Will Deacon2018-11-201-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | Whilst making an unrelated change to some Documentation, Linus sayeth: | Afaik, even in Britain, "whilst" is unusual and considered more | formal, and "while" is the common word. | | [...] | | Can we just admit that we work with computers, and we don't need to | use þe eald Englisc spelling of words that most of the world never | uses? dictionary.com refers to the word as "Chiefly British", which is probably an undesirable attribute for technical documentation. Replace all occurrences under Documentation/ with "while". Cc: David Howells <dhowells@redhat.com> Cc: Liam Girdwood <lgirdwood@gmail.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michael Halcrow <mhalcrow@google.com> Cc: Jonathan Corbet <corbet@lwn.net> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Will Deacon <will.deacon@arm.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
* Drop all 00-INDEX files from Documentation/Henrik Austad2018-09-091-32/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a respin with a wider audience (all that get_maintainer returned) and I know this spams a *lot* of people. Not sure what would be the correct way, so my apologies for ruining your inbox. The 00-INDEX files are supposed to give a summary of all files present in a directory, but these files are horribly out of date and their usefulness is brought into question. Often a simple "ls" would reveal the same information as the filenames are generally quite descriptive as a short introduction to what the file covers (it should not surprise anyone what Documentation/sched/sched-design-CFS.txt covers) A few years back it was mentioned that these files were no longer really needed, and they have since then grown further out of date, so perhaps it is time to just throw them out. A short status yields the following _outdated_ 00-INDEX files, first counter is files listed in 00-INDEX but missing in the directory, last is files present but not listed in 00-INDEX. List of outdated 00-INDEX: Documentation: (4/10) Documentation/sysctl: (0/1) Documentation/timers: (1/0) Documentation/blockdev: (3/1) Documentation/w1/slaves: (0/1) Documentation/locking: (0/1) Documentation/devicetree: (0/5) Documentation/power: (1/1) Documentation/powerpc: (0/5) Documentation/arm: (1/0) Documentation/x86: (0/9) Documentation/x86/x86_64: (1/1) Documentation/scsi: (4/4) Documentation/filesystems: (2/9) Documentation/filesystems/nfs: (0/2) Documentation/cgroup-v1: (0/2) Documentation/kbuild: (0/4) Documentation/spi: (1/0) Documentation/virtual/kvm: (1/0) Documentation/scheduler: (0/2) Documentation/fb: (0/1) Documentation/block: (0/1) Documentation/networking: (6/37) Documentation/vm: (1/3) Then there are 364 subdirectories in Documentation/ with several files that are missing 00-INDEX alltogether (and another 120 with a single file and no 00-INDEX). I don't really have an opinion to whether or not we /should/ have 00-INDEX, but the above 00-INDEX should either be removed or be kept up to date. If we should keep the files, I can try to keep them updated, but I rather not if we just want to delete them anyway. As a starting point, remove all index-files and references to 00-INDEX and see where the discussion is going. Signed-off-by: Henrik Austad <henrik@austad.us> Acked-by: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> Just-do-it-by: Steven Rostedt <rostedt@goodmis.org> Reviewed-by: Jens Axboe <axboe@kernel.dk> Acked-by: Paul Moore <paul@paul-moore.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Acked-by: Mark Brown <broonie@kernel.org> Acked-by: Mike Rapoport <rppt@linux.vnet.ibm.com> Cc: [Almost everybody else] Signed-off-by: Jonathan Corbet <corbet@lwn.net>
* Documentation: leds: Update 00-INDEX fileJacek Anaszewski2017-10-231-0/+10
| | | | | | | | | | | | | 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 <jacek.anaszewski@gmail.com> Acked-by: Pavel Machek <pavel@ucw.cz>
* Documentaion: leds: leds-lp55xx.txt: Fix typosTamara Diaconita2017-03-171-1/+1
| | | | | | | | Fix spelling mistakes in leds-lp55xx.txt file to make documentation clear. Signed-off-by: Tamara Diaconita <diaconita.tamara@gmail.com> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
* leds: class: Add new optional brightness_hw_changed attributeHans de Goede2017-01-291-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* leds/leds-lp5523.txt: make documentation match realityPavel Machek2016-11-221-2/+2
| | | | | | | Files are visible all the time, so remove incorrect notes. Signed-off-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
* leds: Introduce userspace LED class driverDavid Lechner2016-11-221-0/+36
| | | | | | | | | | | | | | 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 <david@lechnology.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
* Merge branch 'for-next' of ↵Linus Torvalds2016-10-042-18/+112
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds 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
| * leds: add driver for Mellanox systems LEDsVadim Pasternak2016-09-151-0/+110
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <vadimp@mellanox.com> Reviewed-by: Jiri Pirko <jiri@mellanox.com> Reviewed-by: Wei Yongjun <weiyongjun1@huawei.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
| * Documentation: move oneshot trigger attributes documentation to ABIRafał Miłecki2016-08-291-18/+2
| | | | | | | | | | | | | | | | | | | | 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>
* | usb: core: Introduce a USB port LED triggerRafał Miłecki2016-09-271-0/+41
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 <rafal@milecki.pl> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
* leds: documentation: 'ide-disk' to 'disk-activity'Stephan Linz2016-06-271-1/+1
| | | | | | | | Signed-off-by: Stephan Linz <linz@li-pro.net> Cc: Joseph Jezak <josejx@gentoo.org> Cc: Jörg Sommer <joerg@alea.gnuu.de> Acked-by: Mark Rutland <mark.rutland@arm.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
* leds: core: Fix brightness setting upon hardware blinking enabledTony Makkiel2016-06-081-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 76931edd54f8 ("leds: fix brightness changing when software blinking is active") changed the semantics of led_set_brightness() which according to the documentation should disable blinking upon any brightness setting. Moreover it made it different for soft blink case, where it was possible to change blink brightness, and for hardware blink case, where setting any brightness greater than 0 was ignored. While the change itself is against the documentation claims, it was driven also by the fact that timer trigger remained active after turning blinking off. Fixing that would have required major refactoring in the led-core, led-class, and led-triggers because of cyclic dependencies. Finally, it has been decided that allowing for brightness change during blinking is beneficial as it can be accomplished without disturbing blink rhythm. The change in brightness setting semantics will not affect existing LED class drivers that implement blink_set op thanks to the LED_BLINK_SW flag introduced by this patch. The flag state will be from now on checked in led_set_brightness() which will allow to distinguish between software and hardware blink mode. In the latter case the control will be passed directly to the drivers which apply their semantics on brightness set, which is disable the blinking in case of most such drivers. New drivers will apply new semantics and just change the brightness while hardware blinking is on, if possible. The issue was smuggled by subsequent LED core improvements, which modified the code that originally introduced the problem. Fixes: f1e80c07416a ("leds: core: Add two new LED_BLINK_ flags") Signed-off-by: Tony Makkiel <tony.makkiel@daqri.com> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
* Documentation: leds: Add description of brightness setting APIJacek Anaszewski2016-01-041-0/+13
| | | | | | | | This patch adds description of the LED subsystem API for setting an LED brightness. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com>
* Merge branch 'for-next' of ↵Linus Torvalds2015-07-012-0/+81
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds Pull LED subsystem updates from Bryan Wu: "In this cycle, we finished to merge patches for LED Flash class driver. Other than that we have some bug fixes and new drivers for LED controllers" * 'for-next' of git://git.kernel.org/pub/scm/linux/kernel/git/cooloney/linux-leds: (33 commits) leds:lp55xx: fix firmware loading error leds: fix max77693-led build errors leds: fix aat1290 build errors leds: aat1290: pass flags parameter to devm_gpiod_get leds: ktd2692: pass flags parameter to devm_gpiod_get drivers/leds: don't use module_init in non-modular leds-cobalt-raq.c leds: aat1290: add support for V4L2 Flash sub-device DT: aat1290: Document handling external strobe sources leds: max77693: add support for V4L2 Flash sub-device media: Add registration helpers for V4L2 flash sub-devices v4l: async: Add a pointer to of_node to struct v4l2_subdev, match it Documentation: leds: Add description of v4l2-flash sub-device leds: add BCM6358 LED driver leds: add DT binding for BCM6358 LED controller leds: fix brightness changing when software blinking is active Documentation: leds-lp5523: describe master fader attributes leds: lp5523: add master_fader support leds: leds-gpio: Allow compile test if !GPIOLIB leds: leds-gpio: Add missing #include <linux/of.h> gpiolib: Add missing dummies for the unified device properties interface ...
| * Documentation: leds: Add description of v4l2-flash sub-deviceJacek Anaszewski2015-06-101-0/+51
| | | | | | | | | | | | | | | | | | | | | | This patch extends LED Flash class documention by the description of interactions with v4l2-flash sub-device. Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com> Acked-by: Kyungmin Park <kyungmin.park@samsung.com> Cc: Richard Purdie <rpurdie@rpsys.net> Acked-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
| * Documentation: leds-lp5523: describe master fader attributesToshi Kikuchi2015-05-251-0/+30
| | | | | | | | | | | | | | | | | | Add the usage of the new attributes for master faders. Signed-off-by: Toshi Kikuchi <toshik@chromium.org> Acked-by: Milo Kim <milo.kim@ti.com> Acked-by: Jacek Anaszewski <j.anaszewski@samsung.com> Signed-off-by: Bryan Wu <cooloney@gmail.com>
* | Merge branch 'for-linus' of ↵Linus Torvalds2015-06-241-3/+0
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input Pull input subsystem updates from Dmitry Torokhov: "Thanks to Samuel Thibault input device (keyboard) LEDs are no longer hardwired within the input core but use LED subsystem and so allow use of different triggers; Hans de Goede did a large update for the ALPS touchpad driver; we have new TI drv2665 haptics driver and DA9063 OnKey driver, and host of other drivers got various fixes" * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input: (55 commits) Input: pixcir_i2c_ts - fix receive error MAINTAINERS: remove non existent input mt git tree Input: improve usage of gpiod API tty/vt/keyboard: define LED triggers for VT keyboard lock states tty/vt/keyboard: define LED triggers for VT LED states Input: export LEDs as class devices in sysfs Input: cyttsp4 - use swap() in cyttsp4_get_touch() Input: goodix - do not explicitly set evbits in input device Input: goodix - export id and version read from device Input: goodix - fix variable length array warning Input: goodix - fix alignment issues Input: add OnKey driver for DA9063 MFD part Input: elan_i2c - add product IDs FW names Input: elan_i2c - add support for multi IC type and iap format Input: focaltech - report finger width to userspace tty: remove platform_sysrq_reset_seq Input: synaptics_i2c - use proper boolean values Input: psmouse - use true instead of 1 for boolean values Input: cyapa - fix a few typos in comments Input: stmpe-ts - enforce device tree only mode ...
| * Input: export LEDs as class devices in sysfsSamuel Thibault2015-06-111-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change creates a new input handler called "leds" that exports LEDs on input devices as standard LED class devices in sysfs and allows controlling their state via sysfs or via any of the standard LED triggers. This allows to re-purpose and reassign LDEs on the keyboards to represent states other than the standard keyboard states (CapsLock, NumLock, etc). The old API of controlling input LEDs by writing into /dev/input/eventX devices is still present and will take precedence over accessing via LEDs subsystem (i.e. it may override state set by a trigger). If input device is "grabbed" then requests coming through LED subsystem will be ignored. Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org> Tested-by: Pavel Machek <pavel@ucw.cz> Acked-by: Pavel Machek <pavel@ucw.cz> Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
generated by cgit v1.2.3 (git 2.25.1) at 2024-05-17 04:10:06 +0000