> >> > >> >> >The reason of above dump message is calling dma_poll_alloc with > >> >> >can- schedule mem_flags at interrupt context. Changing mem_flags > >> >> >from GFP_KERNEL to GFP_ATOMIC fix this problem. > >> >> > >> >> Thanks for the patch. But I think the proper way to fix this is to > >> >> use the gfp_flags parameter passed by fsl_ep_queue(). > >> >> > >> >Hi Leo, current allocate dtd descriptor code are all at atomic > context. > >> > >> Most of the usb_ep_queue() are using GFP_ATOMIC, but there are a few > >> using GFP_KERNEL. For example start_transfer() in file_storage.c. > >> > >It is in spin_lock_irqsave/spin_unlock_irqrestore. > > You are quite right. But on a second thought, it seems to me that the > fsl_req_to_dtd() doesn't need to hold the lock while fsl_queue_td() does. > Might need to change that also? > Correct, we don't need to protect current struct usb_request, but need to protect hardware visit at fsl_queue_td(). So, is it ok I post v2 patch by adding gfp_flags to fsl_queue_td, and move lock from beginning of fsl_req_to_dtd to beginning of fsl_queue_td? > - Leo -- 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
