On Fri, 20 Jan 2012, Nikolai Zhubr wrote: > Hello people, > > Meanwhile I've moved a bit further and now I have another. The listing > below shows basically that dma_alloc_coherent() was called from irq > context which is not a good thing to do IIRC. Here this happens because > gadget driver (specifically, g_serial's composite_setup() function in > this case) is called from irq context by dwc driver and then requests EP > change which subsequently results in dma_alloc_coherent as implemented > in dwc driver. (g_file_storage does not show this problem for some reason) > So, supposedly something have to be moved out of irq context > (scheduled). Now this is a bit too compicated for me to start from > scratch, so question is, is there something I could use as a known-good > reference example? This is a serious problem. The gadget API does not specify whether usb_ep_enable and usb_ep_disable should be able to run in interrupt context. Consequently we end up with UDC drivers like your DWC thing in which the routines cannot run in interrupt context, together with gadget drivers like g_serial which do call them in interrupt context. It may be that the best solution is for the composite.c driver to implement Set-Config and Set-Interface requests in a workqueue, so that the calls could be made in process context. For now, you can avoid the problem by not calling dma_alloc_coherent in your endpoint-setup routine. g_file_storage doesn't have this problem because it uses its own kernel thread for handling these requests. Alan Stern -- 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
