BMC/Intel-BMC/linux.git/drivers/leds, branch dev-5.14-intel

leds: pca955x: Allow zero LEDs to be specified

2021-09-24T04:39:15+00:00

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. OpenBMC-Staging-Count: 1 Signed-off-by: Andrew Jeffery Reviewed-by: Joel Stanley Reviewed-by: Linus Walleij Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210921043936.468001-3-andrew@aj.id.au Signed-off-by: Joel Stanley

leds: pca955x: Make the gpiochip always expose all pins

2021-09-24T04:39:15+00:00

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 = ;` 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. OpenBMC-Staging-Count: 1 Signed-off-by: Andrew Jeffery Reviewed-by: Joel Stanley Reviewed-by: Linus Walleij Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20210921043936.468001-2-andrew@aj.id.au Signed-off-by: Joel Stanley

leds: pca955x: Switch to i2c probe_new

2021-09-22T02:36:43+00:00

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. OpenBMC-Staging-Count: 1 Signed-off-by: Eddie James Signed-off-by: Pavel Machek Link: https://lore.kernel.org/r/20210916212140.33915-8-eajames@linux.ibm.com Signed-off-by: Joel Stanley

leds: pca955x: Let the core process the fwnode

2021-09-22T02:36:43+00:00

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. OpenBMC-Staging-Count: 1 Signed-off-by: Eddie James Signed-off-by: Pavel Machek Link: https://lore.kernel.org/r/20210916212140.33915-7-eajames@linux.ibm.com Signed-off-by: Joel Stanley

leds: pca955x: Implement the default-state property

2021-09-22T02:36:42+00:00

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. OpenBMC-Staging-Count: 1 Signed-off-by: Eddie James Signed-off-by: Pavel Machek Link: https://lore.kernel.org/r/20210916212140.33915-6-eajames@linux.ibm.com Signed-off-by: Joel Stanley

leds: pca955x: Add brightness_get function

2021-09-22T02:36:42+00:00

Add a function to fetch the state of the hardware LED. OpenBMC-Staging-Count: 1 Signed-off-by: Eddie James Signed-off-by: Pavel Machek Link: https://lore.kernel.org/r/20210916212140.33915-5-eajames@linux.ibm.com Signed-off-by: Joel Stanley

leds: pca955x: Clean up code formatting

2021-09-22T02:36:42+00:00

Format the code. Add some variables to help shorten lines. OpenBMC-Staging-Count: 1 Signed-off-by: Eddie James Signed-off-by: Pavel Machek Link: https://lore.kernel.org/r/20210916212140.33915-4-eajames@linux.ibm.com Signed-off-by: Joel Stanley

leds: leds-core: Implement the retain-state-shutdown property

2021-09-22T02:36:42+00:00

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. OpenBMC-Staging-Count: 1 Signed-off-by: Eddie James Signed-off-by: Pavel Machek Link: https://lore.kernel.org/r/20210916212140.33915-3-eajames@linux.ibm.com Signed-off-by: Joel Stanley

leds: lgm-sso: Propagate error codes from callee to caller

2021-09-15T08:02:20+00:00

[ Upstream commit 9cbc861095375793a69858f91f3ac4e817f320f0 ] 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: 9999908ca1ab ("leds: lgm-sso: Put fwnode in any case during ->probe()") Fixes: c3987cd2bca3 ("leds: lgm: Add LED controller driver for LGM SoC") Reported-by: kernel test robot Signed-off-by: Andy Shevchenko Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin

leds: trigger: audio: Add an activate callback to ensure the initial brightness is set

2021-09-15T08:02:17+00:00

[ Upstream commit 64f67b5240db79eceb0bd57dae8e591fd3103ba0 ] 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 Fixes: faa2541f5b1a ("leds: trigger: Introduce audio mute LED trigger") Reviewed-by: Marek Behún Signed-off-by: Hans de Goede Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin