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

[d3z <d3z.the.dev@gmail.com>]

From: Danny D. <d3z.the.dev@gmail.com>

Hi Even,

Good catch on the missing state restore. I rebuilt with your version and
re-ran the test.

This is exactly your proposal: reset_tic() after thc_dma_configure(),
then qsdev->state = QUICKSPI_ENABLED, with no thc_spi_*_config and no
thc_ltr_*. I built it as a module and swapped it into a clean
linux-surface 6.19.8 on the Surface Pro 10.

It still doesn't survive s2idle - touch is fine at probe, but after one
suspend/resume it's dead again. This time resume() fails outright instead
of coming back quietly broken:

    intel_quickspi 0000:00:10.0: Wait DEVICE_DESCRIPTOR timeout, ret:0
    intel_quickspi 0000:00:10.0: PM: dpm_run_callback(): pci_pm_resume returns -110
    intel_quickspi 0000:00:10.0: PM: failed to resume async: error -110

So reset_tic() can't complete here. It clears the reset handshake, then
times out in quickspi_get_device_descriptor() and the whole resume bails
with -ETIMEDOUT. The device isn't a wake source on this box - "Can't find
wake GPIO resource" - so device_may_wakeup() is false and we're on the
reset path, as expected.

And the timeout is the THC, not the touch IC: across s2idle its SPI
input/output address and read/write config are gone, so reset_tic()'s
descriptor exchange has nothing valid to run against. Reprogram those
first - the thc_spi_input_output_address_config + read_config +
write_config block, same as quickspi_restore(), same as v2 on the no-wake
path - and reset_tic() completes and touch comes back. That's exactly why
v2 reconfigures the THC instead of only resetting the IC.

One more platform note: the SP10 never reaches S3. Firmware only offers
s2idle - mem_sleep is just "[s2idle]", with no "deep" entry to select -
yet the THC still loses its context across plain s2idle. So a reset gated
on S3 would never fire here, which is why it has to run on the ordinary
resume path.

Thanks,
Danny