Re: [PATCH] gpio: fix locking open drain IRQ lines

[Russell King - ARM Linux admin <linux@armlinux.org.uk>]

On Thu, May 28, 2020 at 03:46:04PM +0200, Linus Walleij wrote:
> On Wed, May 27, 2020 at 4:18 PM Russell King - ARM Linux admin
> <linux@armlinux.org.uk> wrote:
> > 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@xs4all.nl>
> > > Cc: Russell King <linux@armlinux.org.uk>
> > > Cc: stable@vger.kernel.org
> > > 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.
> 
> You're right, I was thinking of Fixes: as more of a mechanical
> instruction to the stable kernel maintainers administrative machinery.
> 
> I will use the other way to signal to stable where to apply this.

I think it makes sense to apply this patch to stable kernels prior to
the commit mentioned in the Fixes tag - but how far back is a good
question.  Certainly to the point that we ended up with code relying
on this behaviour (so when cec-gpio was introduced?)

-- 
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