Re: Low speed BULK endpoints on UHCI

On Tue, 11 Sep 2007, Brad Campbell wrote:

> G'day all,
> 
> Perhaps I'm flogging a dead horse, and I *know* this came up only recently but my desire to see this 
> gross violation of the USB specs actually function is that "It works on the other two Operating 
> Systems - Win and OSX".
> 
> In addition, prior to the patch recently submitted by Alan Stern which converts low speed bulk 
> endpoints to interrupt, it used to work on any OHCI controller I had available.
> 
> The device in question is emulating a CDC-ACM device, and therefore used the usb-serial/generic 
> driver. If I comment out Alan's addition to control.c and use my OHCI card it works.. If I want to 
> use it on any of my desktop machines I need to comment out the check in uhci-q.c (which is a bit of 
> an ugly workaround).
> 
> I did see an objection raised last time this came up by David Brownell regarding the bulk packet 
> size starving the bus segment, but in my tests there appears to be zero difference between the bulk 
> packet size and the interrupt packet size in any case. They are both a maximum of 8 bytes for 
> low-speed and a minimum of whatever the device happens to send.
> 
> Monitoring this particular device, the average packet size to and from the device (bulk) is 1 or 2 
> bytes + sync, PID and CRC, just the same as an interrupt packet.
> 
> I know the device violates the USB Specs (I developed it).. but then quite a few appear to also. I 
> can't make it use full-speed as I'm doing the USB SIE in software and just don't have the cycles 
> available to get it to go that fast.
> 
> The other option is to find some way of making the usb-serial/generic driver able to substitute 
> interrupt for bulk endpoints where required (and I've spent a bit of time investigating that, but my 
> knowledge of the linux usb stack is pretty shaky)

People here would be glad to help you make that change.  IMO it's much 
less objectionable than allowing bulk endpoints on low-speed devices.

> It's a bit of a bugger when developing something to assist people developing hardware/software and 
> have to tell them they need to use Windows or MacOS as your firmware won't work with Linux.
> 
> I have my flame-proof undies on and am fully prepared to be shot down, I just wonder about the 
> *practical* reasons why we must enforce this limitation when the others don't and nobody seems to 
> complain? (Especially given half the hardware *OHCI* don't enforce it in any case)

The practical reasons are the ones mentioned by Dave Brownell.  Just 
because your device is nice and doesn't starve the bus, that doesn't 
mean other devices will be similarly well-behaved.

The hardware doesn't enforce the restriction because it expects the
software to do so.  So you can't rely on that argument.  :-)

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel