> From: Greg KH [mailto:gregkh@xxxxxxx] > 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". :) It is from the EEM specification, but I do believe there is some usefulness to thinking this way. > > 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.) I look at this a little differently. The intent of ECM was that it would be used by network interface devices that could be plugged in to USB (network cards, cable modems, etc.). Hence the extra control interface that makes it more complicated. However a lot of users really wanted a solution where USB just carried ethernet packets between two devices as if USB were the network. So they started using ECM or RNDIS for that purpose, and it's worked fine. However I believe EEM was designed to fill the role that CDC Subset has been filling in a standard way. That is, it was designed strictly for networking two devices over USB, and hence it sheds the complexity that ECM required. Appendixes C, F, and G of the EEM spec also highlight the conceptual differences between ECM and EEM. Because of the intent of "USB network between two devices" in EEM, it is possible to implement features such as having a single host network interface that is shared by multiple devices. Additionally the host driver could provide bridging between the devices. With the ECM model of one interface per device, this is not possible. > > 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. I have no problem removing this language. It was just helpful to me to think that way since that's the way the standards are written, so I thought it would be helpful to others as well. > > > 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. Is this a question for me or David? It doesn't make any difference to me. I don't know the process for this list. Do I need to submit these patches? -- 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
