On Tue, Oct 13, 2009 at 08:31:09PM -0700, David Brownell wrote: > On Wednesday 23 September 2009, Greg Kroah-Hartman wrote: > > From: Brian Niebuhr <bniebuhr@xxxxxxxxxxxxx> > > > > This patch adds a CDC EEM ethernet gadget driver. > > Good ... but can we get patches to fix the following: > > > > --- a/drivers/usb/gadget/ether.c > > +++ b/drivers/usb/gadget/ether.c > > @@ -61,6 +61,11 @@ > > * simpler, Microsoft pushes their own approach: RNDIS. The published > > * RNDIS specs are ambiguous and appear to be incomplete, and are also > > * needlessly complex. They borrow more from CDC ACM than CDC ECM. > > + * > > + * While CDC ECM, CDC Subset, and RNDIS are designed to extend the ethernet > > + * interface to the target, CDC EEM was designed to use ethernet over the USB > > + * link between the host and target. > > Someone's been drinking the marketing kool-aid. ISTR reading > those words in some USB-IF document, then immediately translating > them as "Microsoft craving justification for RNDIS". :) > > The "CDC Subset" was designed to do *exactly* the same thing EEM > is doing: just pass Ethernet packet around, encapsulated in USB. > > And quite a lot of ECM and RNDIS implementations are used that way > too ... not bridging to another network, although such cable modem > usage is very possible with both ECM and RNDIS. Just encapsulating > Ethernet using USB. (Instead of FireWire, carrier pigeon, etc.) > > A more technically accurate way to put this is that EEM, like the > CDC subset, doesn't invest in a complex control model which has, > in most contexts, proven to be needless and bug-prone overkill. > > > > CDC EEM is implemented as an alternative > > + * to those other protocols when that communication model is more appropriate > > */ > > > > #define DRIVER_DESC "Ethernet Gadget" > > > @@ -150,6 +156,10 @@ static inline bool has_rndis(void) > > #define RNDIS_VENDOR_NUM 0x0525 /* NetChip */ > > #define RNDIS_PRODUCT_NUM 0xa4a2 /* Ethernet/RNDIS Gadget */ > > > > +/* For EEM gadgets */ > > +#define EEM_VENDOR_NUM 0x0525 /* INVALID - NEEDS TO BE ALLOCATED */ > > +#define EEM_PRODUCT_NUM 0xa4a1 /* INVALID - NEEDS TO BE ALLOCATED */ > > Please fix this ASAP. You can use 0x0525/0xa4ab if you like. > (The 0xa4a1 code is claimed by the CDC ECM code...) Oops, I missed this. We have a reserved vendor id for Linux, do you want me to allocate you a product id out of our range? That would make the most sense, instead of using up a netchip id. thanks, greg k-h -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
