Overrun is an error in all cases... but underrun (at least on device to
host) is not. In fact, it's pretty normal.
Matt
On Tue, Sep 18, 2001 at 05:21:08PM -0400, Johannes Erdfelt wrote:
> 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
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
C: Like the Furby?
DP: He gives me the creeps. Think the SPCA will take him?
-- Cobb and Dust Puppy
User Friendly, 1/2/1999
PGP signature
