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 <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>
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>
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>
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>
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>
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>
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>
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 <merlijn@wizzup.org>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Signed-off-by: Pavel Machek <pavel@ucw.cz>