Re: Re: usbback cleanup code

[Harry Butterworth <harry@hebutterworth.freeserve.co.uk>]

On Mon, 2006-05-01 at 20:32 +0100, Mark Williamson wrote:

> There were a lot of files added by your patch which appeared to be utility 
> code / abstractions.  This is fine in general, but the other drivers seem to 
> get away with much less of this kind of thing without suffering unduly in 
> terms of complexity.

I don't think the other drivers are expressed in a way that allows the
reader to see that they are obviously correct.  I found them fairly
difficult to read and I think they could be improved with some
additional internal structure.

> I didn't have time to study the code in detail, but I 
> wasn't convinced they were all strictly necessary.

This feedback isn't specific enough to be useful for me to improve the
patches to your liking.

> > The most difficult remaining work is to fix the protocol to correctly
> > stall URBs during error recovery.  I was involved in some discussion
> > about this on the USB mailing list and there was a proposal for a
> > solution but it is fairly tricky.  Stalling URBs is required when there
> > is a queue of URBs and an URB fails.  If the URBs are not stalled then
> > they may be submitted to the device out-of-order which is a
> > data-integrity exposure.
> 
> Any reason not just to fail all the URBs on the queue?

There was some discussion about this on the USB mailing list.
Apparently the URBs on the control endpoint can have more than one
source (presumably the USB stack and the USB driver) and failure for one
client shouldn't impact another client.

Harry.