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
next reply other threads:[~2026-09-22 23:27 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 23:17 R. Larocque [this message]
2026-09-22 23:37 ` [RFC PATCH] Input: elan_i2c_smbus - resend ENABLE_TP on wake from sleep (NOT TESTED, NEEDS TESTER!) sashiko-bot
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.