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

Reply via email to