Re: [ANNOUNCE] RNDIS Gadget Driver
From: David Brownell
Date: Fri Mar 26 2004 - 14:47:49 EST
Robert Schwebel wrote:
The problem is that, as it is now, it works. The whole RNDIS stuff is
extremely time intensive to debug: when you have one odd value in some
place, Windows just says "Error 10" and you have to guess what you did
wrong. No further information available. So the best way to be
successful may be to check it in as it is, maybe add some FIXMEs, and
let the masses test the code. Then cleanup the remaining issues step by
step and wait until nobody crys any more :-)
Well, what I merge is necessarily going to work on more
hardware than just PXA ... it'll work over net2280 (at high
speed), goku, and surely other hardware. In most cases
that'll just require sanity testing. Maybe I can get Julian
to test on SH3, and it sounds like Andrew is getting close
on the MediaQ.
Once I can see it work, then it'll be ready for that more
widespread testing. (Do penguins actually cry?)
Different topic: I noticed that on PXA you were using "ep5-int".
That's documented as always using DATA0 -- data toggle not working.
Was that making any trouble for you? I've never actually tried
using those endpoints, because of that functional limitation.
Well, there is no other interrupt endpoint on the PXA, and it somehow
It's not as if the protocol actually _needs_ an interrupt endpoint,
though the MSFT spec says it does. It's actually simpler for the
host to poll for completion on the control endpoint; none of the
requests should take very long to finish anyway. An RNDIS host
might not even notice those "toggle broken" issues.
Did you have any evidence that the MSFT host was actually using
that interrupt endpoint? Like CATC snooping showing it never
tried to collect responses until the interrupt packet arrived?
Also, which versions of MS-Windows did you test against? Some of
the MSFT docs suggest version-specific protocol quirks. That's
where I expect most of the end-user problem reports to appear!
Which is why I'd like to have all the documented protocol quirks
(including the other CDC descriptors) resolved before this starts
to get really broad testing.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/