linux-kernel - [PATCH 5/5] Input: elants_i2c: Delay longer with reset asserted

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: <20221208111910.5.I6edfb3f459662c041563a54e5b7df727c27caaba@changeid>
Date:   Thu,  8 Dec 2022 11:20:06 -0800
From:   Douglas Anderson <dianders@...omium.org>
To:     Bjorn Andersson <andersson@...nel.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:     mka@...omium.org, swboyd@...omium.org,
        linux-arm-msm@...r.kernel.org, linux-input@...r.kernel.org,
        Yunlong Jia <ecs.beijing2022@...il.com>,
        Konrad Dybcio <konrad.dybcio@...aro.org>,
        Douglas Anderson <dianders@...omium.org>,
        Johnny Chuang <johnny.chuang.emc@...il.com>,
        linux-kernel@...r.kernel.org
Subject: [PATCH 5/5] Input: elants_i2c: Delay longer with reset asserted

The elan touchscreen datasheet says that the reset GPIO only needs to
be asserted for 500us in order to reset the regulator. The problem is
that some boards need a level shifter between the signals on the GPIO
controller and the signals on the touchscreen. All of these extra
components on the line can slow the transition of the signals. On one
board, we measured the reset line and saw that it took almost 1.8ms to
go low. Even after we bumped up the "drive strength" of the signal
from the default 2mA to 8mA we still saw it take 421us for the signal
to go low.

In order to account for this we let's lengthen the amount of time that
we keep the reset asserted. Let's bump it up from 500us to 5000us.
That's still a relatively short amount of time and is much safer.

It should be noted that this fixes real problems. Case in point:
1. The touchscreen power rail may be shared with another device (like
   an eDP panel). That means that at probe time power might already be
   on.
2. In probe we grab the reset GPIO and assert it (make it low).
3. We turn on power (a noop since it was already on).
4. We wait 500us.
5. We deassert the reset GPIO.

With the above case and only a 500us delay we saw only a partial reset
asserted, which is bad. Giving it 5ms is overkill but feels safer in
case someone else has a different level shifter setup.

Signed-off-by: Douglas Anderson <dianders@...omium.org>
---

 drivers/input/touchscreen/elants_i2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/touchscreen/elants_i2c.c b/drivers/input/touchscreen/elants_i2c.c
index 879a4d984c90..377adf89b25c 100644
--- a/drivers/input/touchscreen/elants_i2c.c
+++ b/drivers/input/touchscreen/elants_i2c.c
@@ -114,7 +114,7 @@
 /* calibration timeout definition */
 #define ELAN_CALI_TIMEOUT_MSEC	12000

-#define ELAN_POWERON_DELAY_USEC	500
+#define ELAN_POWERON_DELAY_USEC	5000
 #define ELAN_RESET_DELAY_MSEC	20

 /* FW boot code version */
-- 
2.39.0.rc1.256.g54fd8350bd-goog