On Mon, 22 Jun 2009, Sarah Sharp wrote: > Some drivers were calling usb_reset_endpoint() in interrupt or tasklet > context. The underlying host controller driver function reset_endpoint() > may block, so this is less than ideal. > > Create a new USB core function to start an asynchronous endpoint reset, > usb_start_reset_endpoint(). The driver's callback function will be > asynchronously called when the reset is finished. Add a new host > controller driver function start_endpoint_reset(), that will be called by > usb_hcd_start_reset_endpoint(). > > WIP: Change WHCI driver to use start_endpoint_reset() and do asynchronous > completions. Change the hisax and UB drivers to use > usb_start_reset_endpoint() I really don't think this is a good solution. It adds a lot of apparently unnecessary complexity. Why not instead require HCDs to be able to handle URB submissions while an endpoint reset is in progress? All this would require is a single "reset_in_progress" bitflag in the HCD's private endpoint structure. If the urb_enqueue method finds the flag is set, it accepts the new URB but leaves the hardware's endpoint queue stopped. When the reset is finished, the hardware queue is started if there are any URBs on it. No changes would be needed in usbcore or the interface drivers. 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
