Re: [ANNOUNCE] RNDIS Gadget Driver

[David Brownell]

Robert Schwebel wrote:
> On Fri, Mar 26, 2004 at 07:58:04AM -0800, David Brownell wrote:
>
> > > > > -	.bDeviceClass =		DEV_CONFIG_CLASS,
> > > > > +	.bDeviceClass =		0x02,
> > > >
> > > > Is this wise?
> > >
> > >
> > > Until now DEV_CONFIG_CLASS was 0xFF, which results in Windows getting
> > > hickup. If you directly set this to 0x02 (Network Device) Win is happy.
> >
> > Actually I suspect setting it to USB_CLASS_COMM would be preferred, in
> > RNDIS-specific config descriptors....

(since:  #define USB_CLASS_COMM                  2)


> We have tried that, Windows does not like it. The only constellation
> where it worked was setting the device descriptor's bConfigClass=0x02. 

Sorry, I meant "device" descriptors.  Yes, I noticed their "spec"
had strange things to say.  Is there some reason you're not including
the CDC header and union descriptors?  That spec does talk about those,
and the erratum I found also talks about better CDC ACM conformance.


> RNDIS is a sensitive beast. Do one bit different results in that uggly
> "Error 10" message on the Windows side. We saw it when we started with
> the driver, we saw it when the driver was half way finished and we will
> see it again if somebody tweaks the driver without exactly knowing what
> the guys at Microsoft smoked when they designed that protocol :-) 

I thought it was "just say no to vendor-neutral protocols" crack ...
although that close to BC they would have much better options! ;)

The purist in me is annoyed that rather than just defining a purely
vendor-specific protocol, they re-used bits and pieces of the USB-IF
CDC-ACM spec.  It's not like they needed _any_ of it.  (Unless maybe
subtle sabotoge of CDC was a goal?)



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.

Also it looks like you've only tested this on PXA hardware.
Most of the patch is the (R)NDIS support code, which is easy
to merge, but the "g_ether" updates will take longer.

- Dave



> Robert


-
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/