Re: [regression] Bug 219440: Touchscreen stops working after Suspendi: i2c_designware.1: controller timed out

Re: [regression] Bug 219440: Touchscreen stops working after Suspendi: i2c_designware.1: controller timed out

[Linux regression tracking (Thorsten Leemhuis)]

On 05.11.24 17:06, Linux regression tracking (Thorsten Leemhuis) wrote:
> Hi, Thorsten here, the Linux kernel's regression tracker.
> 
> Jarkko, I noticed a report about a regression in bugzilla.kernel.org
> that appears to be related to i2c_designware [...]

After a bisection it turns out the regression is caused by a HID change
from Kenny, thus dropping Jarkko from the list of recipients and adding
Kenny and a few other appropriate folks and lists.

The culprit appears to be 7d6f065de37c31 ("HID: i2c-hid: Use address
probe to wake on resume") [v6.10-rc1].

For the rest, see the quote below or the linked ticket:

> To quote from
> https://bugzilla.kernel.org/show_bug.cgi?id=219440 :
> 
>>  Michael 2024-10-29 08:43:55 UTC
>>
>> Just noticed that the touchscreen on my ASUS vivobook S14 stops
>> working after a suspend-to-idle. As this is something, I clearly
>> didn't have before, I tested every kernel version released in the
>> last six months and found the kernel, where the bug was introduced:
>> 6.10. The last 6.9.12 is still working correctly. Since 6.10 all
>> kernel versions have the problem.
>>
>> Some more info:
>>
>> Hardware: ASUS Vivobook S14 (TP3402VA) Kernel working: up to 6.9.12 
>> Kernel defect: from 6.10 OS: nixos
>>
>> I do not have much knowledge about the input devices. I tested that
>> i2c_hid_acpi seems to be relevant for the touchscreen (and also the
>> touchpad), as, when I remove it, both stop working. Reloading the
>> kernel module restores functionality (but NOT after a suspend-to-
>> idle!!!). Otherwise, I do not see any error messages or so. (Or do
>> not recognize them...)
>>
>> Any help I can offer to identify the regression bug?
> 
> [...]
> 
>> 6.12-rc4 does not work either. The regression started with 6.10.
> 
> [...]
> 
>> i2c_designware i2c_designware.1: controller timed out
>> i2c_designware i2c_designware.1: timeout in disabling adapter
>> i2c_hid_acpi i2c-WDHT1F01:00: failed to change power setting.
>> i2c_hid_acpi i2c-WDHT1F01:00: PM: dpm_run_callback(): acpi_subsys_resume returns -110
>> i2c_hid_acpi i2c-WDHT1F01:00: PM: failed to resume async: error -110
> [...]
> 
> See the ticket for more details. The reporter (Michael) is CCed.

Ciao, Thorsten

Re: [regression] Bug 219440: Touchscreen stops working after Suspendi: i2c_designware.1: controller timed out

[Kenny Levinsen]

Thanks for the heads up!

> i2c_designware i2c_designware.1: controller timed out
> i2c_designware i2c_designware.1: timeout in disabling adapter
> i2c_hid_acpi i2c-WDHT1F01:00: failed to change power setting.
> i2c_hid_acpi i2c-WDHT1F01:00: PM: dpm_run_callback(): acpi_subsys_resume returns -110
> i2c_hid_acpi i2c-WDHT1F01:00: PM: failed to resume async: error -110

Hmm, that's interesting. Michael, would you be up for testing a debug 
patch or two? The "dumb" solution of just re-adding a retry of the power 
command (always or as a quirk) on resume and crossing our fingers would 
probably work as a regression fix, but I have a vague suspicion that the 
issue could just be the change in timing.

As an aside, do we have anything available for testing/analyzing quirky 
i2c_hid hardware other than hoarding laptops on our own? Do some 
maintainers keep quirky devices around for re-testing, or are we mostly 
relying on user regressions? Getting feedback - or better yet, logic 
analyzer traces - would be really helpful when touching drivers for 
quirky hardware, and I haven't had too much luck on finding reasonable 
deals on affected hardware myself, halting some of my i2c/i2c_hid 
improvements...

Best regards,
Kenny Levinsen