Re: [PATCH 090/142] USB: gadget: Add EEM gadget driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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...)
--
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

[Index of Archives]     [Linux Media]     [Linux Input]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Old Linux USB Devel Archive]

  Powered by Linux