Alan Stern wrote: > > Another possibility, perhaps simpler, is this: Make the HCD's > endpoint_reset method always runnable in interrupt context, and have > it mark the endpoint (or QH or whatever) to indicate that it is being > reset. New URB submissions will be accepted but delayed until the > reset finishes. usbcore should mark the endpoint as being inactive and it should handle queuing things on it (it does this already after all). The HCD's endpoint_reset() simply needs to start the reset process, When it's done the HCD should call a (new) usbcore function to activate the endpoint again (usb_hcd_endpoint_activate()), trigging usbcore to start giving urbs to the HCD again. It may also be useful to have a usbcore function to force an endpoint to be inactive (usb_hcd_endpoint_inactivate()) but I can't think of an use right now. If no one else does this, I can look into it in a week or so. David -- David Vrabel, Senior Software Engineer, Drivers CSR, Churchill House, Cambridge Business Park, Tel: +44 (0)1223 692562 Cowley Road, Cambridge, CB4 0WZ http://www.csr.com/ -- 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
