* 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. >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. >Signed-off-by: Daniel Mack <zon...@gmail.com> Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
