On Tue, Sep 18, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > > Should be no different. Though the "multiples of endpoint size"
> > > restriction seems unnecessary to me ... "short packet" handling for
> > > each of a series of URBs should work transparently. The HCDs
> > > already have the infrastructure to do that.
> >
> > Not really, since for lots of devices, short packets mean something
> > special if we send one.
>
> I think you were assuming something different about s/g semantics
> than I was, then. If the driver chooses to put a short packet into
> an s/g list, I expected it did so to get that special effect. Perhaps
> you were thinking it was expecting the HCD to coalesce some
> buffers? How about just returning EINVAL? :)
>
> > Or if we say we can only accept 3 bytes and the device wants to send 8,
> > I wouldn't place any bets all devices would handle that gracefully.
>
> Transfers should stop on overrun errors, and report them as such
> (not as stalls :) The driver then gets to recover from the error.
We need to present the device transfers as big as possible up to the
endpoint size.
If the size of the chunks passed to the HC by a driver isn't a multiple
of the endpoint size (except the last) then we need to do nasty
coalescing and copying which is just annoying.
That's why I mentioned "multiples of endpoint size" since then it would
be much simpler.
JE
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
