This series pushes the processing of SET INTERFACE and SET CONFIG for all composite gadgets into process context via a workqueue. This makes it possible to call ->ep_disable() in process context. The UDC in turn may sleep/wait until it canceled all outstanding requests and may then continue. The patch(es) rely on the DELAY_STATUS hack which is used by the mass storage gadget(s). All UDCs have some kind of hacks to make this work. Most of them rely on the fact that wLength is 0 so it is not possible to push all requests into the process context. All requests are enqueued into the nrw work queue which ensurues that only one work item is executed at time within the whole system. That means multiple disconnects / set_interface calls are executed in the same order they occured (but later). Using threaded interrupts would create the process context which we need but does not really solve the problem because the UDC can no longer receive the "command complete" interrupt after canceling the transfer because the interrupt routine is blocked. Not to mention the spin lock conversion in every gadget. The other possible sollution would be to push the ->setup() gadget into a workqueue. I don't think that it is a must to run in "real quick" in interrupt context since it is not a hot path. Once it runs in process context it does not need the DELAYED_STATUS hack because it wait until the gadget completed its work. The mass storage gadget could wait on a completion until its done (so it can still keep its custom thread). This requires changing _every_ udc driver to queue status data into a workqueue and not to continue processing ep0 until the workqueue is done. The next thing is to synchronize this against the disconnect interrupt. Before starting this I would like to see all UDCs using the same start/stop vs udc_start/udc_stop mechanism before starting a new kind of sub interface. Sebastian -- 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
