On Saturday 17 January 2009, Oliver Neukum wrote: > > > What HCD change(s) were you thinking of? > > HCDs shall not call the completion handler from the context that > called usb_submit_urb(), if necessary from a workqueue. That wouldn't address $SUBJECT **at all** ... the issue is calling completions from the context issuing usb_unlink_urb(). Phasing in such a context restriction could be problematic, and of course there's the issue of actually getting and testing patches for all the relevant HCDs. Could usbcore at least detect that an HCD isn't adhering to such new rule? There's a complementary issue ... a completion callback may call usb_unlink_urb(). I'd have to think more about that, but be very cautious about changing _those_ semantics. On fault paths, a completion callback must be able to unlink every URB in the queue for its endpoint, without letting any of them hit the hardware. Last time I thought about this issue, I kept thinking that what's *really* needed is getting rid of one-at-a-time semantics for unlinking URBs ... and replacing them with "unlink everything queued to this endpoint" semantics. I don't recall even one case where "dequeue just one URB" was really the desired usage model. It's a leftover from the early USB work for the Linux 2.2.8+ kernel. > Do you know which HCDs are affected? The unlinking issue generally applies to any HCD that doesn't have to disable hardware queues to unlink. It's the "disable queue" which forces a contex switch on stuff like EHCI/OHCI/UHCI, so they don't see $SUBJECT. Right off the top of my head: sl811_hc and musb_hdrc both have purely software queues, and can (do!) process unlinks immediatly. Plus there's the HCD associated with the $SUBJECT bug report ... ISTR seeing a comment from Jeremy about other affected HCDs. - Dave -- 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
