Re: [PATCH] HID: intel-thc-hid: intel-quickspi: reset touch IC on system resume

[d3z]

From: Danny D. <d3z.the.dev@xxxxxxxxx>

Hi Even,

Thanks for the quick reply and for sharing your patch.

First, the missing piece from your mail: my name is Danny D.
(d3z.the.dev@xxxxxxxxx) - please use it for any
Signed-off-by/Reported-by/Tested-by.

One note on the starting assumption, though: in its current configuration
this Surface Pro 10 doesn't go to S3 at all. /sys/power/mem_sleep only
offers s2idle:

    $ cat /sys/power/mem_sleep
    [s2idle]

There's no "deep" entry to select here, so every suspend goes through
s2idle and never reaches PM_SUSPEND_MEM. The touch IC still loses power
across that s2idle suspend - the same as over hibernation - which is what
gives the "recv failed: -11" on resume.

That's the catch with the attached patch: it gates the THC reconfigure on

    if (last_suspend_state == PM_SUSPEND_MEM)

i.e. S3 only. On this machine that branch never runs, so it wouldn't bring
the touchscreen back here. Happy to apply it and confirm on the device, but
from the code path alone it can't help while we're s2idle-only.

What I did instead was key off whether the device actually kept power
rather than the suspend type: run the full reset only when the device isn't
a wake source (device_may_wakeup() == false), mirroring quickspi_restore().
A wake-enabled device stays on the light path so wake-on-touch is preserved;
one that lost power goes through reset_tic() re-enumeration. That fires on
both s2idle and S3, which is what makes it work on the SP10.

I've tested this on the Surface Pro 10 across many s2idle suspend/resume
cycles - touch and pen both keep working - and just posted a v2 that adds
the device_may_wakeup() gate.

Could we converge on the wakeup-based condition? I'm glad to test any
revision of your patch on the hardware, and equally glad for you to carry
the fix with my Signed-off-by/Tested-by once it handles the s2idle case.

Thanks,
Danny