On Fri, Aug 21, 2009 at 05:08:27PM -0400, Alan Stern wrote: > On Wed, 19 Aug 2009, Sarah Sharp wrote: > > > Hmm, yes that is a problem. Ok, say that xhci_free_streams() always > > guarantees that there's room on the command ring, and it retries the > > command twice. Say that still fails when a driver is being unbound > > during reset. usb_reset_device() can look at the number of streams > > enabled for each endpoint after an unbind and do something if it's > > non-zero. > > > > What should it do? Disable the port and deallocate the device? At that > > point we're probably dealing with a busted host controller that doesn't > > implement internal resource counting or bandwidth allocation properly. > > At that point your best course is probably to print an error message in > the system log and proceed in a degraded mode (kind of like leaking > memory). When the hardware's bad there's not much else to do. > > In fact, can't you use the un-freed streams to satisfy later allocation > requests? Sure, as long as the driver asks for the same number of streams (or less than the previous request) and passes the same endpoints. I'll have to modify the streams allocation code to return success in that case, rather than failing early because streams are already enabled. I'm not sure if I want to handle the case where some endpoints have streams enabled, and some don't. It makes the code pretty complicated. Sarah -- 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
