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 for Android: free password hash cracker in your pocket

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

Message-ID: <Z72EiqCv_pUZDRdV@Debian-VM-Markus.debian>
Date: Tue, 25 Feb 2025 09:51:22 +0100
From: Markus Burri <markus.burri@...com>
To: Dmitry Torokhov <dmitry.torokhov@...il.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 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.
  
> 
> -- 
> Dmitry