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

leds: pca955x: Add HW blink support

2022-04-15T04:35:01+00:00

Support blinking using the PCA955x chip. Use PWM0 for blinking instead of LED_HALF brightness. Since there is only one frequency and brightness register for any blinking LED, track the blink state of each LED and only support one HW blinking frequency. If another frequency is requested, fallback to software blinking. OpenBMC-Staging-Count: 1 Signed-off-by: Eddie James Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220412164211.28824-5-eajames@linux.ibm.com Signed-off-by: Joel Stanley

leds: pca955x: Optimize probe led selection

2022-04-15T04:34:59+00:00

Previously, the probe function might do up to 32 reads and writes to the same 4 registers to program the led selection. Reduce this to a maximum of 8 operations by accumulating the changes to the led selection and comparing with the previous value to write the selection if different. OpenBMC-Staging-Count: 1 Signed-off-by: Eddie James Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220412164211.28824-4-eajames@linux.ibm.com Signed-off-by: Joel Stanley

leds: pca955x: Use pointers to driver data rather than I2C client

2022-04-15T04:34:56+00:00

As a minor clean up item, pass the driver data pointer instead of the I2C client to the reader and writer helper functions. Now the PCA driver data doesn't have to be looked up again in the I2C client data OpenBMC-Staging-Count: 1 Signed-off-by: Eddie James Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220412164211.28824-3-eajames@linux.ibm.com Signed-off-by: Joel Stanley

leds: pca955x: Refactor with helper functions and renaming

2022-04-15T04:34:54+00:00

Add helper functions to clean up the code, and rename a few oddly named functions and variables. OpenBMC-Staging-Count: 1 Signed-off-by: Eddie James Reviewed-by: Andy Shevchenko Link: https://lore.kernel.org/r/20220412164211.28824-2-eajames@linux.ibm.com Signed-off-by: Joel Stanley

Merge tag 'v5.15.18' into dev-5.15

2022-01-31T06:13:20+00:00

This is the 5.15.18 stable release Signed-off-by: Joel Stanley

leds: lp55xx: initialise output direction from dts

2022-01-27T10:04:21+00:00

[ Upstream commit 9e87a8da747bf72365abb79e6f64fcca955b4f56 ] 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 Reviewed-by: Linus Walleij Signed-off-by: Pavel Machek Signed-off-by: Sasha Levin

leds: pca955x: Allow zero LEDs to be specified

2021-11-01T06:42:45+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: 2 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-11-01T06:42:45+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: 2 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-08-20T09:00:08+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. Signed-off-by: Eddie James Signed-off-by: Pavel Machek

leds: pca955x: Let the core process the fwnode

2021-08-20T09:00:08+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. Signed-off-by: Eddie James Signed-off-by: Pavel Machek