Hi All, Here is v2 of my i2c-hid series reworking how the i2c-hid-core waits for reset to complete. Further testing on the laptop for which I2C_HID_QUIRK_NO_IRQ_AFTER_RESET was first introduced, shows that reading the report descriptor before waiting for the reset helps with the missing reset IRQ, but it only helps some of the time. About 50% of the time the reset still does not get acked properly. Therefor for this v2 I have dropped the patch dropping the I2C_HID_QUIRK_NO_IRQ_AFTER_RESET quirks and I've demoted this series to a RFC. It is basically ready for merging, but first the question if this should be applied at all should be discussed: Advantages of merging this series: 1. Reading descriptors before waiting for reset does make the reset ack IRQ happen some of the time, so it does seem to improve things somewhat and maybe it does fully fix the issue on some other models 2. This should reduce the probe time of the i2c-hid driver Disadvantages of merging this series: 1. Non 0 chance of this causing regressions Changes in v2: - Drop the patch dropping the I2C_HID_QUIRK_NO_IRQ_AFTER_RESET quirks - Add a patch changing a missing reset ack from an error into a warning - Move the mutex_[un]lock(&ihid->reset_lock) calls out of i2c_hid_start_hwreset() / i2c_hid_finish_hwreset() and into their callers, as suggested by Douglas Anderson Original v1 cover-letter: Looking at: "2247751 - Touchpad not working on Lenovo Thinkbook 15 Gen 5" https://bugzilla.redhat.com/show_bug.cgi?id=2247751 I thought at first that this was another touchpad needing a I2C_HID_QUIRK_NO_IRQ_AFTER_RESET quirk, further testing has shown this seems to be an IRQ not working issue though, so this series does not help for that bug. The bug has made me revisit I2C_HID_QUIRK_NO_IRQ_AFTER_RESET though and it made me look at Microsoft's i2c-hid docs again and I noticed the following: """ 4. Issue a RESET (Host Initiated Reset) to the Device. 5. Retrieve report descriptor from the device. Note: Steps 4 and 5 may be done in parallel to optimize for time on I²C. Since report descriptors are (a) static and (b) quite long, Windows 8 may issue a request for 5 while it is waiting for a response from the device on 4. """ which made me think that maybe on some touchpads the reset ack is delayed till after the report descriptor is read ? Testing a T-BAO Tbook Air 12.5 with a 0911:5288 (SIPODEV SP1064?) touchpad, for which the I2C_HID_QUIRK_NO_IRQ_AFTER_RESET quirk was first introduced, shows that about 1 ms after the report descriptor read finishes the reset indeed does get acked. So this series refactors the reset handling to move the waiting for the ack to after reading the report-descriptor, so that the I2C_HID_QUIRK_NO_IRQ_AFTER_RESET quirk is no longer necessary. Regards, Hans Hans de Goede (7): HID: i2c-hid: Fold i2c_hid_execute_reset() into i2c_hid_hwreset() HID: i2c-hid: Split i2c_hid_hwreset() in start() and finish() functions HID: i2c-hid: Switch i2c_hid_parse() to goto style error handling HID: i2c-hid: Move i2c_hid_finish_hwreset() to after reading the report-descriptor HID: i2c-hid: Turn missing reset ack into a warning HID: i2c-hid: Remove I2C_HID_QUIRK_SET_PWR_WAKEUP_DEV quirk HID: i2c-hid: Renumber I2C_HID_QUIRK_ defines drivers/hid/i2c-hid/i2c-hid-core.c | 134 +++++++++++++++-------------- 1 file changed, 70 insertions(+), 64 deletions(-) -- 2.41.0
