linux-kernel - Re: [PATCH v5 7/7] Input: matrix_keypad

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: <Z74B8Gppk9YxdIxr@google.com>
Date: Tue, 25 Feb 2025 09:46:24 -0800
From: Dmitry Torokhov <dmitry.torokhov@...il.com>
To: Markus Burri <markus.burri@...com>
Cc: Manuel Traut <manuel.traut@...com>, linux-kernel@...r.kernel.org,
	Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Marek Vasut <marek.vasut@...il.com>, linux-input@...r.kernel.org,
	devicetree@...r.kernel.org
Subject: Re: [PATCH v5 7/7] Input: matrix_keypad - detect change during scan

On Tue, Feb 25, 2025 at 09:51:22AM +0100, Markus Burri wrote:
> On Mon, Feb 24, 2025 at 10:58:27PM -0800, Dmitry Torokhov wrote:
> > On Wed, Feb 19, 2025 at 05:56:10PM +0100, Manuel Traut wrote:
> > > On Fri, Jan 10, 2025 at 06:49:06AM +0100, Markus Burri wrote:
> > > > For a setup where the matrix keypad is connected over a slow interface
> > > > (e.g. a gpio-expansion over i2c), the scan can take a longer time to read.
> > > > 
> > > > Interrupts need to be disabled during scan. And therefore changes in this
> > > > period are not detected.
> > > > To improve this situation, scan the matrix again if the row state changed
> > > > during interrupts disabled.
> > > > The rescan is repeated until no change is detected anymore.
> > > 
> > > This is a quirk for a bad hardware design. For 'good' hardware it adds
> > > an additional read_row_state for no need. For even slower connected
> > > GPIOs this will also not help much. However it is obvious that it will
> > > be an improvement for some designs. 
> > > 
> > > Dmitry, would it make sense to make this configurable?
> > 
> > What if we do not disable interrupts after the first one, but record
> > the last interrupt time and rescan if it arrived after work handler
> > started executing?
> > 
> > Thanks.
> 
> I was also thinking about that.
> If we do not disable interrupts we will get a lot of interrupts during scan.
> The scanning process itself generate interrupts because of selecting the columns
> and read row state. Therefore after scan we will not know if the interrupts are
> caused by scanning or a change.

OK, then maybe we should keep re-submitting the work until we get to
stable state? My objection is repeating the scan once does not really
solve the issue....

Thanks.

-- 
Dmitry