On 28/05/2020 15:58, Russell King - ARM Linux admin wrote: > 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@xxxxxxxxxxxxxxx> 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@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. >> >> 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?) > For the record, cec-gpio started to rely on this behavior in kernel 5.3. There is no need to go back to pre-5.3 kernels. Regards, Hans