Commit fd9c963c5661 ("gpio: mb86s70: Return error if requesting an already assigned gpio") adds code that infers from the state of the GPIO Pin Function Register (PFR) whether a GPIO has been assigned already. This assumes that the pin functions are set to 'peripheral' when the driver is loaded, which is not guaranteed. Also, the GPIO layer is perfectly capable of keeping track of which GPIOs have been assigned already, so we shouldn't need this check in the first place. This reverts commit fd9c963c5661af3403e77e312c0d9941773b6c1b. Cc: Axel Lin <axel.lin@xxxxxxxxxx> Cc: Linus Walleij <linus.walleij@xxxxxxxxxx> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> --- drivers/gpio/gpio-mb86s7x.c | 5 ----- 1 file changed, 5 deletions(-) diff --git a/drivers/gpio/gpio-mb86s7x.c b/drivers/gpio/gpio-mb86s7x.c index 6e1598471733..5cd77dcdbb16 100644 --- a/drivers/gpio/gpio-mb86s7x.c +++ b/drivers/gpio/gpio-mb86s7x.c @@ -53,11 +53,6 @@ static int mb86s70_gpio_request(struct gpio_chip *gc, unsigned gpio) spin_lock_irqsave(&gchip->lock, flags); val = readl(gchip->base + PFR(gpio)); - if (!(val & OFFSET(gpio))) { - spin_unlock_irqrestore(&gchip->lock, flags); - return -EINVAL; - } - val &= ~OFFSET(gpio); writel(val, gchip->base + PFR(gpio)); -- 2.11.0 -- To unsubscribe from this list: send the line "unsubscribe linux-gpio" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html