Re: [BUG] HID: i2c-hid: ELAN 04F3:30FD touchpad reset race causes -EREMOTEIO on HP Pavilion Gaming 15-ec1xxx

Thanks for the detailed hypothesis - here are the results.

I did 5 warm boots (reboot) and 5 cold boots (shutdown, wait, then
power on), with dyndbg still enabled, and physically tried moving the
touchpad after each one. Subjectively, the touchpad did NOT respond to
touch in any of the 10 boots - I never saw the cursor move.

However, when I went through the logs afterward, I noticed something
odd: in one of the 5 warm boots (boot #4) and one of the 5 cold boots
(boot #4), the log shows the device transitioning from repeated
-121 errors into a long stream of "input: ..." lines with what look
like changing/plausible HID report data - 1353 such lines over about
28 seconds in the warm case, 441 lines in the cold case (that one
kept going intermittently, mixed with more -121 "failed to set a
report" errors, for several minutes based on the timestamps - I let
it sit rather than immediately rebooting).

So the kernel-level input events appear to have been getting
generated in those two runs, but I did not perceive any cursor
movement, and I don't have an explanation for that discrepancy - I
was actively trying to move the touchpad during that window in both
cases. I don't know if this is meaningful (e.g. some kind of
noise/garbage data that happens to look like report data) or if
there's a userspace/libinput layer issue on top of a technically
"working" kernel driver. Attaching both full logs
(warm-boots.txt, cold-boots.txt) in case the raw data is useful -
each file has all 5 boots separated by a blank line.

Overall: no clear cold-vs-warm pattern from this sample (1/5 success
in each category, by the log's definition of "success" - not by my
subjective experience of the touchpad working).

I also ran your unbind/bind commands on the platform driver during a
dead state:

echo AMDI0010:03 | sudo tee /sys/bus/platform/drivers/i2c_designware/unbind
echo AMDI0010:03 | sudo tee /sys/bus/platform/drivers/i2c_designware/bind

This did trigger a fresh probe (dmesg shows "HID probe called for i2c
0x15" right after, and the HID descriptor was fetched successfully
this time), but the reset/power-setting sequence right after still
failed the same way:

  i2c_hid_xfer: cmd=05 00 00 01
  failed to reset device: -121
  i2c_hid_set_power
  i2c_hid_xfer: cmd=05 00 01 08
  [repeats a couple more times, same errors]

So as you suspected, it did not recover functionality - the platform
driver rebind gets further than a cold boot sometimes does (descriptor
fetched right away) but still fails at the reset/power stage. I also
physically tried moving the touchpad afterward - still completely
unresponsive.

Let me know if a larger sample size (more boots) or anything else
would help narrow down the input-events-without-perceived-movement
discrepancy.

Thanks,
Adam