On Wed, May 27, 2020 at 04:07:58PM +0200, Linus Walleij wrote:
> We provided the right semantics on open drain lines being
> by definition output but incidentally the irq set up function
> would only allow IRQs on lines that were "not output".
>
> Fix the semantics to allow output open drain lines to be used
> for IRQs.
>
> Reported-by: Hans Verkuil <hverkuil@xxxxxxxxx>
> Cc: Russell King <linux@xxxxxxxxxxxxxxx>
> Cc: stable@xxxxxxxxxxxxxxx
> Fixes: 256efaea1fdc ("gpiolib: fix up emulated open drain outputs")
As I've pointed out in the reporting thread, I don't think it can be
justified as a regression - it's a bug in its own right that has been
discovered by unifying the gpiolib semantics, since the cec-gpio code
will fail on hardware that can provide real open-drain outputs
irrespective of that commit.
So, you're really fixing a deeper problem that was never discovered
until gpiolib's semantics were fixed to be more uniform.
> Signed-off-by: Linus Walleij <linus.walleij@xxxxxxxxxx>
> ---
> drivers/gpio/gpiolib.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c
> index b4b5792fe2ff..edd74ff31cea 100644
> --- a/drivers/gpio/gpiolib.c
> +++ b/drivers/gpio/gpiolib.c
> @@ -4220,7 +4220,9 @@ int gpiochip_lock_as_irq(struct gpio_chip *gc, unsigned int offset)
> }
> }
>
> - if (test_bit(FLAG_IS_OUT, &desc->flags)) {
> + /* To be valid for IRQ the line needs to be input or open drain */
> + if (test_bit(FLAG_IS_OUT, &desc->flags) &&
> + !test_bit(FLAG_OPEN_DRAIN, &desc->flags)) {
> chip_err(gc,
> "%s: tried to flag a GPIO set as output for IRQ\n",
> __func__);
> --
> 2.25.4
>
>
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up
