On Wed, Mar 01, 2006 at 07:30:16PM -0800, David Brownell wrote:
> The thing to understand about test #10 is that it's _trying_ to do things
> that UDC drivers often get wrong. Trying to trigger races ("both events
> in one IRQ"), trying to issue back-to-back faults so that improper cleanup
> of one will make the next one go splat (or the request after both), trying
> to make sure that the _right_ fault modes appear (both in the HCD and in
> the UDC), trying to make sure short packets get handled correctly.
>
> Trying to make those failures happen in the "lab" where they're easy to
> reproduce, watch, and fix ... rather than in the field where that's
> decidedly untrue. Control transfers are quite complex. It's usually
> harder to get them right than it is to get for example bulk DMA to work.
...and I'm really glad for that.
I think I'm getting the picture. The AT driver ought to help as an
example of how something is supposed to flow. The only other thing
that would be really helpful would be a correct output from USB mon
when running test #10. I'll see if I can glean anything now in the
absence of a high-speed hub.
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
