| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
On Apollo Lake the pinctrl drivers will now come up without ACPI. Use
that instead of open coding it.
Create a new driver for that which can later be filled with more GPIO
based models, and which has different dependencies.
Signed-off-by: Henning Schild <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
Since we have a common P2SB accessor in tree we may use it instead of
open coded variants.
Replace custom code by p2sb_bar() call.
Signed-off-by: Henning Schild <[email protected]>
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Lee Jones <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc
Pull more ARM multiplatform updates from Arnd Bergmann:
"The second part of the multiplatform changes now converts the
Intel/Marvell PXA platform along with the rest. The patches went
through several rebases before the merge window as bugs were found, so
they remained separate.
This has to touch a lot of drivers, in particular the touchscreen,
pcmcia, sound and clk bits, to detach the driver files from the
platform and board specific header files"
* tag 'arm-multiplatform-5.19-2' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc: (48 commits)
ARM: pxa/mmp: remove traces of plat-pxa
ARM: pxa: convert to multiplatform
ARM: pxa/sa1100: move I/O space to PCI_IOBASE
ARM: pxa: remove support for MTD_XIP
ARM: pxa: move mach/*.h to mach-pxa/
ARM: PXA: fix multi-cpu build of xsc3
ARM: pxa: move plat-pxa to drivers/soc/
ARM: mmp: rename pxa_register_device
ARM: mmp: remove tavorevb board support
ARM: pxa: remove unused mach/bitfield.h
ARM: pxa: move clk register definitions to driver
ARM: pxa: move smemc register access from clk to platform
cpufreq: pxa3: move clk register access to clk driver
ARM: pxa: remove get_clk_frequency_khz()
ARM: pxa: pcmcia: move smemc configuration back to arch
ASoC: pxa: i2s: use normal MMIO accessors
ASoC: pxa: ac97: use normal MMIO accessors
ASoC: pxa: use pdev resource for FIFO regs
Input: wm97xx - get rid of irq_enable method in wm97xx_mach_ops
Input: wm97xx - switch to using threaded IRQ
...
|
|
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 <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Returning an error value from an i2c remove callback results in an error
message being emitted by the i2c core, but otherwise it doesn't make a
difference. The device goes away anyhow and the devm cleanups are
called.
As stk3310_set_state() already emits an error message on failure and the
additional error message by the i2c core doesn't add any useful
information, don't pass the error value up the stack. Instead continue
to clean up and return 0.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
The Qualcomm LPG driver fails to probe unless PWM support is enabled so
add the missing Kconfig dependency.
Fixes: 24e2d05d1b68 ("leds: Add driver for Qualcomm LPG")
Signed-off-by: Johan Hovold <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Make the AUX pin optional, since it isn't a core part of functionality,
and the device is designed to be operational with only one CTRL pin.
Reviewed-by: Andy Shevchenko <[email protected]>
Signed-off-by: Markuss Broks <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Use dev_err_probe instead of dev_err to avoid duplicate error
messages if the GPIO allocation makes the probe defer.
Signed-off-by: Markuss Broks <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Returning an error value in an i2c remove callback results in a generic
error message being emitted by the i2c core, but otherwise it doesn't make
a difference. The device goes away anyhow and the devm cleanups are
called.
So instead of triggering the generic i2c error message, emit a more helpful
message if a problem occurs and return 0 to suppress the generic message.
This patch is a preparation for making i2c remove callbacks return void.
Signed-off-by: Uwe Kleine-König <[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 regulator LED can easily be adapted to probe from the
device tree.
We switch led_classdev_register() to led_classdev_register_ext()
passing some struct led_init_data init_data that we leave NULL
save the fwnode if platform data isn't present so that it will be
populated from the device tree.
If we have platform data we set up the name from the platform
data but using init_data instead.
Cc: Antonio Ospite <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Instead of repeating the hard to read &pdev->dev just create a
local struct device *dev in probe().
Cc: Antonio Ospite <[email protected]>
Signed-off-by: Linus Walleij <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Up to now pca9532_destroy_devices() returns always zero because it's
always called with data != NULL. Remove the never-taken error path and
make it return void which makes it easier to see in the callers that
there is no error to handle.
Also the return value of i2c remove callbacks is ignored anyway.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Add pm8350c compatible and lpg_data to the driver.
Signed-off-by: Satya Priya <[email protected]>
Reviewed-by: Matthias Kaehlcke <[email protected]>
Reviewed-by: Stephen Boyd <[email protected]>
Reviewed-by: Bjorn Andersson <[email protected]>
Tested-by: Douglas Anderson <[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]>
|
|
The mach/hardware.h is included in lots of places, and it provides
three different things on pxa:
- the cpu_is_pxa* macros
- an indirect inclusion of mach/addr-map.h
- the __REG() and io_pv2() helper macros
Split it up into separate <linux/soc/pxa/cpu.h> and mach/pxa-regs.h
headers, then change all the files that use mach/hardware.h to
include the exact set of those three headers that they actually
need, allowing for further more targeted cleanup.
linux/soc/pxa/cpu.h can remain permanently exported and is now in
a global location along with similar headers. pxa-regs.h and
addr-map.h are only used in a very small number of drivers now
and can be moved to arch/arm/mach-pxa/ directly when those drivers
are to pass the necessary data as resources.
Cc: Michael Turquette <[email protected]>
Cc: Stephen Boyd <[email protected]>
Acked-by: Viresh Kumar <[email protected]>
Acked-by: Dmitry Torokhov <[email protected]>
Cc: Jacek Anaszewski <[email protected]>
Cc: Pavel Machek <[email protected]>
Acked-by: Ulf Hansson <[email protected]>
Cc: Dominik Brodowski <[email protected]>
Acked-by: Alexandre Belloni <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Guenter Roeck <[email protected]>
Acked-by: Mark Brown <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Arnd Bergmann <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds
Pull LED updates from Pavel Machek:
"Nothing major here, there are two drivers that need review and did not
make it into this round"
* tag 'leds-5.18-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/pavel/linux-leds:
leds: pca955x: Allow zero LEDs to be specified
leds: pca955x: Make the gpiochip always expose all pins
leds: simatic-ipc-leds: Don't directly deref ioremap_resource() returned ptr
leds: simatic-ipc-leds: Make simatic_ipc_led_mem_res static
leds: lm3692x: Return 0 from remove callback
leds: sgm3140: Add ocs,ocp8110 compatible
dt-bindings: vendor-prefixes: Add ocs prefix
dt-bindings: leds: common: fix unit address in max77693 example
|
|
It's valid to use the PCA955x devices just for GPIOs and not for LEDs.
In this case, as PCA955X_TYPE_GPIO is now equivalent to
PCA955X_TYPE_NONE, remove the test for whether we have any child nodes
specified in the devicetree.
A consequence of this is it's now possible to bind the driver to a
PCA955x device when dynamically instantiated through the I2C subsystem's
`new_device` interface.
Signed-off-by: Andrew Jeffery <[email protected]>
Reviewed-by: Andy Shevchenko <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Reviewed-by: Joel Stanley <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
The devicetree binding allows specifying which pins are GPIO vs LED.
Limiting the instantiated gpiochip to just these pins as the driver
currently does requires an arbitrary mapping between pins and GPIOs, but
such a mapping is not implemented by the driver. As a result,
specifying GPIOs in such a way that they don't map 1-to-1 to pin indexes
does not function as expected.
Establishing such a mapping is more complex than not and even if we did,
doing so leads to a slightly hairy userspace experience as the behaviour
of the PCA955x gpiochip would depend on how the pins are assigned in the
devicetree. Instead, always expose all pins via the gpiochip to provide
a stable interface and track which pins are in use.
Specifying a pin as `type = <PCA955X_TYPE_GPIO>;` in the devicetree
becomes a no-op.
I've assessed the impact of this change by looking through all of the
affected devicetrees as of the tag leds-5.15-rc1:
```
$ git grep -l 'pca955[0123]' $(find . -name dts -type d)
arch/arm/boot/dts/aspeed-bmc-ibm-everest.dts
arch/arm/boot/dts/aspeed-bmc-ibm-rainier.dts
arch/arm/boot/dts/aspeed-bmc-opp-mihawk.dts
arch/arm/boot/dts/aspeed-bmc-opp-mowgli.dts
arch/arm/boot/dts/aspeed-bmc-opp-swift.dts
arch/arm/boot/dts/aspeed-bmc-opp-tacoma.dts
arch/arm/boot/dts/aspeed-bmc-opp-witherspoon.dts
```
These are all IBM-associated platforms. I've analysed both the
devicetrees and schematics where necessary to determine whether any
systems hit the hazard of the current broken behaviour. For the most
part, the systems specify the pins as either all LEDs or all GPIOs, or
at least do so in a way such that the broken behaviour isn't exposed.
The main counter-point to this observation is the Everest system whose
devicetree describes a large number of PCA955x devices and in some cases
has pin assignments that hit the hazard. However, there does not seem to
be any use of the affected GPIOs in the userspace associated with
Everest.
Regardless, any use of the hazardous GPIOs in Everest is already broken,
so let's fix the interface and then fix any already broken userspace
with it.
Signed-off-by: Andrew Jeffery <[email protected]>
Acked-by: Linus Walleij <[email protected]>
Reviewed-by: Cédric Le Goater <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Sparse (rightly) currently gives the following warning:
drivers/leds/simple/simatic-ipc-leds.c:155:40:
sparse: sparse: incorrect type in assignment (different address spaces)
expected void *static [toplevel] simatic_ipc_led_memory
got void [noderef] __iomem *
Fix this by changing the type of simatic_ipc_led_memory to void __iomem *
and use readl()/writel() to access it.
Cc: Henning Schild <[email protected]>
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Tested-by: Gerd Haeussler <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
simatic_ipc_led_mem_res is not used outside of the driver, make it static.
Cc: Henning Schild <[email protected]>
Reported-by: kernel test robot <[email protected]>
Signed-off-by: Hans de Goede <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
The only difference between returning zero or a non-zero value is that
for the non-zero case the i2c will print a generic error message
("remove failed (-ESOMETHING), will be ignored").
In this case however the driver itself already emitted a more helpful
error message, so the additional error message isn't helpful at all.
The long-term goal is to make the i2c remove callback return void, making
all implementations return 0 is preparatory work for this change.
Signed-off-by: Uwe Kleine-König <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Orient-Chip's ocp8110 has the same pin configuration as the sgm3140.
The data sheet can be found at:
https://cdn.datasheetspdf.com/pdf-down/O/C/P/OCP8110-OrientChip.pdf
Signed-off-by: André Apitzsch <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
The value returned by an spi driver's remove function is mostly ignored.
(Only an error message is printed if the value is non-zero that the
error is ignored.)
So change the prototype of the remove function to return no value. This
way driver authors are not tempted to assume that passing an error to
the upper layer is a good idea. All drivers are adapted accordingly.
There is no intended change of behaviour, all callbacks were prepared to
return 0 before.
Signed-off-by: Uwe Kleine-König <[email protected]>
Acked-by: Marc Kleine-Budde <[email protected]>
Acked-by: Andy Shevchenko <[email protected]>
Reviewed-by: Geert Uytterhoeven <[email protected]>
Acked-by: Jérôme Pouiller <[email protected]>
Acked-by: Miquel Raynal <[email protected]>
Acked-by: Jonathan Cameron <[email protected]>
Acked-by: Claudius Heine <[email protected]>
Acked-by: Stefan Schmidt <[email protected]>
Acked-by: Alexandre Belloni <[email protected]>
Acked-by: Ulf Hansson <[email protected]> # For MMC
Acked-by: Marcus Folkesson <[email protected]>
Acked-by: Łukasz Stelmach <[email protected]>
Acked-by: Lee Jones <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Mark Brown <[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
|
|
Commit a5d3d1adc95f ("leds: lp55xx: Initialize enable GPIO direction to
output") attempts to fix this, but the fix did not work since at least
for the Nokia N900 the value needs to be set to HIGH, per the device
tree. So rather than hardcoding the value to a potentially invalid value
for some devices, let's set direction in lp55xx_init_device.
Fixes: a5d3d1adc95f ("leds: lp55xx: Initialize enable GPIO direction to output")
Fixes: 92a81562e695 ("leds: lp55xx: Add multicolor framework support to lp55xx")
Fixes: ac219bf3c9bd ("leds: lp55xx: Convert to use GPIO descriptors")
Signed-off-by: Merlijn Wajer <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
output of dev_of_node() is already assigned to "np" variable in
ktd2692_parse_dt(). Use "np" variable to check if OF node is NULL
instead of calling dev_of_node() again.
Signed-off-by: Lad Prabhakar <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
GPIO library does copy the of_node from the parent device of
the GPIO chip, there is no need to repeat this in the individual
drivers. Remove assignment here.
For the details one may look into the of_gpio_dev_init() implementation.
Call graph:
--> sso_gpio_gc_init()
--> devm_gpiochip_add_data
--> devm_gpiochip_add_data_with_key
--> gpiochip_add_data_with_key()
--> of_gpio_dev_init()
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
GPIO library does copy the of_node from the parent device of
the GPIO chip, there is no need to repeat this in the individual
drivers. Remove assignment here.
For the details one may look into the of_gpio_dev_init() implementation.
Call graph:
--> tca6507_probe_gpios()
--> gpiochip_add_data()
--> gpiochip_add_data_with_key()
--> of_gpio_dev_init()
Signed-off-by: Andy Shevchenko <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
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]>
|
|
During code review this unused variable was found. Remove it.
Signed-off-by: Sven Schuchmann <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Update a newly created device's fwnode and of_node pointers using the
recently added device_set_node helper. This keeps some firmware node
specifics out of led-class and should help tracking future changes
regarding device firmware node updates.
Signed-off-by: Sander Vanheule <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Use the macro 'swap()' defined in 'include/linux/minmax.h' to avoid
opencoding it.
Signed-off-by: Yihao Han <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Add MT6360 LED driver include 2-channel Flash LED with torch/strobe mode,
3-channel RGB LED support Register/Flash/Breath Mode, and 1-channel for
moonlight LED.
Signed-off-by: Gene Chen <[email protected]>
Acked-by: Jacek Anaszewski <[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 CPU trigger is invoked on ARM from CPU-idle. That trigger later
invokes led_trigger_event() which may invoke the callback of the actual driver.
That driver can acquire a spinlock_t which is okay on kernel without
PREEMPT_RT. On a PREEMPT_RT enabled kernel this lock is turned into a
sleeping lock and must not be acquired with disabled interrupts.
Disable the CPU trigger on PREEMPT_RT.
Signed-off-by: Sebastian Andrzej Siewior <[email protected]>
Link: https://lkml.kernel.org/r/[email protected]
Signed-off-by: Pavel Machek <[email protected]>
|
|
Even with the previous commit 27af8e2c90fb
("leds: trigger: fix potential deadlock with libata")
to this file, we still get lockdep unhappy, and Boqun
explained the report here:
https://lore.kernel.org/r/YNA+d1X4UkoQ7g8a@boqun-archlinux
Effectively, this means that the read_lock_irqsave() isn't
enough here because another CPU might be trying to do a
write lock, and thus block the readers.
This is all pretty messy, but it doesn't seem right that
the LEDs framework imposes some locking requirements on
users, in particular we'd have to make the spinlock in the
iwlwifi driver always disable IRQs, even if we don't need
that for any other reason, just to avoid this deadlock.
Since writes to the led_cdevs list are rare (and are done
by userspace), just switch the list to RCU. This costs a
synchronize_rcu() at removal time so we can ensure things
are correct, but that seems like a small price to pay for
getting lock-free iterations and no deadlocks (nor any
locking requirements imposed on users.)
Signed-off-by: Johannes Berg <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
gcc-11 warns when building with W=1:
drivers/leds/led-class-flash.c: In function 'flash_fault_show':
drivers/leds/led-class-flash.c:210:16: error: 'sprintf' argument 3 overlaps destination object 'buf' [-Werror=restrict]
210 | return sprintf(buf, "%s\n", buf);
| ^~~~~~~~~~~~~~~~~~~~~~~~~
drivers/leds/led-class-flash.c:187:54: note: destination object referenced by 'restrict'-qualified argument 1 was declared here
187 | struct device_attribute *attr, char *buf)
| ~~~~~~^~~
There is no need for the sprintf() here when a strcat() does
the same thing without invoking undefined behavior.
Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
The deprecated i2c probe functionality doesn't work with OF
compatible strings, as it only checks for the i2c device id. Switch
to the new way of probing and grab the match data to select the
chip type.
Signed-off-by: Eddie James <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Much of the fwnode processing in the PCA955x driver is now in the
LEDs core driver, so pass the fwnode in the init data when
registering the LED device. In order to preserve the existing naming
scheme, check for an empty name and set it to the LED number.
Signed-off-by: Eddie James <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
In order to retain the LED state after a system reboot, check the
documented default-state device tree property during initialization.
Modify the behavior of the probe according to the property.
Signed-off-by: Eddie James <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Add a function to fetch the state of the hardware LED.
Signed-off-by: Eddie James <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Format the code. Add some variables to help shorten lines.
Signed-off-by: Eddie James <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Read the retain-state-shutdown device tree property to set the
existing LED_RETAIN_AT_SHUTDOWN flag. Then check the flag when
unregistering, and if set, don't set the brightness to OFF. This
is useful for systems that want to keep the HW state of the LED
across reboots.
Signed-off-by: Eddie James <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Commit b7fb14d3ac63 ("ide: remove the legacy ide driver") removes the
definition of the config IDE_GD_ATA.
So, remove the obsolete reference in ./drivers/leds/trigger/Kconfig.
Signed-off-by: Lukas Bulwahn <[email protected]>
Signed-off-by: Pavel Machek <[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]>
|
|
This patch adds support for "default-state" devicetree property, which
allows to defer pwm init to first use of led.
This allows to configure the PWM early in bootloader to let the LED
blink until an application in Linux userspace sets something different.
Signed-off-by: Denis Osterland-Heim <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
This patch introduces a new function to read initial
default_state from fwnode.
Suggested-by: Pavel Machek <[email protected]>
Signed-off-by: Denis Osterland-Heim <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|
|
Adjust initialization not to trigger Coverity warnings.
Reported-by: Colin Ian King <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>
|