On Thu, 24 Jul 2003, Johannes Erdfelt wrote: > On Thu, Jul 24, 2003, David Brownell <[EMAIL PROTECTED]> wrote: > > Johannes Erdfelt wrote: > > > This should probably go into the core since every HCD needs it to be set > > > to 0. > > > > If we keep it, yes. But the only use of error_count seems to be > > in debug printk() calls ... is there a real reason to keep it around? > > Anyone who really needs it can count urbs for which urb->status != 0, > > it's clearly not necessary. > > You mean the ISO descriptors where status != 0? > > If so, I agree. It is superfluous.
Me too. It is currently used only by the audio, dabusb, and usbvideo drivers -- and all they do is print it in various logging messages. > > If it's bogus, yes return an error. Some new errno value. > > Kind of. It's not like it doesn't make sense, but that leaving this > unbounded would make all of the HCDs more complicated for little gain. > > > > If the calling driver wants to do this, submit it as 2 seperate requests > > > at the correct time. > > > > It'd also be good to let USB device drivers know the biggest iso period > > that can be scheduled. It's not necessarily the same as the biggest > > interrupt period, and on EHCI it's also configurable. Otherwise drivers > > will not be able to tell in advance what requests are legal. > > Is it always as large or larger than 1024 frames? > > UHCI has a fixed schedule of 1024 frames, so scheduling further than > that isn't easy. > > If OHCI and EHCI greater than or equal to 1024, might as well make it a > fixed limit of 1024 frames. We shouldn't rely on a fixed bound like 1024 because in the future someone might come along with a HCD that only uses 512. Consider this way of informing device drivers: If the submitted value is too large, return status = -EFBIG (already mentioned in Documentation/usb/error-codes.txt) and put the maximum allowed number of frames in actual_length. On the other matters... I didn't mean to suggest that the fsbr_timeout() stuff should be removed; I was just trying to understand it. Also, I think a 0-length iso. descriptor should be legal. It would mean sending a 0-length packet, which doesn't violate the USB spec and might even be meaningful to some type of device (as a "heartbeat" signal maybe, although an interrupt transfer would be more appropriate for that). Alan Stern ------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01 _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel