On Tue, Oct 15, 2024 at 03:23:23PM +0300, Mathias Nyman wrote: > In addition to fixing this NEC case we could think about avoiding these > cases, some could be avoided by adding a new ".flush_endpoint()" callback to > the USB host side API. Usb core itself has a usb_hcd_flush_endpoint() function > that calls .urb_dequeue() in a loop for each queued URB, causing host to > issue the stop, move deq and ring doorbell for every URB. > > If usbcore knows all URBs will be cancelled it could let host do it in one go. > i.e. stop endpoint once. Indeed, this makes a lot of sense, and I have long thought that the API should have been designed this way from the beginning. At least for non-Control transfers, unlinking a single URB somewhere inside a sequence of URBs seems pointless. I doubt that it ever happens in the kernel. (On the other hand, it _is_ reasonable to do this for Control transfers, because they can come from several different sources, not just from the device's driver. The source for a Control URB might want to unlink it while not affecting the URBs from other sources.) Furthermore, I suspect this is what Windows does and what the USBIF originally had in mind for URB management. (It's harder to tell what they thought about Control transfers, though.) Alan Stern
