| Age | Commit message (Collapse) | Author |
|---|
|
Change 'dasy-chain' to 'daisy-chain'.
Signed-off-by: Aryabhatta Dey <aryabhattadey35@gmail.com>
Link: https://lore.kernel.org/r/qpnx2m6qo5abvbs65o452gicumxa7n5vnw42e3hxnnm7sou4xn@fvu52tilzujc
Signed-off-by: Lee Jones <lee@kernel.org>
|
|
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
...
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
...
|
|
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
|
|
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>
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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()
...
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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>
|
|
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>
|
|
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>
|
|
Remove notes about vibrations, as that is better done using input
subsystem.
Signed-off-by: Pavel Machek <pavel@ucw.cz>
|
|
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
...
|
|
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]
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
|
|
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>
|
|
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 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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
...
|
|
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
...
|
|
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>
|
|
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>
|
