linux-kernel - Re: [PATCH v5 3/6] dt-bindings: touchscreen: add touchscreen-glitch-threshold-ns property

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: <CABGWkvrxOTzAcqWHLvuqk_7WFxybheSZFnMkqnksfkPi6wXcpQ@mail.gmail.com>
Date: Fri, 19 Sep 2025 17:12:42 +0200
From: Dario Binacchi <dario.binacchi@...rulasolutions.com>
To: Rob Herring <robh@...nel.org>
Cc: linux-kernel@...r.kernel.org, Frank Li <Frank.Li@....com>, 
	linux-amarula@...rulasolutions.com, Conor Dooley <conor.dooley@...rochip.com>, 
	Conor Dooley <conor+dt@...nel.org>, Dmitry Torokhov <dmitry.torokhov@...il.com>, 
	Javier Carrasco <javier.carrasco@...fvision.net>, Jeff LaBundy <jeff@...undy.com>, 
	Krzysztof Kozlowski <krzk+dt@...nel.org>, devicetree@...r.kernel.org, 
	linux-input@...r.kernel.org
Subject: Re: [PATCH v5 3/6] dt-bindings: touchscreen: add touchscreen-glitch-threshold-ns
 property

On Fri, Sep 19, 2025 at 4:38 PM Rob Herring <robh@...nel.org> wrote:
>
> On Thu, Sep 18, 2025 at 10:37:37PM +0200, Dario Binacchi wrote:
> > On Thu, Sep 18, 2025 at 10:04 PM Rob Herring <robh@...nel.org> wrote:
> > >
> > > On Thu, Sep 18, 2025 at 05:52:31PM +0200, Dario Binacchi wrote:
> > > > Add support for glitch threshold configuration. A detected signal is valid
> > > > only if it lasts longer than the set threshold; otherwise, it is regarded
> > > > as a glitch.
> > > >
> > > > Signed-off-by: Dario Binacchi <dario.binacchi@...rulasolutions.com>
> > > > Acked-by: Conor Dooley <conor.dooley@...rochip.com>
> > > >
> > > > ---
> > > >
> > > > Changes in v5:
> > > > - Add Acked-by tag of Conor Dooley
> > > >
> > > > Changes in v2:
> > > > - Added in v2.
> > > >
> > > >  .../devicetree/bindings/input/touchscreen/touchscreen.yaml    | 4 ++++
> > > >  1 file changed, 4 insertions(+)
> > > >
> > > > diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> > > > index 3e3572aa483a..a60b4d08620d 100644
> > > > --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> > > > +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml
> > > > @@ -206,6 +206,10 @@ properties:
> > > >
> > > >          unevaluatedProperties: false
> > > >
> > > > +  touchscreen-glitch-threshold-ns:
> > > > +    description: Minimum duration in nanoseconds a signal must remain stable
> > > > +      to be considered valid.
> > >
> > > What's wrong with debounce-delay-ms?
> >
> > Do you mean that I should rename touchscreen-glitch-threshold-ns to
> > debounce-delay-ms?
>
> I mean that's the common property we already have, so use it or explain
> why you aren't using it. I suppose the definition is technically a bit
> different if it's purely a s/w delay vs. h/w monitoring of the signal
> state. I don't think it matters if the interpretation by each driver is
> a bit different.
>
> Maybe msec is not enough resolution for you could be another reason?

Yes, this is the main reason. As specified in the following patch:
  v5 4/6 dt-bindings: touchscreen: fsl,imx6ul-tsc: support glitch threshold

Drivers must convert this value to IPG clock cycles and map
it to one of the four discrete thresholds exposed by the
TSC_DEBUG_MODE2 register:

  0: 8191 IPG cycles
  1: 4095 IPG cycles
  2: 2047 IPG cycles
  3: 1023 IPG cycles

In my case, the IPG clock runs at 66 MHz, which corresponds to:

124 µs for 0
62 µs for 1
31 us for 2
15 us for 3

So using milliseconds would not fit my use case. A possible trade-off
could be to use debounce-delay-us. Would that be acceptable?

Thanks and regards
Dario

> Looks like your h/w supports that assuming the clock frequency is 10s
> of MHz. But are touchscreen glitches really in sub msec times? Not in my
> experience, but that's 20 years ago on resistive touchscreens...
>
> Rob



-- 

Dario Binacchi

Senior Embedded Linux Developer

dario.binacchi@...rulasolutions.com

__________________________________


Amarula Solutions SRL

Via Le Canevare 30, 31100 Treviso, Veneto, IT

T. +39 042 243 5310
info@...rulasolutions.com

www.amarulasolutions.com