Re: [PATCH v2 1/5] usb: musb: move port reset to worker

[Daniel Mack <zonque@gmail.com>]

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