BMC/Intel-BMC/linux.git/drivers/gpio, branch dev-5.2

gpio: Add in ast2600 details to Aspeed driver

2019-09-10T17:29:57+00:00

The ast2600 is a new generation of SoC from ASPEED. Similarly to the ast2400 and ast2500, it has a GPIO controller for it's 3.3V GPIO pins. Additionally, it has a GPIO controller for 1.8V GPIO pins. As the register names for both controllers are the same and the 36 1.8V GPIOs and the first 36 of the 3.3V GPIOs are all bidirectional, we can use the same configuration struct and use the ngpio property to differentiate between the two sets of GPIOs. OpenBMC-Staging-Count: 1 Signed-off-by: Rashmica Gupta Signed-off-by: Joel Stanley

gpio/aspeed: Use ngpio property from device tree if available

2019-09-10T17:29:57+00:00

Use the ngpio property from the device tree if it exists. If it doesn't then fallback to the hardcoded value in the config. This is in preparation for adding ast2600 support. The ast2600 SoC has two GPIO controllers and so requires two instances of the GPIO driver. We use the ngpio property to different between them as they have different numbers of GPIOs. OpenBMC-Staging-Count: 1 Signed-off-by: Rashmica Gupta Reviewed-by: Joel Stanley Signed-off-by: Joel Stanley

gpio/aspeed: Setup irqchip dynamically

2019-09-10T17:29:57+00:00

This is in preparation for adding ast2600 support. The ast2600 SoC requires two instances of the GPIO driver as it has two GPIO controllers. Each instance needs it's own irqchip. OpenBMC-Staging-Count: 1 Signed-off-by: Rashmica Gupta Reviewed-by: Joel Stanley Signed-off-by: Joel Stanley

gpio/aspeed: Fix incorrect number of banks

2019-09-10T17:29:57+00:00

The current calculation for the number of GPIO banks is only correct if the number of GPIOs is a multiple of 32 (if there were 31 GPIOs we would currently say there are 0 banks, which is incorrect). OpenBMC-Staging-Count: 1 Fixes: 361b79119a4b7 ('gpio: Add Aspeed driver') Signed-off-by: Rashmica Gupta Reviewed-by: Andrew Jeffery Reviewed-by: Joel Stanley Signed-off-by: Joel Stanley

gpio: aspeed: Pass irqchip when adding gpiochip

2019-09-10T17:29:49+00:00

We need to convert all old gpio irqchips to pass the irqchip setup along when adding the gpio_chip. For more info see drivers/gpio/TODO. For chained irqchips this is a pretty straight-forward conversion. Cc: Joel Stanley Cc: Andrew Jeffery Cc: Benjamin Herrenschmidt Cc: Thierry Reding Link: https://lore.kernel.org/r/20190809125515.19094-1-linus.walleij@linaro.org Reviewed-by: Andrew Jeffery Tested-by: Andrew Jeffery Acked-by: Joel Stanley Signed-off-by: Linus Walleij (cherry picked from commit 8512ee31926296fd7d65c1b3c97bb20d67e7eb2a) Signed-off-by: Joel Stanley

gpio: Fix irqchip initialization order

2019-09-10T09:35:25+00:00

[ Upstream commit 48057ed1840fde9239b1e000bea1a0a1f07c5e99 ] The new API for registering a gpio_irq_chip along with a gpio_chip has a different semantic ordering than the old API which added the irqchip explicitly after registering the gpio_chip. Move the calls to add the gpio_irq_chip *last* in the function, so that the different hooks setting up OF and ACPI and machine gpio_chips are called *before* we try to register the interrupts, preserving the elder semantic order. This cropped up in the PL061 driver which used to work fine with no special ACPI quirks, but started to misbehave using the new API. Fixes: e0d897289813 ("gpio: Implement tighter IRQ chip integration") Cc: Thierry Reding Cc: Grygorii Strashko Cc: Andy Shevchenko Reported-by: Wei Xu Tested-by: Wei Xu Reported-by: Andy Shevchenko Signed-off-by: Linus Walleij Link: https://lore.kernel.org/r/20190820080527.11796-1-linus.walleij@linaro.org Signed-off-by: Sasha Levin

gpiolib: never report open-drain/source lines as 'input' to user-space

2019-08-29T06:30:23+00:00

commit 2c60e6b5c9241b24b8b523fefd3e44fb85622cda upstream. If the driver doesn't support open-drain/source config options, we emulate this behavior when setting the direction by calling gpiod_direction_input() if the default value is 0 (open-source) or 1 (open-drain), thus not actively driving the line in those cases. This however clears the FLAG_IS_OUT bit for the GPIO line descriptor and makes the LINEINFO ioctl() incorrectly report this line's mode as 'input' to user-space. This commit modifies the ioctl() to always set the GPIOLINE_FLAG_IS_OUT bit in the lineinfo structure's flags field. Since it's impossible to use the input mode and open-drain/source options at the same time, we can be sure the reported information will be correct. Fixes: 521a2ad6f862 ("gpio: add userspace ABI for GPIO line information") Cc: stable Signed-off-by: Bartosz Golaszewski Link: https://lore.kernel.org/r/20190806114151.17652-1-brgl@bgdev.pl Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpiolib: fix incorrect IRQ requesting of an active-low lineevent

2019-08-06T17:08:16+00:00

commit 223ecaf140b1dd1c1d2a1a1d96281efc5c906984 upstream. When a pin is active-low, logical trigger edge should be inverted to match the same interrupt opportunity. For example, a button pushed triggers falling edge in ACTIVE_HIGH case; in ACTIVE_LOW case, the button pushed triggers rising edge. For user space the IRQ requesting doesn't need to do any modification except to configuring GPIOHANDLE_REQUEST_ACTIVE_LOW. For example, we want to catch the event when the button is pushed. The button on the original board drives level to be low when it is pushed, and drives level to be high when it is released. In user space we can do: req.handleflags = GPIOHANDLE_REQUEST_INPUT; req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE; while (1) { read(fd, &dat, sizeof(dat)); if (dat.id == GPIOEVENT_EVENT_FALLING_EDGE) printf("button pushed\n"); } Run the same logic on another board which the polarity of the button is inverted; it drives level to be high when pushed, and level to be low when released. For this inversion we add flag GPIOHANDLE_REQUEST_ACTIVE_LOW: req.handleflags = GPIOHANDLE_REQUEST_INPUT | GPIOHANDLE_REQUEST_ACTIVE_LOW; req.eventflags = GPIOEVENT_REQUEST_FALLING_EDGE; At the result, there are no any events caught when the button is pushed. By the way, button releasing will emit a "falling" event. The timing of "falling" catching is not expected. Cc: stable@vger.kernel.org Signed-off-by: Michael Wu Tested-by: Bartosz Golaszewski Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman

gpiolib: Preserve desc->flags when setting state

2019-08-06T17:08:16+00:00

commit d95da993383c78f7efd25957ba3af23af4b1c613 upstream. desc->flags may already have values set by of_gpiochip_add() so make sure that this isn't undone when setting the initial direction. Cc: stable@vger.kernel.org Fixes: 3edfb7bd76bd1cba ("gpiolib: Show correct direction from the beginning") Signed-off-by: Chris Packham Link: https://lore.kernel.org/r/20190707203558.10993-1-chris.packham@alliedtelesis.co.nz Signed-off-by: Linus Walleij Signed-off-by: Greg Kroah-Hartman

gpio: davinci: silence error prints in case of EPROBE_DEFER

2019-07-28T06:27:21+00:00

commit 541e4095f388c196685685633c950cb9b97f8039 upstream. Silence error prints in case of EPROBE_DEFER. This avoids multiple/duplicate defer prints during boot. Cc: Signed-off-by: Keerthy Signed-off-by: Bartosz Golaszewski Signed-off-by: Greg Kroah-Hartman