On Thu, 18 Jun 2009, David Vrabel wrote: > 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). What would it mean to usbcore for an endpoint to be inactive? It doesn't mean to stop accepting URB submissions for that endpoint. It doesn't mean to stop sending the submissions to the HCD's enqueue method, unless you want to end up with a situation where there are URB's on the endpoint's queue that the HCD hasn't approved of (which doesn't seem like a good idea). > 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. Are you suggesting that each endpoint should have _two_ queues, where usbcore puts URBs on the second queue while the endpoint is inactive and then tranfers them to the first queue by sending them to the HCD when the endpoint is activated again? Wouldn't it be easier to require the HCD keep track of its own inactive endpoints? 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
