| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
With CONFIG_LEDS_CLASS_MULTICOLOR=m, a builtin leds-blinkm driver causes
a link failure:
arm-linux-gnueabi-ld: drivers/leds/leds-blinkm.o: in function `blinkm_set_mc_brightness':
leds-blinkm.c:(.text.blinkm_set_mc_brightness+0xc): undefined reference to `led_mc_calc_color_components'
Add a more specific dependency that only allows multicoler mode to
be enabled for blinkm if it can build and link.
Fixes: 56e8c56c9af0 ("leds: Add multicolor support to BlinkM LED driver")
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Joseph Strauss <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
Add multicolor support to the BlinkM driver, making it easier to control
from userspace. The BlinkM LED is a programmable RGB LED. The driver
currently supports only the regular LED sysfs class, resulting in the
creation of three distinct classes, one for red, green, and blue. The
user then has to input three values into the three seperate brightness
files within those classes. The multicolor LED framework makes the
device easier to control with the multi_intensity file: the user can
input three values at once to form a color, while still controlling the
lightness with the brightness file.
The main struct blinkm_led has changed slightly. The struct led_classdev
for the regular sysfs classes remain. The blinkm_probe function checks
CONFIG_LEDS_BLINKM_MULTICOLOR to decide whether to load the seperate
sysfs classes or the single multicolor one, but never both. The
blinkm_set_mc_brightness() function had to be added to calculate the
three color components and then set the fields of the blinkm_data
structure accordingly.
Signed-off-by: Joseph Strauss <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
Add support for Texas Instruments LP5569 LED driver.
Texas Instruments LP5569 is 9 channels chip with programmable engines.
It almost a copy of LP5523 with fundamental changes to regs order and
regs content.
Has difference in how the clock is handled and doesn't support detecting
clock time automatically, different handling for selftest and different
scheme for the status regs.
LED chip supports ENGINE and MUX to group LED and run precompiled code
with magic values to run patterns. This is loaded via the sysfs entry
and it's passed as a string of ASCII HEX char.
One some devices using this LED Controller (a NBG7815 Router) it was
found loading big precompiled pattern with up to 96 bytes of code. To
have support for this "extended" scenario, hardcode each engine to
support 4 pages of precompiled pattern (128 bytes of code) and 1 page
for each MUX. This gives plenty of space for any kind precompiled
pattern keeping simple logic for page handling of each engine and mux.
Signed-off-by: Christian Marangi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
Convert the module to be property provider agnostic and allow
it to be used on non-OF platforms.
Add mod_devicetable.h include.
Signed-off-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
The ChromeOS Embedded Controller exposes an LED control command.
Expose its functionality through the leds subsystem.
The LEDs are exposed as multicolor devices.
A hardware trigger, which is active by default, is provided to let the
EC itself take over control over the LED.
The driver is designed to be probed via the cros_ec mfd device.
Signed-off-by: Thomas Weißschuh <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
The ExpressWire library does not depend on NEW_LEDS and selecting it
from a subsystem other than LEDs may cause Kconfig warnings:
WARNING: unmet direct dependencies detected for LEDS_EXPRESSWIRE
Depends on [n]: NEW_LEDS [=n] && GPIOLIB [=y]
Selected by [y]:
- BACKLIGHT_KTD2801 [=y] && HAS_IOMEM [=y] && BACKLIGHT_CLASS_DEVICE [=y]
Move it out of the "if NEW_LEDS" block to allow selection from other
subsystems (in particular backlight) without raising this warning.
Reported-by: Arnd Bergmann <[email protected]>
Closes: https://lore.kernel.org/[email protected]
Reported-by: kernel test robot <[email protected]>
Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/
Suggested-by: Daniel Thompson <[email protected]>
Fixes: 25ae5f5f4168 ("leds: Introduce ExpressWire library")
Reviewed-by: Daniel Thompson <[email protected]>
Signed-off-by: Duje Mihanović <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
Along the same lines as making devm_led_classdev_register() declared
extern unconditional, do the same thing for the two sub-classes
that have similar stubs.
The users of these interfaces go to great lengths to allow building
with both the generic leds API and the extended version, but realistically
there is not much use in this, so just simplify it to always rely
on it and remove the confusing fallback logic.
Signed-off-by: Arnd Bergmann <[email protected]>
Acked-by: Greg Kroah-Hartman <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
The ExpressWire protocol is shared between at least KTD2692 and KTD2801
with slight differences such as timings and the former not having a
defined set of pulses for enabling the protocol (possibly because it
does not support PWM unlike KTD2801). Despite these differences the
ExpressWire handling code can be shared between the two, so in
preparation for adding KTD2801 support introduce a library implementing
this protocol.
Suggested-by: Daniel Thompson <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Reviewed-by: Daniel Thompson <[email protected]>
Signed-off-by: Duje Mihanović <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
Convert the driver to be agnostic to the property provider.
LEDS subsytem is not dependent on OF, so no need to make drivers
be a such.
Signed-off-by: Andy Shevchenko <[email protected]>
Reviewed-by: Jernej Skrabec <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
Add support for the Awinic aw20108 device, which belongs to the same LED
drivers family. The new device supports 108 LEDs using a matrix of 12x9
outputs."
Signed-off-by: George Stark <[email protected]>
Signed-off-by: Dmitry Rokosov <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
The MAX5970 is hot swap controller and has 4 indication LED.
Signed-off-by: Patrick Rudolph <[email protected]>
Signed-off-by: Naresh Solanki <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
The AW2013 driver uses devm_regmap_init_i2c, so REGMAP_I2C needs to
be selected.
Otherwise build process may fail with:
ld: drivers/leds/leds-aw2013.o: in function `aw2013_probe':
leds-aw2013.c:345: undefined reference to `__devm_regmap_init_i2c'
Signed-off-by: Dang Huynh <[email protected]>
Acked-by: Nikita Travkin <[email protected]>
Fixes: 59ea3c9faf32 ("leds: add aw2013 driver")
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
Some Allwinner sunxi SoCs, starting with the A100, contain an LED
controller designed to drive RGB LED pixels. Add a driver for it using
the multicolor LED framework, and with LEDs defined in the device tree.
Acked-by: Guo Ren <[email protected]>
Acked-by: Jernej Skrabec <[email protected]>
Acked-by: Palmer Dabbelt <[email protected]>
Signed-off-by: Samuel Holland <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
Add support for enabling MCU controlled mode of the Turris Omnia LEDs
via a LED private trigger called "omnia-mcu". Recall that private LED
triggers will only be listed in the sysfs trigger file for LEDs that
support them (currently there is no user of this mechanism).
When in MCU controlled mode, the user can still set LED color, but the
blinking is done by MCU, which does different things for different LEDs:
- WAN LED is blinked according to the LED[0] pin of the WAN PHY
- LAN LEDs are blinked according to the LED[0] output of the
corresponding port of the LAN switch
- PCIe LEDs are blinked according to the logical OR of the MiniPCIe port
LED pins
In the future I want to make the netdev trigger to transparently offload
the blinking to the HW if user sets compatible settings for the netdev
trigger (for LEDs associated with network devices).
There was some work on this already, and hopefully we will be able to
complete it sometime, but for now there are still multiple blockers for
this, and even if there weren't, we still would not be able to configure
HW controlled mode for the LEDs associated with MiniPCIe ports.
In the meantime let's support HW controlled mode via the private LED
trigger mechanism. If, in the future, we manage to complete the netdev
trigger offloading, we can still keep this private trigger for backwards
compatibility, if needed.
We also set "omnia-mcu" to cdev->default_trigger, so that the MCU keeps
control until the user first wants to take over it. If a different
default trigger is specified in device-tree via the
'linux,default-trigger' property, LED class will overwrite
cdev->default_trigger, and so the DT property will be respected.
Signed-off-by: Marek Behún <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
The PCA995x chips are I2C controlled LED drivers. Each chip has
up to 16 outputs, each one with an individual 8-bit resolution
PWM for brightness control.
Signed-off-by: Isai Gaspar <[email protected]>
Signed-off-by: Marek Vasut <[email protected]> # Basically rewrite the driver
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
This commit adds support for AWINIC AW20036/AW20054/AW20072 LED driver.
This driver supports following AW200XX features:
- Individual 64-level DIM currents
Signed-off-by: Martin Kurbanov <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
In a future patch HAS_IOPORT=n will result in inb()/outb() and friends
not being declared. We thus need to add HAS_IOPORT as dependency for
those drivers using them.
Co-developed-by: Arnd Bergmann <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Niklas Schnelle <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
Currently, LEDS_LM3697 and LEDS_LM36274 depend on LEDS_TI_LMU_COMMON,
which contains the common code to support TI LMU devices. This means
the user is asked about the common code first, followed by the
individual drivers, if their dependencies are met.
Simplify this, and reduce the number of questions by making
LEDS_TI_LMU_COMMON invisible, and letting it be selected when needed.
Signed-off-by: Geert Uytterhoeven <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Link: https://lore.kernel.org/r/91f6efaa48c36320e58b6a312025ae9b39ee206b.1683644796.git.geert+renesas@glider.be
Signed-off-by: Lee Jones <[email protected]>
|
|
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/[email protected]
Signed-off-by: Yauhen Kharuzhy <[email protected]>
Co-developed-by: Hans de Goede <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Lee Jones <[email protected]>
|
|
The device provides 6 channels which can be individually
turned off and on but groups of two channels share a common brightness
register.
Limitation: The GPIO to enable the device is not used yet.
Signed-off-by: Andreas Kemnade <[email protected]>
Reviewed-by: Matti Vaittinen <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
REGMAP is a hidden (not user visible) symbol. Users cannot set it
directly thru "make *config", so drivers should select it instead of
depending on it if they need it.
Consistently using "select" or "depends on" can also help reduce
Kconfig circular dependency issues.
Therefore, change the use of "depends on REGMAP" to "select REGMAP".
Fixes: 3fce8e1eb994 ("leds: TI LMU: Add common code for TI LMU devices")
Signed-off-by: Randy Dunlap <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
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()
...
|
|
Since ASIC3 MFD driver is removed, the LED support is also
obsolete.
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
The s3c24xx platform is gone, so the led driver can be
removed as well.
Reviewed-by: Krzysztof Kozlowski <[email protected]>
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
Convert the module to be property provider agnostic and allow
it to be used on non-OF platforms.
Add mod_devicetable.h include.
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Vincent Knecht <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Setting blink rate using brightness is unusual and should be fixed.
Signed-off-by: Pavel Machek <[email protected]>
|
|
Use the possessive "its" instead of the contraction "it's"
where appropriate.
Signed-off-by: Randy Dunlap <[email protected]>
Cc: Pavel Machek <[email protected]>
Cc: Lee Jones <[email protected]>
Cc: [email protected]
Signed-off-by: Pavel Machek <[email protected]>
|
|
The drivers/leds/rgb subdirectory is relatively fresh, so we move this
new PWM multi-color driver into it.
Signed-off-by: Sven Schwermer <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
By allowing to group multiple monochrome PWM LEDs into multicolor LEDs,
all involved LEDs can be controlled in-sync. This enables using effects
using triggers, etc.
Signed-off-by: Sven Schwermer <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
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 <[email protected]>
Tested-by: Douglas Anderson <[email protected]>
Tested-by: Luca Weiss <[email protected]>
Reviewed-by: Marijn Suijten <[email protected]>
Tested-by: Marijn Suijten <[email protected]>
[On the Sony Xperia Nile Discovery, SDM630]
Signed-off-by: Pavel Machek <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds
Pull LED updates from Pavel Machek:
"Nothing major is happening here"
* tag 'leds-5.17-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds:
leds: lp55xx: initialise output direction from dts
ARM: dts: omap3-n900: Fix lp5523 for multi color
leds: ktd2692: Drop calling dev_of_node() in ktd2692_parse_dt
leds: lgm-sso: Get rid of duplicate of_node assignment
leds: tca6507: Get rid of duplicate of_node assignment
leds: leds-fsg: Drop FSG3 LED driver
leds: lp50xx: remove unused variable
dt-bindings: leds: Replace moonlight with indicator in mt6360 example
leds: led-core: Update fwnode with device_set_node
leds: tca6507: use swap() to make code cleaner
leds: Add mt6360 driver
dt-bindings: leds: Add bindings for MT6360 LED
|
|
The board file using this driver has been deleted and the
FSG3 LEDs can be modeled using a system controller and some
register bit LEDs in the device tree so this driver is no
longer needed.
Reported-by: Lukas Bulwahn <[email protected]>
Cc: Krzysztof Hałasa <[email protected]>
Cc: Rod Whitby <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
This driver adds initial support for several devices from Siemens. It is
based on a platform driver introduced in an earlier commit.
One of the supported machines has GPIO connected LEDs, here we poke GPIO
memory directly because pinctrl does not come up.
Signed-off-by: Henning Schild <[email protected]>
Acked-by: Pavel Machek <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Hans de Goede <[email protected]>
|
|
The 9-channel one is called LP5009, not LP509.
Signed-off-by: Jan Kundrát <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
We created a subdirectory for LED drivers that depend on
CONFIG_LEDS_CLASS_FLASH, and this driver does so let's
move it there.
Cc: Ingi Kim <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
We created a subdirectory for LED drivers that depend on
CONFIG_LEDS_CLASS_FLASH, and this driver does so let's
move it there.
Cc: Dan Murphy <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
We created a subdirectory for LED drivers that depend on
CONFIG_LEDS_CLASS_FLASH, and this driver does so let's
move it there.
Cc: Luca Weiss <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
We created a subdirectory for LED drivers that depend on
CONFIG_LEDS_CLASS_FLASH, and this driver does so let's
move it there.
Signed-off-by: Linus Walleij <[email protected]>
Acked-by: Jacek Anaszewski <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
We created a subdirectory for LED drivers that depend on
CONFIG_LEDS_CLASS_FLASH, and this driver does so let's
move it there.
Signed-off-by: Linus Walleij <[email protected]>
Acked-by: Sakari Ailus <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
We created a subdirectory for LED drivers that depend on
CONFIG_LEDS_CLASS_FLASH, and this driver does so let's
move it there.
Signed-off-by: Linus Walleij <[email protected]>
Acked-by: Jacek Anaszewski <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Device property API allows to gather device resources from different sources,
such as ACPI. Convert the driver to unleash the power of device property API.
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Regmap APIs should be selected, otherwise link can fail
ERROR: modpost: "__devm_regmap_init_i2c" [drivers/leds/leds-lm3532.ko] undefined!
Fixes: bc1b8492c764 ("leds: lm3532: Introduce the lm3532 LED driver")
Cc: Dan Murphy <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
People should really say Y to the LEDS_CLASS prompt.
Signed-off-by: Pavel Machek <[email protected]>
|
|
Remove unnecessary Kconfig symbol LEDS_BLINK
Improve Kconfig help text to make it more useful.
Signed-off-by: Rahul Tanwar <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds
Pull LED updates from Pavel Machek:
"Besides the usual fixes and new drivers, we are changing CLASS_FLASH
to return success to make it easier to work with V4L2 stuff disabled,
and we are getting rid of enum that should have been plain integer
long time ago. I'm slightly nervous about potential warnings, but it
needed to be fixed at some point"
* tag 'leds-5.12-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds:
leds: lp50xx: Get rid of redundant explicit casting
leds: lp50xx: Update headers block to reflect reality
leds: lp50xx: Get rid of redundant check in lp50xx_enable_disable()
leds: lp50xx: Reduce level of dereferences
leds: lp50xx: Switch to new style i2c-driver probe function
leds: lp50xx: Don't spam logs when probe is deferred
leds: apu: extend support for PC Engines APU1 with newer firmware
leds: flash: Fix multicolor no-ops registration by return 0
leds: flash: Add flash registration with undefined CONFIG_LEDS_CLASS_FLASH
leds: lgm: Add LED controller driver for LGM SoC
dt-bindings: leds: Add bindings for Intel LGM SoC
leds: led-core: Get rid of enum led_brightness
leds: gpio: Set max brightness to 1
leds: lm3533: Switch to using the new API kobj_to_dev()
leds: ss4200: simplify the return expression of register_nasgpio_led()
leds: Use DEVICE_ATTR_{RW, RO, WO} macros
|
|
Parallel to serial conversion, which is also called SSO controller,
can drive external shift register for LED outputs, reset or
general purpose outputs.
This driver enables LED support for Serial Shift Output Controller (SSO).
Signed-off-by: Amireddy Mallikarjuna reddy <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
This adds a driver for the Richtek RT8515 dual channel
torch/flash white LED driver.
This LED driver is found in some mobile phones from
Samsung such as the GT-S7710 and GT-I8190.
A V4L interface is added.
We do not have a proper datasheet for the RT8515 but
it turns out that RT9387A has a public datasheet and
is essentially the same chip. We designed the driver
in accordance with this datasheet. The day someone
needs to drive a RT9387A this driver can probably
easily be augmented to handle that chip too.
Sakari Ailus, Pavel Machek and Andy Shevchenko helped
significantly in getting this driver right.
Cc: Sakari Ailus <[email protected]>
Cc: [email protected]
Cc: Stephan Gerhold <[email protected]>
Cc: [email protected]
Cc: [email protected]
Reviewed-by: Sakari Ailus <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Acer Iconia Tab A500 is an Android tablet device which has two LEDs
embedded into the Power Button. Orange LED indicates "battery charging"
status and white LED indicates "wake-up/charge-done" status. The new LED
driver provides control over both LEDs to userspace.
Signed-off-by: Dmitry Osipenko <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
This driver can be compiled on other platforms with small change if
COMPILE_TEST=y.
Signed-off-by: Marek Behún <[email protected]>
Cc: Pavel Machek <[email protected]>
Cc: Dan Murphy <[email protected]>
Cc: Thomas Bogendoerfer <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
These drivers can be compiled without modification when COMPILE_TEST=y:
cobalt-qube, cobalt-raq, netxbig, ns2 and s3c24xx
Signed-off-by: Marek Behún <[email protected]>
Cc: Pavel Machek <[email protected]>
Cc: Dan Murphy <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|