linux-kernel - Re: [PATCH] gpio: pca953x: Improve interrupt support

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]

Message-ID: <ZmQoCwLFuJNyuRG6@surfacebook.localdomain>
Date: Sat, 8 Jun 2024 12:44:43 +0300
From: Andy Shevchenko <andy.shevchenko@...il.com>
To: Mark Tomlinson <mark.tomlinson@...iedtelesis.co.nz>
Cc: linus.walleij@...aro.org, brgl@...ev.pl, linux-gpio@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] gpio: pca953x: Improve interrupt support

Thu, Jun 06, 2024 at 03:31:02PM +1200, Mark Tomlinson kirjoitti:
> The GPIO drivers with latch interrupt support (typically types starting
> with PCAL) have interrupt status registers to determine which particular
> inputs have caused an interrupt. Unfortunately there is no atomic
> operation to read these registers and clear the interrupt. Clearing the
> interrupt is done by reading the input registers.

What you are describing sounds to me like the case without latch enabled.
Can you elaborate a bit more?

> The code was reading the interrupt status registers, and then reading
> the input registers. If an input changed between these two events it was
> lost.

I don't see how. If there is a short pulse or a series of pulses between
interrupt latching and input reading, the second+ will be lost in any case.
This is HW limitation as far as I can see.

> The solution in this patch is to revert to the non-latch version of
> code, i.e. remembering the previous input status, and looking for the
> changes. This system results in no more I2C transfers, so is no slower.
> The latch property of the device still means interrupts will still be
> noticed if the input changes back to its initial state.

Again, can you elaborate? Is it a real use case? If so, can you provide the
chart of the pin sginalling against the time line and depict where the problem
is?

-- 
With Best Regards,
Andy Shevchenko