On Wed, 2010-03-03 at 09:58 -0800, Sarah Sharp wrote: > Well, patches 2, 3, 4, and 5 are really about adding one thing: > isochronous support. Patch 1 really should be separate to show that > adding the urb_priv structure doesn't effect the other types of > transfers. Patch 6 should probably be a separate thing if it gets in at > all. But splitting patches 2-5 up makes it a bit harder to review and > spot bugs. Maybe you just want to combine patches 2-5? OK. I'll combine patches 2-5. > I do want to make sure some code in your patchset addresses the > cancellation and hardware dying case. They're really not "extreme" > situations. A driver could be unloaded immediately after submitting > URBs and have to cancel them right away. As for the hardware dying > code, it's used to handle PCI express card removal, which is pretty > common if your card sits loose in the slot and you bump it occasionally. > > Here's my suggestion for the cancellation case: > - Add all the TDs in an URB to the endpoint's cancellation list. > - When processing a canceled TD when the endpoint ring is stopped, > increment the new field in urb_priv for the number of TDs completed. > - Only giveback a canceled URB if the count of TDs completed matches > urb_priv->td_cnt. > > This should ensure that all the isochronous TDs are removed from the > hardware ring, and the isochronous URB is only given back once. You can > do a similar thing for the hardware dying case. Thanks for the comment. I'll refine the patches with cancellation and HW dying cases. -- Thanks, Andiry -- 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
