linux-kernel - RE: [PATCH V4 2/5] input: keyboard: imx_sc: Add i.MX system controller key 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 for Android: free password hash cracker in your pocket

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

Message-ID: <DB3PR0402MB39164F6EB8141BA5CC4F26FCF5850@DB3PR0402MB3916.eurprd04.prod.outlook.com>
Date:   Mon, 23 Sep 2019 02:43:04 +0000
From:   Anson Huang <anson.huang@....com>
To:     Pavel Machek <pavel@....cz>
CC:     Dmitry Torokhov <dmitry.torokhov@...il.com>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mark.rutland@....com" <mark.rutland@....com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        "festevam@...il.com" <festevam@...il.com>,
        "catalin.marinas@....com" <catalin.marinas@....com>,
        "will@...nel.org" <will@...nel.org>,
        Aisheng Dong <aisheng.dong@....com>,
        "ulf.hansson@...aro.org" <ulf.hansson@...aro.org>,
        Andy Duan <fugang.duan@....com>, Peng Fan <peng.fan@....com>,
        Leonard Crestez <leonard.crestez@....com>,
        Daniel Baluta <daniel.baluta@....com>,
        "olof@...om.net" <olof@...om.net>,
        "mripard@...nel.org" <mripard@...nel.org>,
        "arnd@...db.de" <arnd@...db.de>,
        "jagan@...rulasolutions.com" <jagan@...rulasolutions.com>,
        "dinguyen@...nel.org" <dinguyen@...nel.org>,
        "bjorn.andersson@...aro.org" <bjorn.andersson@...aro.org>,
        "marcin.juszkiewicz@...aro.org" <marcin.juszkiewicz@...aro.org>,
        "andriy.shevchenko@...ux.intel.com" 
        <andriy.shevchenko@...ux.intel.com>,
        "yuehaibing@...wei.com" <yuehaibing@...wei.com>,
        "cw00.choi@...sung.com" <cw00.choi@...sung.com>,
        "enric.balletbo@...labora.com" <enric.balletbo@...labora.com>,
        "m.felsch@...gutronix.de" <m.felsch@...gutronix.de>,
        Jacky Bai <ping.bai@....com>,
        "ronald@...ovation.ch" <ronald@...ovation.ch>,
        "stefan@...er.ch" <stefan@...er.ch>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        "linux-input@...r.kernel.org" <linux-input@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>
Subject: RE: [PATCH V4 2/5] input: keyboard: imx_sc: Add i.MX system
 controller key support

Hi, Pavel

> Subject: Re: [PATCH V4 2/5] input: keyboard: imx_sc: Add i.MX system
> controller key support
> 
> Hi!
> 
> > > > +	ret = imx_scu_call_rpc(priv->key_ipc_handle, &msg, true);
> > > > +	if (ret) {
> > > > +		dev_err(&input->dev, "read imx sc key failed, ret %d\n", ret);
> > > > +		return;
> > > > +	}
> > > > +
> > > > +	state = (bool)msg.state;
> > > > +
> > > > +	if (!state && !priv->keystate)
> > > > +		state = true;
> > >
> > > This needs an explanation please.
> >
> > This is to handle the quick press of button, e.g., when button is
> > pressed and released very quickly, when the delay work is scheduled,
> > the button state read from SCU FW is actually a release state (0), the press
> state is (1), so the quick press/release will be ignored.
> >
> > However, after double check and test, I think this should be handled
> > by debounce time, if the button is pressed/release very quickly, the
> > event should be ignored, I will remove it and reduce the debounce time to
> 30mS, previous 100mS is too long, using 30mS as debounce time, I did NOT
> see similar issue no matter how quick I press/release the button.
> 
> Are you sure this is expected behaviour?
> 
> AFAIK microswitches can bounce when the button is pressed and released,
> but will not generate glitches when the button was not pressed, so even
> short presses are real and should be propagated...

Latest version of patch handle the quick press as below:

- When the button is pressed, the delayed work will be scheduled;
- In the delayed work, the button state will be read, once the state is different as previous
  state, it will be propagated;
- If the state is a press state, another delayed work will be scheduled for handling release
  event.

So there could be a small window of DEBOUNCE_TIME (30mS) between button press and the delayed
work scheduled for reading the button state, if the button is released in less than 30ms, then the
state read could be a release state which is same as previous state and it will be ignored.

Do you think in this case, we should also propagated the press event? If yes, then what about the
release event? Although from what I tested, no matter how quick I press the button, the driver
can always receive both the press and release event, as the 30mS is very short.

Thanks,
Anson