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
