[RFC PATCH V2] Input: elan_i2c_smbus - resend ENABLE_TP on wake from sleep (NOT TESTED, NEEDS TESTER!) (v2: typo fixes)

[RFC PATCH V2] Input: elan_i2c_smbus - resend ENABLE_TP on wake from sleep (NOT TESTED, NEEDS TESTER!) (v2: typo fixes)

[R. Larocque]

From: "Raphaël Larocque" <rlarocque@disroot.org>

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 questioning whether 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 symmetrically with
elan_smbus_initialize() instead of being a no-op.

Signed-off-by: Raphaël Larocque <rlarocque@disroot.org>
---
RFC: I don't have the Elan SMBus protocol datasheet and consequently 
haven't 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

Re: [RFC PATCH V2] Input: elan_i2c_smbus - resend ENABLE_TP on wake from sleep (NOT TESTED, NEEDS TESTER!) (v2: typo fixes)

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] input: elan_i2c: ENABLE_TP command sent after set_mode() may clobber absolute mode
--

commit 37faf4759d30c6532910d41f48a2708415776398
Author: Raphaël Larocque <rlarocque@disroot.org>
Input: elan_i2c_smbus - resend ENABLE_TP on wake from sleep (NOT TESTED, NEEDS TESTER!) (v2: typo fixes)

This commit updates elan_smbus_sleep_control() to resend the
ETP_SMBUS_ENABLE_TP command when waking the controller from sleep.

> diff --git a/drivers/input/mouse/elan_i2c_smbus.c b/drivers/input/mouse/elan_i2c_smbus.c
> index 0287441cda46d..dd86bd1739c55 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)
>  {
[ ... ]
> +	/*
> +	 * 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);

[Severity: Medium]
Could this clobber the absolute mode configuration for non-ASUS devices?

Looking at __elan_initialize() in drivers/input/mouse/elan_i2c_core.c,
non-ASUS devices first configure absolute mode via set_mode(), and then
call sleep_control() to wake the device:

	data->mode |= ETP_ENABLE_ABS;
	error = data->ops->set_mode(client, data->mode);
	if (error) {
		...
	}

	if (!woken_up) {
		error = data->ops->sleep_control(client, false);
		...
	}

Since this patch now sends ETP_SMBUS_ENABLE_TP in sleep_control() on
wake, it gets transmitted after set_mode() for these non-ASUS devices.
Could sending this command after configuring absolute mode reset the
hardware to its default relative mode, breaking absolute touch reporting?

> +	if (error) {
> +		dev_err(&client->dev,
> +			"failed to re-enable touchpad after wake: %d\n",
> +			error);
> +		return error;
> +	}
> +
> +	return 0;
>  }

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922233549.10431-1-rlarocque@disroot.org?part=1

Re: [RFC PATCH V2] Input: elan_i2c_smbus - resend ENABLE_TP on wake from sleep (NOT TESTED, NEEDS TESTER!) (v2: typo fixes)

[Dmitry Torokhov]

Hi Raphaël,

On Tue, Sep 22, 2026 at 07:35:47PM -0400, R. Larocque wrote:
> From: "Raphaël Larocque" <rlarocque@disroot.org>
> 
> 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 questioning whether 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 symmetrically with
> elan_smbus_initialize() instead of being a no-op.
> 
> Signed-off-by: Raphaël Larocque <rlarocque@disroot.org>
> ---
> RFC: I don't have the Elan SMBus protocol datasheet and consequently 
> haven't 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.

I do not have objections in principle, but this really needs testing on
real hardware... 

Thanks.

-- 
Dmitry