BMC/Intel-BMC/linux.git, 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

ARM: dts: aspeed: Add ADC for AST2600 and enable for Rainier and Everest

2021-09-24T04:37:17+00:00

Add the ADC nodes to the AST2600 devicetree. Enable ADC1 for Rainier and Everest systems and add an iio-hwmon node for the 7th channel to report the battery voltage. Tested on Rainier: ~# cat /sys/class/hwmon/hwmon11/in1_input 1347 OpenBMC-Staging-Count: 1 Signed-off-by: Eddie James Link: https://lore.kernel.org/r/20210916210045.31769-1-eajames@linux.ibm.com Signed-off-by: Joel Stanley

fixup! i2c: aspeed: add H/W timeout support

2021-09-22T16:00:34+00:00

Add H/W timeout settings into ast2600.dts. Signed-off-by: Jae Hyun Yoo Change-Id: Iae0b4043b8efe2da76af7eccd99ae296b434ae0e

ARM: dts: everest: Define name for gpio line B6

2021-09-22T02:34:02+00:00

gpio-line-names B6 set to checkstop OpenBMC-Staging-Count: 1 Signed-off-by: Ben Tyner Reviewed-by: Eddie James Link: https://lore.kernel.org/r/20210920150549.6431-4-bentyner@linux.ibm.com Signed-off-by: Joel Stanley

ARM: dts: everest: Define name for gpio line Q2

2021-09-22T02:33:59+00:00

gpio-line-names Q2 set to regulator-standby-faulted OpenBMC-Staging-Count: 1 Signed-off-by: Ben Tyner Reviewed-by: Eddie James Link: https://lore.kernel.org/r/20210920150549.6431-3-bentyner@linux.ibm.com Signed-off-by: Joel Stanley