Alan Stern wrote: > 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 vague idea was to have usb_hcd_link_urb_to_ep() add the urb to the list and return -EAGAIN if the endpoint was inactive. When the endpoint is reactivated it would enqueue the urbs again. >> 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? I think so now. 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
