linux-kernel - Re: [PATCH 8/8] gpio: tqmx86: fix broken IRQ_TYPE_EDGE

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 29 May 2024 14:44:30 +0200
From: Matthias Schiffer <matthias.schiffer@...tq-group.com>
To: Andrew Lunn <andrew@...n.ch>
Cc: Linus Walleij <linus.walleij@...aro.org>, Bartosz Golaszewski
 <brgl@...ev.pl>, linux-gpio@...r.kernel.org, linux-kernel@...r.kernel.org, 
 Gregor Herburger <gregor.herburger@...group.com>, linux@...tq-group.com
Subject: Re: [PATCH 8/8] gpio: tqmx86: fix broken IRQ_TYPE_EDGE_BOTH
 interrupt type

On Wed, 2024-05-29 at 14:37 +0200, Andrew Lunn wrote:
> On Wed, May 29, 2024 at 09:45:20AM +0200, Matthias Schiffer wrote:
> > The TQMx86 GPIO controller only supports falling and rising edge
> > triggers, but not both. Fix this by implementing a software both-edge
> > mode that toggles the edge type after every interrupt.
> 
> Do you have a real use case for this, one that will handle lost
> interrupts because it cannot swap edge quick enough?
> 
> I personally would not do this, because it is dangerous, it gives the
> impression the device can do both, when in fact it cannot reliably.
> 
> For me, the correct fix is to return EOPNOTSUPP or EINVAL for BOTH.
> 

This was the first thing I tried as well, but it seems that supporting IRQ_TYPE_EDGE_BOTH is
mandatory for all GPIO drivers (not doing so results in various error messages when attemting to use
*any* type of interrupt for the GPIO; I don't remember the exact errors). For this reason, several
drivers implement a similar software solution when the hardware doesn't support it.

Many drivers implement this in a fragile way that will easily break when an edge is missed. On the
TQMx86 we are lucky, and this software implementation is actually robust and will not stop reporting
edges when one is missed. The reason is explained in detail in the long comment added by this patch.

Matthias