Commit Graph

1623 Commits

Author SHA1 Message Date
Linus Torvalds
96479c0980 ARM: multiplatform changes, part 2
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.
 -----BEGIN PGP SIGNATURE-----
 
 iQIzBAABCgAdFiEEo6/YBQwIrVS28WGKmmx57+YAGNkFAmKZKqsACgkQmmx57+YA
 GNnO/w//dgJBlkmoIIKlG2eJsvoUKwDt7MuLEMCqSqYYUSvMENFwKK66INMDIJ3l
 PmKf94JadlpBm2OB2vzW+D1EtaLGX9eXZkKD+vyB1I1yFkKdzEPcAfitfrRwe58E
 pR4nQd/jVL4UCY+pp442O1q9VvMpMV9P4ILJGPS/PpsD5CT9Gn8m9svIIuNuDRFd
 nwpyZC3l32jVLo9iuLmwZUvxtOWI3hTqZrnxhByBhlvtnGexRsq/VhfubK2uzBi1
 CyWHjqzOSmseGmsUDwv9LFqVV9YRCeisS3IElA5L0VgM0XvHKA+f9qyF7V6zI20g
 y9LtqhdAtiTpE/aUrOW2LDYaM/bc7RilYZrWchoZbCEsHhV4C+ld3QoTyxvGscvG
 tbznhvZKdUNX8LHS0J9NqIj1q1YGN5ei5r/C5R8DBj1q8VcTVnq3dms8xzVTd35o
 xS5BbLFliiI96jc7S6LaQizXheYjAfdPhmXUAxNXvWIVQ6SXnf8/U/RB9Zzjb8hm
 FH2Gu8m/Dh2MHKBBRWSVw8VahV0V7WiEaWeYuwwTbW1wUrsWiizVaPnqrt6Cq9DW
 oJZgBvktWEXUQz73qrnvwo9GjcKqAxaWKWq05hHKHKuLGezsPAyIhIKr51V2xqqw
 cp2OIMCsN5GYENOhHvt6BMRAI5iA4VyFDtWAqw9B6EIwno6N7Z4=
 =cnSb
 -----END PGP SIGNATURE-----

Merge tag 'arm-multiplatform-5.19-2' of 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
  ...
2022-06-02 15:23:54 -07:00
Bjorn Andersson
e98a860f65 leds: qcom-lpg: Require pattern to follow documentation
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: 24e2d05d1b ("leds: Add driver for Qualcomm LPG")
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-05-24 22:08:10 +02:00
Uwe Kleine-König
73bce575ed leds: lp50xx: Remove duplicated error reporting in .remove()
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-05-07 23:20:54 +02:00
Johan Hovold
1d6a1b5e50 leds: qcom-lpg: add missing PWM dependency
The Qualcomm LPG driver fails to probe unless PWM support is enabled so
add the missing Kconfig dependency.

Fixes: 24e2d05d1b ("leds: Add driver for Qualcomm LPG")
Signed-off-by: Johan Hovold <johan+linaro@kernel.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-05-07 23:20:14 +02:00
Markuss Broks
69175786d5 leds: ktd2692: Make aux-gpios optional
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 <andy.shevchenko@gmail.com>
Signed-off-by: Markuss Broks <markuss.broks@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-05-07 23:12:19 +02:00
Markuss Broks
1d3b5aaaa4 leds: ktd2692: Avoid duplicate error messages on probe deferral
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 <markuss.broks@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-05-07 23:12:18 +02:00
Uwe Kleine-König
e1347bd4ab leds: is31fl32xx: Improve error reporting in .remove()
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-05-07 23:10:22 +02:00
Sven Schwermer
818d03b3d4 leds: Move pwm-multicolor driver into rgb directory
The drivers/leds/rgb subdirectory is relatively fresh, so we move this
new PWM multi-color driver into it.

Signed-off-by: Sven Schwermer <sven.schwermer@disruptive-technologies.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-05-07 23:09:31 +02:00
Sven Schwermer
9fa2762110 leds: Add PWM multicolor driver
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 <sven.schwermer@disruptive-technologies.com>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-05-05 10:04:52 +02:00
Linus Walleij
835fc89e24 leds: regulator: Make probeable from device tree
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 <ao2@ao2.it>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-05-05 10:04:52 +02:00
Linus Walleij
4c350c658f leds: regulator: Add dev helper variable
Instead of repeating the hard to read &pdev->dev just create a
local struct device *dev in probe().

Cc: Antonio Ospite <ao2@ao2.it>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-05-05 10:04:52 +02:00
Uwe Kleine-König
c55f75c4f9 leds: pca9532: Make pca9532_destroy_devices() return void
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-05-04 19:37:51 +02:00
Satya Priya
96c59c8ba8 leds: Add pm8350c support to Qualcomm LPG driver
Add pm8350c compatible and lpg_data to the driver.

Signed-off-by: Satya Priya <quic_c_skakit@quicinc.com>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
Reviewed-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Tested-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-05-04 19:31:17 +02:00
Bjorn Andersson
24e2d05d1b leds: Add driver for Qualcomm LPG
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>
2022-05-04 09:17:31 +02:00
Arnd Bergmann
08d3df8c81 ARM: pxa: split up mach/hardware.h
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 <mturquette@baylibre.com>
Cc: Stephen Boyd <sboyd@kernel.org>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Cc: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Cc: Pavel Machek <pavel@ucw.cz>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Dominik Brodowski <linux@dominikbrodowski.net>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Guenter Roeck <linux@roeck-us.net>
Acked-by: Mark Brown <broonie@kernel.org>
Cc: linux-clk@vger.kernel.org
Cc: linux-pm@vger.kernel.org
Cc: linux-input@vger.kernel.org
Cc: linux-leds@vger.kernel.org
Cc: linux-mmc@vger.kernel.org
Cc: linux-mtd@lists.infradead.org
Cc: linux-rtc@vger.kernel.org
Cc: linux-usb@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-fbdev@vger.kernel.org
Cc: linux-watchdog@vger.kernel.org
Cc: alsa-devel@alsa-project.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
2022-04-19 16:27:05 +02:00
Linus Torvalds
dfb0a0b715 LED updates for 5.18-rc1. Nothing major here, there are two drivers
that need review and did not make it.
 -----BEGIN PGP SIGNATURE-----
 
 iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCYj+mOQAKCRAw5/Bqldv6
 8pXqAJ9co9nkfU7H+VIdk4FWHp6w87fDCACeKRIOcG5eK50yoBhMGclvuuC7V5s=
 =gSle
 -----END PGP SIGNATURE-----

Merge tag 'leds-5.18-rc1' of 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
2022-03-27 14:09:48 -07:00
Andrew Jeffery
e26557a0aa leds: pca955x: Allow zero LEDs to be specified
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 <andrew@aj.id.au>
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Joel Stanley <joel@jms.id.au>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-03-02 09:51:40 +01:00
Andrew Jeffery
ca386253ff leds: pca955x: Make the gpiochip always expose all pins
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 <andrew@aj.id.au>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Cédric Le Goater <clg@kaod.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-03-02 09:50:58 +01:00
Hans de Goede
8b43ef06ff leds: simatic-ipc-leds: Don't directly deref ioremap_resource() returned ptr
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 <henning.schild@siemens.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Gerd Haeussler <gerd.haeussler.ext@siemens.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-02-17 12:25:30 +01:00
Hans de Goede
a8f59497a4 leds: simatic-ipc-leds: Make simatic_ipc_led_mem_res static
simatic_ipc_led_mem_res is not used outside of the driver, make it static.

Cc: Henning Schild <henning.schild@siemens.com>
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-02-17 12:25:09 +01:00
Uwe Kleine-König
cf642faef7 leds: lm3692x: Return 0 from remove callback
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 <u.kleine-koenig@pengutronix.de>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-02-12 13:02:50 +01:00
André Apitzsch
77d62fcceb leds: sgm3140: Add ocs,ocp8110 compatible
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 <git@apitzsch.eu>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-02-12 12:27:53 +01:00
Uwe Kleine-König
a0386bba70
spi: make remove callback a void function
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 <u.kleine-koenig@pengutronix.de>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Jérôme Pouiller <jerome.pouiller@silabs.com>
Acked-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Acked-by: Claudius Heine <ch@denx.de>
Acked-by: Stefan Schmidt <stefan@datenfreihafen.org>
Acked-by: Alexandre Belloni <alexandre.belloni@bootlin.com>
Acked-by: Ulf Hansson <ulf.hansson@linaro.org> # For MMC
Acked-by: Marcus Folkesson <marcus.folkesson@gmail.com>
Acked-by: Łukasz Stelmach <l.stelmach@samsung.com>
Acked-by: Lee Jones <lee.jones@linaro.org>
Link: https://lore.kernel.org/r/20220123175201.34839-6-u.kleine-koenig@pengutronix.de
Signed-off-by: Mark Brown <broonie@kernel.org>
2022-02-09 13:00:45 +00:00
Linus Torvalds
d9b5941bb5 LED updates for 5.17. Nothing major is happening here.
I had to rebase at last moment to fix wrong author of one
 commit. Sorry about that.
 -----BEGIN PGP SIGNATURE-----
 
 iF0EABECAB0WIQRPfPO7r0eAhk010v0w5/Bqldv68gUCYd8hdwAKCRAw5/Bqldv6
 8m3sAKC20ddEFW04Mk45Tw72qSyud6vhwQCaAnQy6dcd+zV6LOxosgLZdtXkvx0=
 =CU+X
 -----END PGP SIGNATURE-----

Merge tag 'leds-5.17-rc1' of 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
2022-01-12 16:59:22 -08:00
Merlijn Wajer
9e87a8da74 leds: lp55xx: initialise output direction from dts
Commit a5d3d1adc9 ("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: a5d3d1adc9 ("leds: lp55xx: Initialize enable GPIO direction to output")
Fixes: 92a81562e6 ("leds: lp55xx: Add multicolor framework support to lp55xx")
Fixes: ac219bf3c9 ("leds: lp55xx: Convert to use GPIO descriptors")
Signed-off-by: Merlijn Wajer <merlijn@wizzup.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-01-12 19:43:15 +01:00
Lad Prabhakar
a05f5d0e6a leds: ktd2692: Drop calling dev_of_node() in ktd2692_parse_dt
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 <prabhakar.mahadev-lad.rj@bp.renesas.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-01-12 19:43:15 +01:00
Andy Shevchenko
2702c9be20 leds: lgm-sso: Get rid of duplicate of_node assignment
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 <andriy.shevchenko@linux.intel.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-01-12 19:43:15 +01:00
Andy Shevchenko
27d1a6210d leds: tca6507: Get rid of duplicate of_node assignment
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 <andriy.shevchenko@linux.intel.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-01-12 19:43:15 +01:00
Linus Walleij
b7f1ac9bb6 leds: leds-fsg: Drop FSG3 LED driver
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 <lukas.bulwahn@gmail.com>
Cc: Krzysztof Hałasa <khalasa@piap.pl>
Cc: Rod Whitby <rod@whitby.id.au>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-01-12 19:43:15 +01:00
Sven Schuchmann
6212264be7 leds: lp50xx: remove unused variable
During code review this unused variable was found. Remove it.

Signed-off-by: Sven Schuchmann <schuchmann@schleissheimer.de>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-01-12 19:43:14 +01:00
Sander Vanheule
495b8966f7 leds: led-core: Update fwnode with device_set_node
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 <sander@svanheule.net>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-01-12 19:43:14 +01:00
Yihao Han
fa019ba4f2 leds: tca6507: use swap() to make code cleaner
Use the macro 'swap()' defined in 'include/linux/minmax.h' to avoid
opencoding it.

Signed-off-by: Yihao Han <hanyihao@vivo.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-01-12 19:43:14 +01:00
Gene Chen
679f865206 leds: Add mt6360 driver
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 <gene_chen@richtek.com>
Acked-by: Jacek Anaszewski <jacek.anaszewski@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2022-01-12 19:42:42 +01:00
Henning Schild
8c78e0614e leds: simatic-ipc-leds: add new driver for Siemens Industial PCs
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 <henning.schild@siemens.com>
Acked-by: Pavel Machek <pavel@ucw.cz>
Link: https://lore.kernel.org/r/20211213120502.20661-3-henning.schild@siemens.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2021-12-23 18:09:13 +01:00
Sebastian Andrzej Siewior
97b31c1f8e leds: trigger: Disable CPU trigger on PREEMPT_RT
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 <bigeasy@linutronix.de>
Link: https://lkml.kernel.org/r/20210924111501.m57cwwn7ahiyxxdd@linutronix.de
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-10-13 20:07:57 +02:00
Johannes Berg
2a5a8fa8b2 leds: trigger: use RCU to protect the led_cdevs list
Even with the previous commit 27af8e2c90
("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 <johannes.berg@intel.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-09-27 16:16:42 +02:00
Arnd Bergmann
811b5440c6 led-class-flash: fix -Wrestrict warning
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 <arnd@arndb.de>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-09-27 16:09:42 +02:00
Eddie James
239f32b4f1 leds: pca955x: Switch to i2c probe_new
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 <eajames@linux.ibm.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-20 11:00:08 +02:00
Eddie James
7c48159292 leds: pca955x: Let the core process the fwnode
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 <eajames@linux.ibm.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-20 11:00:08 +02:00
Eddie James
e46cb6d0c7 leds: pca955x: Implement the default-state property
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 <eajames@linux.ibm.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-20 11:00:07 +02:00
Eddie James
7086625fde leds: pca955x: Add brightness_get function
Add a function to fetch the state of the hardware LED.

Signed-off-by: Eddie James <eajames@linux.ibm.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-20 11:00:07 +02:00
Eddie James
2420ae02ce leds: pca955x: Clean up code formatting
Format the code. Add some variables to help shorten lines.

Signed-off-by: Eddie James <eajames@linux.ibm.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-20 11:00:06 +02:00
Eddie James
419066324e leds: leds-core: Implement the retain-state-shutdown property
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 <eajames@linux.ibm.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-20 11:00:06 +02:00
Lukas Bulwahn
5358680e67 leds: trigger: remove reference to obsolete CONFIG_IDE_GD_ATA
Commit b7fb14d3ac ("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 <lukas.bulwahn@gmail.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-18 08:59:47 +02:00
Jan Kundrát
8b624007e7 leds: lp50xx: Fix chip name in KConfig
The 9-channel one is called LP5009, not LP509.

Signed-off-by: Jan Kundrát <jan.kundrat@cesnet.cz>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-18 08:58:21 +02:00
Denis Osterland-Heim
3d3d65bd27 leds: pwm: add support for default-state device property
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 <Denis.Osterland@diehl.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-18 08:27:31 +02:00
Denis Osterland-Heim
791bc41163 leds: move default_state read from fwnode to core
This patch introduces a new function to read initial
default_state from fwnode.

Suggested-by: Pavel Machek <pavel@ucw.cz>
Signed-off-by: Denis Osterland-Heim <Denis.Osterland@diehl.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-18 08:27:30 +02:00
Pavel Machek
654933ae7d leds: flash: Remove redundant initialization of variable ret
Adjust initialization not to trigger Coverity warnings.

Reported-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-16 08:47:08 +02:00
Andy Shevchenko
9cbc861095 leds: lgm-sso: Propagate error codes from callee to caller
The one of the latest change to the driver reveals the problem that
the error codes from callee aren't propagated to the caller of
__sso_led_dt_parse(). Fix this accordingly.

Fixes: 9999908ca1 ("leds: lgm-sso: Put fwnode in any case during ->probe()")
Fixes: c3987cd2bc ("leds: lgm: Add LED controller driver for LGM SoC")
Reported-by: kernel test robot <lkp@intel.com>
Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-07 09:12:45 +02:00
Hans de Goede
64f67b5240 leds: trigger: audio: Add an activate callback to ensure the initial brightness is set
Some 2-in-1s with a detachable (USB) keyboard(dock) have mute-LEDs in
the speaker- and/or mic-mute keys on the keyboard.

Examples of this are the Lenovo Thinkpad10 tablet (with its USB kbd-dock)
and the HP x2 10 series.

The detachable nature of these keyboards means that the keyboard and
thus the mute LEDs may show up after the user (or userspace restoring
old mixer settings) has muted the speaker and/or mic.

Current LED-class devices with a default_trigger of "audio-mute" or
"audio-micmute" initialize the brightness member of led_classdev with
ledtrig_audio_get() before registering the LED.

This makes the software state after attaching the keyboard match the
actual audio mute state, e.g. cat /sys/class/leds/foo/brightness will
show the right value.

But before this commit nothing was actually calling the led_classdev's
brightness_set[_blocking] callback so the value returned by
ledtrig_audio_get() was never actually being sent to the hw, leading
to the mute LEDs staying in their default power-on state, after
attaching the keyboard, even if ledtrig_audio_get() returned a different
state.

This could be fixed by having the individual LED drivers call
brightness_set[_blocking] themselves after registering the LED,
but this really is something which should be done by a led-trigger
activate callback.

Add an activate callback for this, fixing the issue of the
mute LEDs being out of sync after (re)attaching the keyboard.

Cc: Takashi Iwai <tiwai@suse.de>
Fixes: faa2541f5b ("leds: trigger: Introduce audio mute LED trigger")
Reviewed-by: Marek Behún <kabel@kernel.org>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Pavel Machek <pavel@ucw.cz>
2021-08-03 23:57:17 +02:00