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

Merge branch 'dev-5.10' into dev-5.10-intel

2021-10-01T18:40:21+00:00

Pull 5.10.67 stable from OpenBMC upstream. Signed-off-by: Jae Hyun Yoo

fixup! ADC linux driver for AST2600

2021-10-01T18:36:56+00:00

Revert d17922945eeaded06b6424a8e8d666d211d57dd4. Signed-off-by: Jae Hyun Yoo

fixup! Igore 0x3FF in aspeed_adc driver

2021-10-01T18:36:48+00:00

Revert 0256271cd3840545a13728b07e1bc6baf0cd75db. Signed-off-by: Jae Hyun Yoo

ASD Add Shift IR/DR from Exit IR/DR for HW2 JTAG xfers

2021-09-30T21:15:58+00:00

Before this change JTAG HW2 mode shift operation failed to process a shift request when current state was Exit IR/DR for the same type of xfer SHIFTIR/SHIFTDR respectively. After this change we will support shift operations in HW2 mode from the following jtag states: For SHIFTDR: JTAG_STATE_SHIFTDR, JTAG_STATE_IDLE, JTAG_STATE_TLRESET, JTAG_STATE_PAUSEDR, JTAG_STATE_EXIT1DR and JTAG_STATE_EXIT1IR For SHIFTIR: JTAG_STATE_SHIFTIR, JTAG_STATE_IDLE, JTAG_STATE_TLRESET, JTAG_STATE_PAUSEIR, JTAG_STATE_EXIT1IR and JTAG_STATE_EXIT1DR Test: ASD Sanity(SW mode) finished successfully(SPR) ASD Sanity(HW mode) finished successfully(SPR) Cscripts(SW mode) finished successfully(SPR) Cscripts(HW mode) finished successfully(SPR) Signed-off-by: Ernesto Corona Change-Id: Ide878b8986639c63e41c2bc360e06a261cdffee5

leds: pca955x: Allow zero LEDs to be specified

2021-09-24T04:37:17+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:37:17+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:33:52+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:33:48+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:33:45+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:33:43+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