On 02.10.2013 12:46, Sebastian Andrzej Siewior wrote: > * Daniel Mack | 2013-10-01 15:39:53 [+0200]: > >> musb_port_reset() sleeps, so we can't call it from atomic context. It >> is, however, called from places inside musb_hub_control() while >> &musb->lock is held, which leads to a "scheduling while atomic" warning. > > I guess you are hit by the msleep(1) here. Yes. >> Fix this by moving the logic into a worker, and call it where the >> function was previously called directly. > > I *think* the better approach here would be to replace the msleep(1) by > a busy loop. The thing is that you do now want to continue the operation > and having the reset in progress. It should complete _right_ _now_ i.e. > SET_PORT_FEATURE RESET is completed before the the next SET/GET request > arrives and with a workqueue you can not guarantee this. Hmm, ok. I'm just not sure what time periods we're really sleeping for here. After all, we're blocking all interrupts from occuring while the lock is held. So my question is rather whether it's sensible at all to hold the lock while waiting. We might change some of the execution pathes to mutexes and waitqueues as well. Felipe? Thanks, Daniel -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
