Rather than answering the question, I'll say just avoid using urb->next as it deserves to go away (this isn't the only good question to have about it :), and is not needed.
The way drivers are expected to use this is to queue a bunch of ISO URBs (automatic for ISO, but for BULK you need a magic flag before the UHCIs permit it, sigh) and rely on them being linked in a ring to cause automagic resubmission. Drivers can instead do what the audio driver has done for a long time: queue the ISO URBs, but have your completion callback do the resubmit. Advantages: less hidden magic, more consistent behavior from the HCDs, and should there ever be an error on resubmission you'll actually know about it rather than having it silently hidden by the HCD. - Dave ----- Original Message ----- From: "Magnus M�rtensson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, April 16, 2002 4:31 AM Subject: [linux-usb-devel] URB's next ponter > Hi. > I have a question that I once and for all would like to make clear. URBs that are > linked together, are they always meant for the same endpoint-id on a device or can > linked URBs have different endpoint-id:s. > > /Magnus > _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
