[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <75ada7e6-3796-4ebc-b824-fc8a57b0c1df@kl.wtf>
Date: Fri, 8 Nov 2024 13:23:13 +0100
From: Kenny Levinsen <kl@...wtf>
To: Linux regressions mailing list <regressions@...ts.linux.dev>
Cc: Michael <auslands-kv@....de>, LKML <linux-kernel@...r.kernel.org>,
Jiri Kosina <jkosina@...e.com>,
"open list:HID CORE LAYER" <linux-input@...r.kernel.org>,
Benjamin Tissoires <bentiss@...nel.org>
Subject: Re: [regression] Bug 219440: Touchscreen stops working after
Suspendi: i2c_designware.1: controller timed out
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
Powered by blists - more mailing lists