lkml.org 
[lkml]   [2004]   [Mar]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [ANNOUNCE] RNDIS Gadget Driver
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
> works :-)

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.

- Dave



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:02    [W:0.096 / U:0.040 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site