Hrm... Well, I can try this as an experiment... just assume that the clear halt has worked... tho the logs suggest that it didn't.
And, this doesn't explain why the code used to work but doesn't now. We
used to be able to clear halts with this code -- so what went wrong?
Matt
On Thu, Oct 03, 2002 at 10:21:15PM -0700, David Brownell wrote:
> Wolfgang Mües wrote:
> > Hello,
> >
> > On Monday 30 September 2002 16:24, Alan Stern wrote:
> >
> >>Actually, it is possible to receive EPIPE for a control endpoint. But it
> >>shouldn't happen very often. In fact, with normal use we shouldn't see it
> >>at all.
> >
> >
> > Oh yes, I have seen it. EPIPE on control endpoints. Mostly with the usb-uhci
> > driver (Linux 2.4.10). It was no STALL but a transmission error. There was a
> > spike on the USB data lines, and the host is doing 3 retries. All 3 retries
> > failed because the spike was longer than all the retries.
>
> So it seems like receiving -EPIPE is legal and common enough to notice in
> robust drivers for reasonable devices, both because of protocol stalls and
> transmission errors. (It'd be nice if those two were fully distinct, but ...)
>
> What was a bit surprising to me was the bit Alan quoted from [9.4.5] that
> said devices can actually set a halt condition on control endpoints for
> "functional error conditions" (though it's not recommended) if, as it says
> in [8.5.3.4], they're not "well designed" devices.
>
> I think that means that some drivers, maybe even usb-storage, might need
> to be able to clear halts on the control pipe, if they talk to devices that
> are not "well designed". BUT any driver that tries should expect that most
> devices return protocol stalls (-EPIPE) when asked to clear halts.
>
> Matt, does this help resolve your issue?
>
> - Dave
>
>
--
Matthew Dharm Home: [EMAIL PROTECTED]
Maintainer, Linux USB Mass Storage Driver
It was a new hope.
-- Dust Puppy
User Friendly, 12/25/1998
msg08309/pgp00000.pgp
Description: PGP signature
