On Fri, Dec 18, 2015 at 05:10:31PM +0100, Benjamin Tissoires wrote: > After turning this around, I think I finally got what was going on (and > yes, it's basically a race that should have been caught long ago): > - during resume, the i2c-hid driver calls reset, which is a long (few > ms) operation. > - hid-multitouch is also called during resume, and right after i2c-hid > - hid-multiotuch immediately emits for touchpads a set input mode (this > was unseen with touchscreens because they do not have to be switched > into a proper mode) > - there is a race between hid-multitouch accessing the features while > the device is still resetting. And our reset interrupt never gets to > us because there was an other operation in progress to request/set > reports > > So the actual fix would be to make hid-multitouch wait until we reset > i2c-hid. The driver used for touchpad is actually hid-rmi but you are right, it tries to set rmi mode (or something) during its rmi_post_reset() that then confuses the i2c-hid driver. Thanks for the analysis :-) > This should be done by either a mutex or a spinlock in > i2c_hid_output_raw_report() and i2c_hid_resume() that would protect a > flag set during suspend and cleared after resume. Makes sense. I'll make a patch that does this and submit it soon. -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
