2015-07-30 8:59 GMT+02:00 Dmitry Torokhov <dmitry.torokhov@xxxxxxxxx>: > On Sat, Jul 11, 2015 at 01:47:48AM +0200, Pavel Rojtberg wrote: >> From: Pavel Rojtberg <rojtberg@xxxxxxxxx> >> >> track the active status of the irq_out URB to prevent submission while >> it is active. Failure to do so results in the "URB submitted while >> active" warning/ stacktrace. >> >> Also add missing mutex locking around xpad->odata usages. >> >> This is an workaround for a suspend/ resume issue on my machine, where >> after resume irq_out is completely dead. >> >> In preliminary testing I could not observe any dropping of packets. >> (controlling rumble with fftest while setting the LEDs using sysfs) >> If there actually are cases where packets are dropped an extension of >> this patch to queue the URBs instead of dropping is straightforward. > > We need to implement it. If you weren't able to reproduce the race it > does not mean it does not exist. I will probably just back out this one from v2. It is not quite clear to me whether we are at fault here for not buffering the packets or the userspace for submitting too many. Furthermore I found out that I can wake up irq_out by resetting the usb device after suspend/ resume. This would be a better fix for my issue at hand. > Also you can not take mutex in xpad_play_effect as it is called under a > spinlock with interrupts disabled. Should the odata_mutex better be replaced by a spinlock then? > Thanks. > > -- > Dmitry -- 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
