David Brownell wrote, On 01/18/2009 02:30 PM: > On Saturday 17 January 2009, Robert Jarzmik wrote: >> My understanding of the gadget API is that it is the "setup()" duty to disable >> unecessary endpoints by calling pxa_ep_disable() when needed. > > Of the three "disable that endpoint" cases that come quickly to > mind, two are driven by the gadget driver's setup() callback: > > - SET_CONFIGURATION ... puts a bunch of interfaces in altsetting 0 > and guarantees all other endpoints are disabled > - SET_INTERFACE ... puts one interface in arbitrary altsetting, > which can involve enabling/disabling any number of endpoints > - disconnect ... scrubs all endpoint state > > Those first two are "config change events". SET_CONFIGURATION to zero > disables all endpoints except EP0. > > - Dave I was using the file storage gadget as a kernel module. During testing, I was unable to remove the module because of a soft-lockup. I found that the cause was the re-configuration of the gadget (I believe it was a SET INTERFACE) where the new USB endpoints did not correspond to PXA endpoints. Therefore, the queued requests could not be dequeued and the module removed. The dequeue code checks to see if the PXA EP is valid. If not, it aborts, leaving the USB EP with a request it cannot clean up. This patch guarantees that if a change in USB EP causes the EP to no longer have a PXA EP associated with it, the previous PXA EP is disabled and all requests dequeued so nothing gets stuck. Maybe the confusion is the name. I should have made it more clear that this patch is about *PXA* endpoints being decommissioned, not USB EPs. -- Regards, Vernon Sauder :) -- 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
