On Tue, Sep 18, 2001, David Brownell <[EMAIL PROTECTED]> wrote:
> > > > 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?  :)
> >
> > I think he means short packet in, not short packet out.
> 
> Except he said "send" ... ;)
> 
> For "in", why shouldn't a short packet terminate the whole series
> of transfers?  Underrun, overrun ... in both cases, the device and
> driver are significantly out-of-sync.

I think you're talking about something else. Obviously an underrun or
overrun should terminate all of the transfers.

What I was talking about was not putting ourselves into the situation
where we would have overrun's.

An overrun is a bug, in every case. It might be the host or the device,
but it should never happen.

JE


_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel

Reply via email to