From: "R. Larocque" <rlarocque@disroot.org>
To: linux-input@vger.kernel.org
Cc: dmitry.torokhov@gmail.com, dave.wang@emc.com.tw,
jingle.wu@emc.com.tw, linux-kernel@vger.kernel.org,
"R. Larocque" <rlarocque@disroot.org>
Subject: [RFC PATCH] Input: elan_i2c_smbus - resend ENABLE_TP on wake from sleep (NOT TESTED, NEEDS TESTER!)
Date: Tue, 22 Sep 2026 19:17:12 -0400 [thread overview]
Message-ID: <20260922232707.8949-1-rlarocque@disroot.org> (raw)
elan_smbus_sleep_control() sends ETP_SMBUS_SLEEP_CMD to put the
controller to sleep, but does nothing on wake, leaving a long-standing
XXX comment questionning wether ETP_SMBUS_ENABLE_TP should be re sent.
elan_initialize() already treats sleep_control(client, false) as a
genuine "wake device up" primitive (see the ASUS special-firmware
branch and its accompanying dev_err() message), so this makes the
non-ASUS/default path resend ETP_SMBUS_ENABLE_TP symetrically with
elan_smbus_initialize() instead of being a no-op.
Signed-off-by: Raphaël Larocque <rlarocque@disroot.org>
---
RFC: I dont have the Elan SMBus protocol datasheet and consequently
havent been able to test this on any real hardware where the previous no-op
path was actually relied upon. Sending this for testing by
someone with access to affected devices before it is considered for
merge. A bad SMBus write to a sleeping controller could leave it
in a weird state on the wrong firmware revision if unlucky.
drivers/input/mouse/elan_i2c_smbus.c | 19 +++++++++++++++++--
1 file changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/input/mouse/elan_i2c_smbus.c b/drivers/input/mouse/elan_i2c_smbus.c
index 0287441cda46..95f5951e9549 100644
--- a/drivers/input/mouse/elan_i2c_smbus.c
+++ b/drivers/input/mouse/elan_i2c_smbus.c
@@ -93,10 +93,25 @@ static int elan_smbus_set_mode(struct i2c_client *client, u8 mode)
static int elan_smbus_sleep_control(struct i2c_client *client, bool sleep)
{
+ int error;
+
if (sleep)
return i2c_smbus_write_byte(client, ETP_SMBUS_SLEEP_CMD);
- else
- return 0; /* XXX should we send ETP_SMBUS_ENABLE_TP here? */
+
+ /*
+ * The controller stops touch reporting while asleep; resend
+ * ETP_SMBUS_ENABLE_TP on wake, mirroring what is done during
+ * elan_smbus_initialize(), so that reporting actually resumes.
+ */
+ error = i2c_smbus_write_byte(client, ETP_SMBUS_ENABLE_TP);
+ if (error) {
+ dev_err(&client->dev,
+ "failed to re-enable touchpad after wake: %d\n",
+ error);
+ return error;
+ }
+
+ return 0;
}
static int elan_smbus_power_control(struct i2c_client *client, bool enable)
--
2.55.0
reply other threads:[~2026-09-22 23:27 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260922232707.8949-1-rlarocque@disroot.org \
--to=rlarocque@disroot.org \
--cc=dave.wang@emc.com.tw \
--cc=dmitry.torokhov@gmail.com \
--cc=jingle.wu@emc.com.tw \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®