From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: "R. Larocque" <rlarocque@disroot.org>
Cc: linux-input@vger.kernel.org, dave.wang@emc.com.tw,
jingle.wu@emc.com.tw, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH V2] Input: elan_i2c_smbus - resend ENABLE_TP on wake from sleep (NOT TESTED, NEEDS TESTER!) (v2: typo fixes)
Date: Sun, 27 Sep 2026 21:59:32 -0700 [thread overview]
Message-ID: <arnz0y8oqHJTx__b@google.com> (raw)
In-Reply-To: <20260922233549.10431-1-rlarocque@disroot.org>
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
prev parent reply other threads:[~2026-09-28 4:59 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-22 23:35 R. Larocque
2026-09-28 4:59 ` Dmitry Torokhov [this message]
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=arnz0y8oqHJTx__b@google.com \
--to=dmitry.torokhov@gmail.com \
--cc=dave.wang@emc.com.tw \
--cc=jingle.wu@emc.com.tw \
--cc=linux-input@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rlarocque@disroot.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®