2005-09-01 00:54:20 +08:00
|
|
|
/*
|
|
|
|
* CDC Ethernet based networking peripherals
|
|
|
|
* Copyright (C) 2003-2005 by David Brownell
|
2006-12-15 08:01:28 +08:00
|
|
|
* Copyright (C) 2006 by Ole Andre Vadla Ravnas (ActiveSync)
|
2005-09-01 00:54:20 +08:00
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2 of the License, or
|
|
|
|
* (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
2013-12-06 22:28:46 +08:00
|
|
|
* along with this program; if not, see <http://www.gnu.org/licenses/>.
|
2005-09-01 00:54:20 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
// #define DEBUG // error path messages, extra info
|
|
|
|
// #define VERBOSE // more; success messages
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/netdevice.h>
|
|
|
|
#include <linux/etherdevice.h>
|
|
|
|
#include <linux/ethtool.h>
|
|
|
|
#include <linux/workqueue.h>
|
|
|
|
#include <linux/mii.h>
|
|
|
|
#include <linux/usb.h>
|
2006-06-14 00:57:47 +08:00
|
|
|
#include <linux/usb/cdc.h>
|
2008-01-26 06:51:45 +08:00
|
|
|
#include <linux/usb/usbnet.h>
|
2005-09-01 00:54:20 +08:00
|
|
|
|
|
|
|
|
2013-09-16 17:47:51 +08:00
|
|
|
#if IS_ENABLED(CONFIG_USB_NET_RNDIS_HOST)
|
2006-12-15 08:01:28 +08:00
|
|
|
|
|
|
|
static int is_rndis(struct usb_interface_descriptor *desc)
|
|
|
|
{
|
2009-12-03 15:58:21 +08:00
|
|
|
return (desc->bInterfaceClass == USB_CLASS_COMM &&
|
|
|
|
desc->bInterfaceSubClass == 2 &&
|
|
|
|
desc->bInterfaceProtocol == 0xff);
|
2006-12-15 08:01:28 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int is_activesync(struct usb_interface_descriptor *desc)
|
|
|
|
{
|
2009-12-03 15:58:21 +08:00
|
|
|
return (desc->bInterfaceClass == USB_CLASS_MISC &&
|
|
|
|
desc->bInterfaceSubClass == 1 &&
|
|
|
|
desc->bInterfaceProtocol == 1);
|
2006-12-15 08:01:28 +08:00
|
|
|
}
|
|
|
|
|
2008-07-23 04:55:58 +08:00
|
|
|
static int is_wireless_rndis(struct usb_interface_descriptor *desc)
|
|
|
|
{
|
2009-12-03 15:58:21 +08:00
|
|
|
return (desc->bInterfaceClass == USB_CLASS_WIRELESS_CONTROLLER &&
|
|
|
|
desc->bInterfaceSubClass == 1 &&
|
|
|
|
desc->bInterfaceProtocol == 3);
|
2008-07-23 04:55:58 +08:00
|
|
|
}
|
|
|
|
|
2006-12-15 08:01:28 +08:00
|
|
|
#else
|
|
|
|
|
|
|
|
#define is_rndis(desc) 0
|
|
|
|
#define is_activesync(desc) 0
|
2008-07-23 04:55:58 +08:00
|
|
|
#define is_wireless_rndis(desc) 0
|
2006-12-15 08:01:28 +08:00
|
|
|
|
|
|
|
#endif
|
|
|
|
|
2010-04-23 09:07:45 +08:00
|
|
|
static const u8 mbm_guid[16] = {
|
|
|
|
0xa3, 0x17, 0xa8, 0x8b, 0x04, 0x5e, 0x4f, 0x01,
|
|
|
|
0xa6, 0x07, 0xc0, 0xff, 0xcb, 0x7e, 0x39, 0x2a,
|
|
|
|
};
|
|
|
|
|
2014-10-25 01:43:01 +08:00
|
|
|
static void usbnet_cdc_update_filter(struct usbnet *dev)
|
|
|
|
{
|
|
|
|
struct cdc_state *info = (void *) &dev->data;
|
|
|
|
struct usb_interface *intf = info->control;
|
2014-11-06 22:19:14 +08:00
|
|
|
struct net_device *net = dev->net;
|
2014-10-25 01:43:01 +08:00
|
|
|
|
2014-11-06 22:19:14 +08:00
|
|
|
u16 cdc_filter = USB_CDC_PACKET_TYPE_DIRECTED
|
|
|
|
| USB_CDC_PACKET_TYPE_BROADCAST;
|
2014-10-25 01:43:01 +08:00
|
|
|
|
2014-11-06 22:19:14 +08:00
|
|
|
/* filtering on the device is an optional feature and not worth
|
|
|
|
* the hassle so we just roughly care about snooping and if any
|
|
|
|
* multicast is requested, we take every multicast
|
2014-10-25 01:43:01 +08:00
|
|
|
*/
|
2014-11-06 22:19:14 +08:00
|
|
|
if (net->flags & IFF_PROMISC)
|
|
|
|
cdc_filter |= USB_CDC_PACKET_TYPE_PROMISCUOUS;
|
|
|
|
if (!netdev_mc_empty(net) || (net->flags & IFF_ALLMULTI))
|
|
|
|
cdc_filter |= USB_CDC_PACKET_TYPE_ALL_MULTICAST;
|
2014-10-25 01:43:01 +08:00
|
|
|
|
|
|
|
usb_control_msg(dev->udev,
|
|
|
|
usb_sndctrlpipe(dev->udev, 0),
|
|
|
|
USB_CDC_SET_ETHERNET_PACKET_FILTER,
|
|
|
|
USB_TYPE_CLASS | USB_RECIP_INTERFACE,
|
|
|
|
cdc_filter,
|
|
|
|
intf->cur_altsetting->desc.bInterfaceNumber,
|
|
|
|
NULL,
|
|
|
|
0,
|
|
|
|
USB_CTRL_SET_TIMEOUT
|
|
|
|
);
|
|
|
|
}
|
|
|
|
|
2013-09-16 17:47:51 +08:00
|
|
|
/* probes control interface, claims data interface, collects the bulk
|
2005-09-01 00:54:20 +08:00
|
|
|
* endpoints, activates data interface (if needed), maybe sets MTU.
|
|
|
|
* all pure cdc, except for certain firmware workarounds, and knowing
|
|
|
|
* that rndis uses one different rule.
|
|
|
|
*/
|
|
|
|
int usbnet_generic_cdc_bind(struct usbnet *dev, struct usb_interface *intf)
|
|
|
|
{
|
|
|
|
u8 *buf = intf->cur_altsetting->extra;
|
|
|
|
int len = intf->cur_altsetting->extralen;
|
|
|
|
struct usb_interface_descriptor *d;
|
|
|
|
struct cdc_state *info = (void *) &dev->data;
|
|
|
|
int status;
|
|
|
|
int rndis;
|
2012-04-26 10:35:10 +08:00
|
|
|
bool android_rndis_quirk = false;
|
2005-09-01 00:54:20 +08:00
|
|
|
struct usb_driver *driver = driver_of(intf);
|
2015-09-07 22:05:40 +08:00
|
|
|
struct usb_cdc_parsed_header header;
|
2005-09-01 00:54:20 +08:00
|
|
|
|
2013-09-16 17:47:51 +08:00
|
|
|
if (sizeof(dev->data) < sizeof(*info))
|
2005-09-01 00:54:20 +08:00
|
|
|
return -EDOM;
|
|
|
|
|
|
|
|
/* expect strict spec conformance for the descriptors, but
|
|
|
|
* cope with firmware which stores them in the wrong place
|
|
|
|
*/
|
|
|
|
if (len == 0 && dev->udev->actconfig->extralen) {
|
|
|
|
/* Motorola SB4100 (and others: Brad Hards says it's
|
|
|
|
* from a Broadcom design) put CDC descriptors here
|
|
|
|
*/
|
|
|
|
buf = dev->udev->actconfig->extra;
|
|
|
|
len = dev->udev->actconfig->extralen;
|
2010-12-25 20:23:42 +08:00
|
|
|
dev_dbg(&intf->dev, "CDC descriptors on config\n");
|
2005-09-01 00:54:20 +08:00
|
|
|
}
|
|
|
|
|
2007-04-30 01:09:47 +08:00
|
|
|
/* Maybe CDC descriptors are after the endpoint? This bug has
|
|
|
|
* been seen on some 2Wire Inc RNDIS-ish products.
|
|
|
|
*/
|
|
|
|
if (len == 0) {
|
|
|
|
struct usb_host_endpoint *hep;
|
|
|
|
|
|
|
|
hep = intf->cur_altsetting->endpoint;
|
|
|
|
if (hep) {
|
|
|
|
buf = hep->extra;
|
|
|
|
len = hep->extralen;
|
|
|
|
}
|
|
|
|
if (len)
|
|
|
|
dev_dbg(&intf->dev,
|
|
|
|
"CDC descriptors on endpoint\n");
|
|
|
|
}
|
|
|
|
|
2005-09-01 00:54:20 +08:00
|
|
|
/* this assumes that if there's a non-RNDIS vendor variant
|
|
|
|
* of cdc-acm, it'll fail RNDIS requests cleanly.
|
|
|
|
*/
|
2009-12-03 15:58:21 +08:00
|
|
|
rndis = (is_rndis(&intf->cur_altsetting->desc) ||
|
|
|
|
is_activesync(&intf->cur_altsetting->desc) ||
|
|
|
|
is_wireless_rndis(&intf->cur_altsetting->desc));
|
2005-09-01 00:54:20 +08:00
|
|
|
|
2013-09-16 17:47:51 +08:00
|
|
|
memset(info, 0, sizeof(*info));
|
2005-09-01 00:54:20 +08:00
|
|
|
info->control = intf;
|
2015-09-07 22:05:40 +08:00
|
|
|
|
|
|
|
cdc_parse_cdc_header(&header, intf, buf, len);
|
|
|
|
|
|
|
|
info->u = header.usb_cdc_union_desc;
|
|
|
|
info->header = header.usb_cdc_header_desc;
|
|
|
|
info->ether = header.usb_cdc_ether_desc;
|
2016-01-07 18:01:00 +08:00
|
|
|
if (!info->u) {
|
|
|
|
if (rndis)
|
|
|
|
goto skip;
|
|
|
|
else /* in that case a quirk is mandatory */
|
|
|
|
goto bad_desc;
|
|
|
|
}
|
2015-09-07 22:05:40 +08:00
|
|
|
/* we need a master/control interface (what we're
|
|
|
|
* probed with) and a slave/data interface; union
|
|
|
|
* descriptors sort this all out.
|
|
|
|
*/
|
|
|
|
info->control = usb_ifnum_to_if(dev->udev,
|
|
|
|
info->u->bMasterInterface0);
|
|
|
|
info->data = usb_ifnum_to_if(dev->udev,
|
|
|
|
info->u->bSlaveInterface0);
|
|
|
|
if (!info->control || !info->data) {
|
|
|
|
dev_dbg(&intf->dev,
|
|
|
|
"master #%u/%p slave #%u/%p\n",
|
|
|
|
info->u->bMasterInterface0,
|
|
|
|
info->control,
|
|
|
|
info->u->bSlaveInterface0,
|
|
|
|
info->data);
|
|
|
|
/* fall back to hard-wiring for RNDIS */
|
|
|
|
if (rndis) {
|
|
|
|
android_rndis_quirk = true;
|
|
|
|
goto skip;
|
2005-09-01 00:54:20 +08:00
|
|
|
}
|
2015-09-07 22:05:40 +08:00
|
|
|
goto bad_desc;
|
|
|
|
}
|
|
|
|
if (info->control != intf) {
|
|
|
|
dev_dbg(&intf->dev, "bogus CDC Union\n");
|
|
|
|
/* Ambit USB Cable Modem (and maybe others)
|
|
|
|
* interchanges master and slave interface.
|
|
|
|
*/
|
|
|
|
if (info->data == intf) {
|
|
|
|
info->data = info->control;
|
|
|
|
info->control = intf;
|
|
|
|
} else
|
|
|
|
goto bad_desc;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* some devices merge these - skip class check */
|
|
|
|
if (info->control == info->data)
|
|
|
|
goto skip;
|
|
|
|
|
|
|
|
/* a data interface altsetting does the real i/o */
|
|
|
|
d = &info->data->cur_altsetting->desc;
|
|
|
|
if (d->bInterfaceClass != USB_CLASS_CDC_DATA) {
|
|
|
|
dev_dbg(&intf->dev, "slave class %u\n",
|
|
|
|
d->bInterfaceClass);
|
|
|
|
goto bad_desc;
|
|
|
|
}
|
|
|
|
skip:
|
|
|
|
if ( rndis &&
|
|
|
|
header.usb_cdc_acm_descriptor &&
|
|
|
|
header.usb_cdc_acm_descriptor->bmCapabilities) {
|
|
|
|
dev_dbg(&intf->dev,
|
|
|
|
"ACM capabilities %02x, not really RNDIS?\n",
|
|
|
|
header.usb_cdc_acm_descriptor->bmCapabilities);
|
|
|
|
goto bad_desc;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (header.usb_cdc_ether_desc) {
|
|
|
|
dev->hard_mtu = le16_to_cpu(info->ether->wMaxSegmentSize);
|
|
|
|
/* because of Zaurus, we may be ignoring the host
|
|
|
|
* side link address we were given.
|
|
|
|
*/
|
|
|
|
}
|
|
|
|
|
|
|
|
if (header.usb_cdc_mdlm_desc &&
|
|
|
|
memcmp(header.usb_cdc_mdlm_desc->bGUID, mbm_guid, 16)) {
|
|
|
|
dev_dbg(&intf->dev, "GUID doesn't match\n");
|
|
|
|
goto bad_desc;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (header.usb_cdc_mdlm_detail_desc &&
|
|
|
|
header.usb_cdc_mdlm_detail_desc->bLength <
|
|
|
|
(sizeof(struct usb_cdc_mdlm_detail_desc) + 1)) {
|
|
|
|
dev_dbg(&intf->dev, "Descriptor too short\n");
|
|
|
|
goto bad_desc;
|
2005-09-01 00:54:20 +08:00
|
|
|
}
|
|
|
|
|
2015-09-07 22:05:40 +08:00
|
|
|
|
|
|
|
|
2008-01-26 06:50:44 +08:00
|
|
|
/* Microsoft ActiveSync based and some regular RNDIS devices lack the
|
|
|
|
* CDC descriptors, so we'll hard-wire the interfaces and not check
|
|
|
|
* for descriptors.
|
2012-04-26 10:35:10 +08:00
|
|
|
*
|
|
|
|
* Some Android RNDIS devices have a CDC Union descriptor pointing
|
|
|
|
* to non-existing interfaces. Ignore that and attempt the same
|
|
|
|
* hard-wired 0 and 1 interfaces.
|
2006-12-15 08:01:28 +08:00
|
|
|
*/
|
2012-04-26 10:35:10 +08:00
|
|
|
if (rndis && (!info->u || android_rndis_quirk)) {
|
2006-12-15 08:01:28 +08:00
|
|
|
info->control = usb_ifnum_to_if(dev->udev, 0);
|
|
|
|
info->data = usb_ifnum_to_if(dev->udev, 1);
|
2012-04-26 10:35:10 +08:00
|
|
|
if (!info->control || !info->data || info->control != intf) {
|
2006-12-15 08:01:28 +08:00
|
|
|
dev_dbg(&intf->dev,
|
2008-01-26 06:50:44 +08:00
|
|
|
"rndis: master #0/%p slave #1/%p\n",
|
2006-12-15 08:01:28 +08:00
|
|
|
info->control,
|
|
|
|
info->data);
|
|
|
|
goto bad_desc;
|
|
|
|
}
|
|
|
|
|
2016-01-07 18:01:00 +08:00
|
|
|
} else if (!info->header || (!rndis && !info->ether)) {
|
2005-09-01 00:54:20 +08:00
|
|
|
dev_dbg(&intf->dev, "missing cdc %s%s%sdescriptor\n",
|
|
|
|
info->header ? "" : "header ",
|
|
|
|
info->u ? "" : "union ",
|
|
|
|
info->ether ? "" : "ether ");
|
|
|
|
goto bad_desc;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* claim data interface and set it up ... with side effects.
|
|
|
|
* network traffic can't flow until an altsetting is enabled.
|
|
|
|
*/
|
2013-06-29 18:03:06 +08:00
|
|
|
if (info->data != info->control) {
|
|
|
|
status = usb_driver_claim_interface(driver, info->data, dev);
|
|
|
|
if (status < 0)
|
|
|
|
return status;
|
|
|
|
}
|
2005-09-01 00:54:20 +08:00
|
|
|
status = usbnet_get_endpoints(dev, info->data);
|
|
|
|
if (status < 0) {
|
|
|
|
/* ensure immediate exit from usbnet_disconnect */
|
|
|
|
usb_set_intfdata(info->data, NULL);
|
2013-06-29 18:03:06 +08:00
|
|
|
if (info->data != info->control)
|
|
|
|
usb_driver_release_interface(driver, info->data);
|
2005-09-01 00:54:20 +08:00
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* status endpoint: optional for CDC Ethernet, not RNDIS (or ACM) */
|
2013-06-29 18:03:06 +08:00
|
|
|
if (info->data != info->control)
|
|
|
|
dev->status = NULL;
|
2005-09-01 00:54:20 +08:00
|
|
|
if (info->control->cur_altsetting->desc.bNumEndpoints == 1) {
|
|
|
|
struct usb_endpoint_descriptor *desc;
|
|
|
|
|
|
|
|
dev->status = &info->control->cur_altsetting->endpoint [0];
|
|
|
|
desc = &dev->status->desc;
|
2009-12-03 15:58:21 +08:00
|
|
|
if (!usb_endpoint_is_int_in(desc) ||
|
|
|
|
(le16_to_cpu(desc->wMaxPacketSize)
|
|
|
|
< sizeof(struct usb_cdc_notification)) ||
|
|
|
|
!desc->bInterval) {
|
2005-09-01 00:54:20 +08:00
|
|
|
dev_dbg(&intf->dev, "bad notification endpoint\n");
|
|
|
|
dev->status = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if (rndis && !dev->status) {
|
|
|
|
dev_dbg(&intf->dev, "missing RNDIS status endpoint\n");
|
|
|
|
usb_set_intfdata(info->data, NULL);
|
|
|
|
usb_driver_release_interface(driver, info->data);
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
2014-07-28 16:56:36 +08:00
|
|
|
|
|
|
|
/* Some devices don't initialise properly. In particular
|
|
|
|
* the packet filter is not reset. There are devices that
|
|
|
|
* don't do reset all the way. So the packet filter should
|
|
|
|
* be set to a sane initial value.
|
|
|
|
*/
|
2014-10-25 01:43:01 +08:00
|
|
|
usbnet_cdc_update_filter(dev);
|
|
|
|
|
2005-09-01 00:54:20 +08:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
bad_desc:
|
|
|
|
dev_info(&dev->udev->dev, "bad CDC descriptors\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usbnet_generic_cdc_bind);
|
|
|
|
|
|
|
|
void usbnet_cdc_unbind(struct usbnet *dev, struct usb_interface *intf)
|
|
|
|
{
|
|
|
|
struct cdc_state *info = (void *) &dev->data;
|
|
|
|
struct usb_driver *driver = driver_of(intf);
|
|
|
|
|
2013-06-29 18:03:06 +08:00
|
|
|
/* combined interface - nothing to do */
|
|
|
|
if (info->data == info->control)
|
|
|
|
return;
|
|
|
|
|
2005-09-01 00:54:20 +08:00
|
|
|
/* disconnect master --> disconnect slave */
|
|
|
|
if (intf == info->control && info->data) {
|
|
|
|
/* ensure immediate exit from usbnet_disconnect */
|
|
|
|
usb_set_intfdata(info->data, NULL);
|
|
|
|
usb_driver_release_interface(driver, info->data);
|
|
|
|
info->data = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* and vice versa (just in case) */
|
|
|
|
else if (intf == info->data && info->control) {
|
|
|
|
/* ensure immediate exit from usbnet_disconnect */
|
|
|
|
usb_set_intfdata(info->control, NULL);
|
|
|
|
usb_driver_release_interface(driver, info->control);
|
|
|
|
info->control = NULL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(usbnet_cdc_unbind);
|
|
|
|
|
2013-09-16 17:47:51 +08:00
|
|
|
/* Communications Device Class, Ethernet Control model
|
2005-09-01 00:54:20 +08:00
|
|
|
*
|
|
|
|
* Takes two interfaces. The DATA interface is inactive till an altsetting
|
|
|
|
* is selected. Configuration data includes class descriptors. There's
|
|
|
|
* an optional status endpoint on the control interface.
|
|
|
|
*
|
|
|
|
* This should interop with whatever the 2.4 "CDCEther.c" driver
|
|
|
|
* (by Brad Hards) talked with, with more functionality.
|
2013-09-16 17:47:51 +08:00
|
|
|
*/
|
2005-09-01 00:54:20 +08:00
|
|
|
|
|
|
|
static void dumpspeed(struct usbnet *dev, __le32 *speeds)
|
|
|
|
{
|
2010-02-17 18:30:24 +08:00
|
|
|
netif_info(dev, timer, dev->net,
|
|
|
|
"link speeds: %u kbps up, %u kbps down\n",
|
|
|
|
__le32_to_cpu(speeds[0]) / 1000,
|
|
|
|
__le32_to_cpu(speeds[1]) / 1000);
|
2005-09-01 00:54:20 +08:00
|
|
|
}
|
|
|
|
|
2011-03-28 20:56:33 +08:00
|
|
|
void usbnet_cdc_status(struct usbnet *dev, struct urb *urb)
|
2005-09-01 00:54:20 +08:00
|
|
|
{
|
|
|
|
struct usb_cdc_notification *event;
|
|
|
|
|
2013-09-16 17:47:51 +08:00
|
|
|
if (urb->actual_length < sizeof(*event))
|
2005-09-01 00:54:20 +08:00
|
|
|
return;
|
|
|
|
|
|
|
|
/* SPEED_CHANGE can get split into two 8-byte packets */
|
|
|
|
if (test_and_clear_bit(EVENT_STS_SPLIT, &dev->flags)) {
|
|
|
|
dumpspeed(dev, (__le32 *) urb->transfer_buffer);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
event = urb->transfer_buffer;
|
|
|
|
switch (event->bNotificationType) {
|
|
|
|
case USB_CDC_NOTIFY_NETWORK_CONNECTION:
|
2010-02-17 18:30:24 +08:00
|
|
|
netif_dbg(dev, timer, dev->net, "CDC: carrier %s\n",
|
|
|
|
event->wValue ? "on" : "off");
|
2013-04-17 06:12:13 +08:00
|
|
|
usbnet_link_change(dev, !!event->wValue, 0);
|
2005-09-01 00:54:20 +08:00
|
|
|
break;
|
|
|
|
case USB_CDC_NOTIFY_SPEED_CHANGE: /* tx/rx rates */
|
2010-02-17 18:30:24 +08:00
|
|
|
netif_dbg(dev, timer, dev->net, "CDC: speed change (len %d)\n",
|
|
|
|
urb->actual_length);
|
2013-09-16 17:47:51 +08:00
|
|
|
if (urb->actual_length != (sizeof(*event) + 8))
|
2005-09-01 00:54:20 +08:00
|
|
|
set_bit(EVENT_STS_SPLIT, &dev->flags);
|
|
|
|
else
|
|
|
|
dumpspeed(dev, (__le32 *) &event[1]);
|
|
|
|
break;
|
|
|
|
/* USB_CDC_NOTIFY_RESPONSE_AVAILABLE can happen too (e.g. RNDIS),
|
|
|
|
* but there are no standard formats for the response data.
|
|
|
|
*/
|
|
|
|
default:
|
2010-02-17 18:30:23 +08:00
|
|
|
netdev_err(dev->net, "CDC: unexpected notification %02x!\n",
|
|
|
|
event->bNotificationType);
|
2005-09-01 00:54:20 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
2011-03-28 20:56:33 +08:00
|
|
|
EXPORT_SYMBOL_GPL(usbnet_cdc_status);
|
2005-09-01 00:54:20 +08:00
|
|
|
|
2011-03-28 20:56:33 +08:00
|
|
|
int usbnet_cdc_bind(struct usbnet *dev, struct usb_interface *intf)
|
2005-09-01 00:54:20 +08:00
|
|
|
{
|
|
|
|
int status;
|
|
|
|
struct cdc_state *info = (void *) &dev->data;
|
|
|
|
|
2011-11-19 01:44:20 +08:00
|
|
|
BUILD_BUG_ON((sizeof(((struct usbnet *)0)->data)
|
|
|
|
< sizeof(struct cdc_state)));
|
|
|
|
|
2005-09-01 00:54:20 +08:00
|
|
|
status = usbnet_generic_cdc_bind(dev, intf);
|
|
|
|
if (status < 0)
|
|
|
|
return status;
|
|
|
|
|
2009-04-18 15:24:17 +08:00
|
|
|
status = usbnet_get_ethernet_addr(dev, info->ether->iMACAddress);
|
2005-09-01 00:54:20 +08:00
|
|
|
if (status < 0) {
|
|
|
|
usb_set_intfdata(info->data, NULL);
|
|
|
|
usb_driver_release_interface(driver_of(intf), info->data);
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2011-03-28 20:56:33 +08:00
|
|
|
EXPORT_SYMBOL_GPL(usbnet_cdc_bind);
|
2005-09-01 00:54:20 +08:00
|
|
|
|
cdc_ether: Improve ZTE MF823/831/910 handling
The firmware in several ZTE devices (at least the MF823/831/910
modems/mifis) use OS fingerprinting to determine which type of device to
export. In addition, these devices export a REST API which can be used to
control the type of device. So far, on Linux, the devices have been seen as
RNDIS or CDC Ether.
When CDC Ether is used, devices of the same type are, as with RNDIS,
exported with the same, bogus random MAC address. In addition, the devices
(at least on all firmware revisions I have found) use the bogus MAC when
sending traffic routed from external networks. And as a final feature, the
devices sometimes export the link state incorrectly. There are also
references online to several other ZTE devices displaying this behavior,
with several different PIDs and MAC addresses.
This patch tries to improve the handling of ZTE devices by doing the
following:
* Create a new driver_info-struct that is used by ZTE devices that do not
have an explicit entry in the product table. This struct is the same as the
default cdc_ether driver info, but a new bind- and an rx_fixup-function
have been added.
* In the new bind function, we check if we have read a random MAC from the
device. If we have, then we generate a new random MAC address. This will
ensure that all devices get a unique MAC.
* The rx_fixup-function replaces the destination MAC address in the skb
with that of the device. I have not seen a revision of these devices that
behaves correctly (i.e., sets the right destination MAC), so I chose not to
do any comparison with for example the known, bogus addresses.
* The MF823/MF832/MF910 sometimes export cdc carrier on twice on connect
(the correct behavior is off then on). Work around this by manually setting
carrier to off if an on-notification is received and the NOCARRIER-bit is
not set.
This change will affect all devices, but it should take care of similar
mistakes made by other manufacturers. I tried to think of/look/test for
problems/regressions that could be introduced by this behavior, but could
not find any. However, my familiarity with this code path is not that
great, so there could be something I have overlooked.
I have tested this patch with multiple revisions of all three devices, and
they behave as expected. In other words, they all got a valid, random MAC,
the correct operational state and I can receive/sent traffic without
problems. I also tested with some other cdc_ether devices I have and did
not find any problems/regressions caused by the two general changes.
v3->v4:
* Forgot to remove unused variables, sorry about that (thanks David
Miller).
v2->v3:
* I had forgot to remove the random MAC generation from usbnet_cdc_bind()
(thanks Oliver).
* Rework logic in the ZTE bind-function a bit.
v1->v2:
* Only generate random MAC for ZTE devices (thanks Oliver Neukum).
* Set random MAC and do RX fixup for all ZTE devices that do not have a
product-entry, as the bogus MAC have been seen on devices with several
different PIDs/MAC addresses. In other words, it seems to be the default
behavior of ZTE CDC Ether devices (thanks Lars Melin).
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
Acked-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-07-21 17:10:06 +08:00
|
|
|
static int usbnet_cdc_zte_bind(struct usbnet *dev, struct usb_interface *intf)
|
|
|
|
{
|
|
|
|
int status = usbnet_cdc_bind(dev, intf);
|
|
|
|
|
|
|
|
if (!status && (dev->net->dev_addr[0] & 0x02))
|
|
|
|
eth_hw_addr_random(dev->net);
|
|
|
|
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Make sure packets have correct destination MAC address
|
|
|
|
*
|
|
|
|
* A firmware bug observed on some devices (ZTE MF823/831/910) is that the
|
|
|
|
* device sends packets with a static, bogus, random MAC address (event if
|
|
|
|
* device MAC address has been updated). Always set MAC address to that of the
|
|
|
|
* device.
|
|
|
|
*/
|
|
|
|
static int usbnet_cdc_zte_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
|
|
|
|
{
|
|
|
|
if (skb->len < ETH_HLEN || !(skb->data[0] & 0x02))
|
|
|
|
return 1;
|
|
|
|
|
|
|
|
skb_reset_mac_header(skb);
|
|
|
|
ether_addr_copy(eth_hdr(skb)->h_dest, dev->net->dev_addr);
|
|
|
|
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2016-12-01 21:23:17 +08:00
|
|
|
/* Ensure correct link state
|
|
|
|
*
|
|
|
|
* Some devices (ZTE MF823/831/910) export two carrier on notifications when
|
|
|
|
* connected. This causes the link state to be incorrect. Work around this by
|
|
|
|
* always setting the state to off, then on.
|
|
|
|
*/
|
2017-01-12 21:43:47 +08:00
|
|
|
static void usbnet_cdc_zte_status(struct usbnet *dev, struct urb *urb)
|
2016-12-01 21:23:17 +08:00
|
|
|
{
|
|
|
|
struct usb_cdc_notification *event;
|
|
|
|
|
|
|
|
if (urb->actual_length < sizeof(*event))
|
|
|
|
return;
|
|
|
|
|
|
|
|
event = urb->transfer_buffer;
|
|
|
|
|
|
|
|
if (event->bNotificationType != USB_CDC_NOTIFY_NETWORK_CONNECTION) {
|
|
|
|
usbnet_cdc_status(dev, urb);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
netif_dbg(dev, timer, dev->net, "CDC: carrier %s\n",
|
|
|
|
event->wValue ? "on" : "off");
|
|
|
|
|
|
|
|
if (event->wValue &&
|
|
|
|
netif_carrier_ok(dev->net))
|
|
|
|
netif_carrier_off(dev->net);
|
|
|
|
|
|
|
|
usbnet_link_change(dev, !!event->wValue, 0);
|
|
|
|
}
|
|
|
|
|
2005-09-01 00:54:20 +08:00
|
|
|
static const struct driver_info cdc_info = {
|
|
|
|
.description = "CDC Ethernet Device",
|
usbnet: use eth%d name for known ethernet devices
The documentation for the USB ethernet devices suggests that
only some devices are supposed to use usb0 as the network interface
name instead of eth0. The logic used there, and documented in
Kconfig for CDC is that eth0 will be used when the mac address
is a globally assigned one, but usb0 is used for the locally
managed range that is typically used on point-to-point links.
Unfortunately, this has caused a lot of pain on the smsc95xx
device that is used on the popular pandaboard without an
EEPROM to store the MAC address, which causes the driver to
call random_ether_address().
Obviously, there should be a proper MAC addressed assigned to
the device, and discussions are ongoing about how to solve
this, but this patch at least makes sure that the default
interface naming gets a little saner and matches what the
user can expect based on the documentation, including for
new devices.
The approach taken here is to flag whether a device might be a
point-to-point link with the new FLAG_POINTTOPOINT setting in
the usbnet driver_info. A driver can set both FLAG_POINTTOPOINT
and FLAG_ETHER if it is not sure (e.g. cdc_ether), or just one
of the two. The usbnet framework only looks at the MAC address
for device naming if both flags are set, otherwise it trusts the
flag.
Signed-off-by: Arnd Bergmann <arnd.bergmann@linaro.org>
Tested-by: Andy Green <andy.green@linaro.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2011-04-02 11:12:02 +08:00
|
|
|
.flags = FLAG_ETHER | FLAG_POINTTOPOINT,
|
2011-03-28 20:56:33 +08:00
|
|
|
.bind = usbnet_cdc_bind,
|
2005-09-01 00:54:20 +08:00
|
|
|
.unbind = usbnet_cdc_unbind,
|
2011-03-28 20:56:33 +08:00
|
|
|
.status = usbnet_cdc_status,
|
2014-10-25 01:43:02 +08:00
|
|
|
.set_rx_mode = usbnet_cdc_update_filter,
|
2012-12-18 12:46:12 +08:00
|
|
|
.manage_power = usbnet_manage_power,
|
2005-09-01 00:54:20 +08:00
|
|
|
};
|
|
|
|
|
cdc_ether: Improve ZTE MF823/831/910 handling
The firmware in several ZTE devices (at least the MF823/831/910
modems/mifis) use OS fingerprinting to determine which type of device to
export. In addition, these devices export a REST API which can be used to
control the type of device. So far, on Linux, the devices have been seen as
RNDIS or CDC Ether.
When CDC Ether is used, devices of the same type are, as with RNDIS,
exported with the same, bogus random MAC address. In addition, the devices
(at least on all firmware revisions I have found) use the bogus MAC when
sending traffic routed from external networks. And as a final feature, the
devices sometimes export the link state incorrectly. There are also
references online to several other ZTE devices displaying this behavior,
with several different PIDs and MAC addresses.
This patch tries to improve the handling of ZTE devices by doing the
following:
* Create a new driver_info-struct that is used by ZTE devices that do not
have an explicit entry in the product table. This struct is the same as the
default cdc_ether driver info, but a new bind- and an rx_fixup-function
have been added.
* In the new bind function, we check if we have read a random MAC from the
device. If we have, then we generate a new random MAC address. This will
ensure that all devices get a unique MAC.
* The rx_fixup-function replaces the destination MAC address in the skb
with that of the device. I have not seen a revision of these devices that
behaves correctly (i.e., sets the right destination MAC), so I chose not to
do any comparison with for example the known, bogus addresses.
* The MF823/MF832/MF910 sometimes export cdc carrier on twice on connect
(the correct behavior is off then on). Work around this by manually setting
carrier to off if an on-notification is received and the NOCARRIER-bit is
not set.
This change will affect all devices, but it should take care of similar
mistakes made by other manufacturers. I tried to think of/look/test for
problems/regressions that could be introduced by this behavior, but could
not find any. However, my familiarity with this code path is not that
great, so there could be something I have overlooked.
I have tested this patch with multiple revisions of all three devices, and
they behave as expected. In other words, they all got a valid, random MAC,
the correct operational state and I can receive/sent traffic without
problems. I also tested with some other cdc_ether devices I have and did
not find any problems/regressions caused by the two general changes.
v3->v4:
* Forgot to remove unused variables, sorry about that (thanks David
Miller).
v2->v3:
* I had forgot to remove the random MAC generation from usbnet_cdc_bind()
(thanks Oliver).
* Rework logic in the ZTE bind-function a bit.
v1->v2:
* Only generate random MAC for ZTE devices (thanks Oliver Neukum).
* Set random MAC and do RX fixup for all ZTE devices that do not have a
product-entry, as the bogus MAC have been seen on devices with several
different PIDs/MAC addresses. In other words, it seems to be the default
behavior of ZTE CDC Ether devices (thanks Lars Melin).
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
Acked-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-07-21 17:10:06 +08:00
|
|
|
static const struct driver_info zte_cdc_info = {
|
|
|
|
.description = "ZTE CDC Ethernet Device",
|
|
|
|
.flags = FLAG_ETHER | FLAG_POINTTOPOINT,
|
|
|
|
.bind = usbnet_cdc_zte_bind,
|
|
|
|
.unbind = usbnet_cdc_unbind,
|
2016-12-01 21:23:17 +08:00
|
|
|
.status = usbnet_cdc_zte_status,
|
cdc_ether: Improve ZTE MF823/831/910 handling
The firmware in several ZTE devices (at least the MF823/831/910
modems/mifis) use OS fingerprinting to determine which type of device to
export. In addition, these devices export a REST API which can be used to
control the type of device. So far, on Linux, the devices have been seen as
RNDIS or CDC Ether.
When CDC Ether is used, devices of the same type are, as with RNDIS,
exported with the same, bogus random MAC address. In addition, the devices
(at least on all firmware revisions I have found) use the bogus MAC when
sending traffic routed from external networks. And as a final feature, the
devices sometimes export the link state incorrectly. There are also
references online to several other ZTE devices displaying this behavior,
with several different PIDs and MAC addresses.
This patch tries to improve the handling of ZTE devices by doing the
following:
* Create a new driver_info-struct that is used by ZTE devices that do not
have an explicit entry in the product table. This struct is the same as the
default cdc_ether driver info, but a new bind- and an rx_fixup-function
have been added.
* In the new bind function, we check if we have read a random MAC from the
device. If we have, then we generate a new random MAC address. This will
ensure that all devices get a unique MAC.
* The rx_fixup-function replaces the destination MAC address in the skb
with that of the device. I have not seen a revision of these devices that
behaves correctly (i.e., sets the right destination MAC), so I chose not to
do any comparison with for example the known, bogus addresses.
* The MF823/MF832/MF910 sometimes export cdc carrier on twice on connect
(the correct behavior is off then on). Work around this by manually setting
carrier to off if an on-notification is received and the NOCARRIER-bit is
not set.
This change will affect all devices, but it should take care of similar
mistakes made by other manufacturers. I tried to think of/look/test for
problems/regressions that could be introduced by this behavior, but could
not find any. However, my familiarity with this code path is not that
great, so there could be something I have overlooked.
I have tested this patch with multiple revisions of all three devices, and
they behave as expected. In other words, they all got a valid, random MAC,
the correct operational state and I can receive/sent traffic without
problems. I also tested with some other cdc_ether devices I have and did
not find any problems/regressions caused by the two general changes.
v3->v4:
* Forgot to remove unused variables, sorry about that (thanks David
Miller).
v2->v3:
* I had forgot to remove the random MAC generation from usbnet_cdc_bind()
(thanks Oliver).
* Rework logic in the ZTE bind-function a bit.
v1->v2:
* Only generate random MAC for ZTE devices (thanks Oliver Neukum).
* Set random MAC and do RX fixup for all ZTE devices that do not have a
product-entry, as the bogus MAC have been seen on devices with several
different PIDs/MAC addresses. In other words, it seems to be the default
behavior of ZTE CDC Ether devices (thanks Lars Melin).
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
Acked-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-07-21 17:10:06 +08:00
|
|
|
.set_rx_mode = usbnet_cdc_update_filter,
|
|
|
|
.manage_power = usbnet_manage_power,
|
|
|
|
.rx_fixup = usbnet_cdc_zte_rx_fixup,
|
|
|
|
};
|
|
|
|
|
2011-04-27 17:54:28 +08:00
|
|
|
static const struct driver_info wwan_info = {
|
2009-10-02 13:15:25 +08:00
|
|
|
.description = "Mobile Broadband Network Device",
|
|
|
|
.flags = FLAG_WWAN,
|
2011-03-28 20:56:33 +08:00
|
|
|
.bind = usbnet_cdc_bind,
|
2009-10-02 13:15:25 +08:00
|
|
|
.unbind = usbnet_cdc_unbind,
|
2011-03-28 20:56:33 +08:00
|
|
|
.status = usbnet_cdc_status,
|
2014-10-25 01:43:02 +08:00
|
|
|
.set_rx_mode = usbnet_cdc_update_filter,
|
2012-12-18 12:46:12 +08:00
|
|
|
.manage_power = usbnet_manage_power,
|
2009-10-02 13:15:25 +08:00
|
|
|
};
|
|
|
|
|
2005-09-01 00:54:20 +08:00
|
|
|
/*-------------------------------------------------------------------------*/
|
|
|
|
|
2011-04-27 17:54:28 +08:00
|
|
|
#define HUAWEI_VENDOR_ID 0x12D1
|
2012-05-07 12:24:51 +08:00
|
|
|
#define NOVATEL_VENDOR_ID 0x1410
|
2012-05-19 11:56:07 +08:00
|
|
|
#define ZTE_VENDOR_ID 0x19D2
|
2012-12-17 16:17:41 +08:00
|
|
|
#define DELL_VENDOR_ID 0x413C
|
2013-05-03 00:01:25 +08:00
|
|
|
#define REALTEK_VENDOR_ID 0x0bda
|
2014-01-02 11:25:10 +08:00
|
|
|
#define SAMSUNG_VENDOR_ID 0x04e8
|
2015-03-31 20:10:07 +08:00
|
|
|
#define LENOVO_VENDOR_ID 0x17ef
|
2015-07-08 04:54:12 +08:00
|
|
|
#define NVIDIA_VENDOR_ID 0x0955
|
2017-01-24 17:45:38 +08:00
|
|
|
#define HP_VENDOR_ID 0x03f0
|
2017-03-28 13:56:51 +08:00
|
|
|
#define MICROSOFT_VENDOR_ID 0x045e
|
2005-09-01 00:54:20 +08:00
|
|
|
|
2013-09-16 17:47:51 +08:00
|
|
|
static const struct usb_device_id products[] = {
|
|
|
|
/* BLACKLIST !!
|
2005-09-01 00:54:20 +08:00
|
|
|
*
|
|
|
|
* First blacklist any products that are egregiously nonconformant
|
|
|
|
* with the CDC Ethernet specs. Minor braindamage we cope with; when
|
|
|
|
* they're not even trying, needing a separate driver is only the first
|
|
|
|
* of the differences to show up.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#define ZAURUS_MASTER_INTERFACE \
|
|
|
|
.bInterfaceClass = USB_CLASS_COMM, \
|
|
|
|
.bInterfaceSubClass = USB_CDC_SUBCLASS_ETHERNET, \
|
|
|
|
.bInterfaceProtocol = USB_CDC_PROTO_NONE
|
|
|
|
|
|
|
|
/* SA-1100 based Sharp Zaurus ("collie"), or compatible;
|
|
|
|
* wire-incompatible with true CDC Ethernet implementations.
|
|
|
|
* (And, it seems, needlessly so...)
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
|
|
|
|
| USB_DEVICE_ID_MATCH_DEVICE,
|
|
|
|
.idVendor = 0x04DD,
|
|
|
|
.idProduct = 0x8004,
|
|
|
|
ZAURUS_MASTER_INTERFACE,
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
|
|
|
/* PXA-25x based Sharp Zaurii. Note that it seems some of these
|
|
|
|
* (later models especially) may have shipped only with firmware
|
|
|
|
* advertising false "CDC MDLM" compatibility ... but we're not
|
|
|
|
* clear which models did that, so for now let's assume the worst.
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
|
|
|
|
| USB_DEVICE_ID_MATCH_DEVICE,
|
|
|
|
.idVendor = 0x04DD,
|
|
|
|
.idProduct = 0x8005, /* A-300 */
|
|
|
|
ZAURUS_MASTER_INTERFACE,
|
|
|
|
.driver_info = 0,
|
|
|
|
}, {
|
|
|
|
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
|
|
|
|
| USB_DEVICE_ID_MATCH_DEVICE,
|
|
|
|
.idVendor = 0x04DD,
|
|
|
|
.idProduct = 0x8006, /* B-500/SL-5600 */
|
|
|
|
ZAURUS_MASTER_INTERFACE,
|
|
|
|
.driver_info = 0,
|
|
|
|
}, {
|
|
|
|
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
|
2013-09-16 17:47:51 +08:00
|
|
|
| USB_DEVICE_ID_MATCH_DEVICE,
|
2005-09-01 00:54:20 +08:00
|
|
|
.idVendor = 0x04DD,
|
|
|
|
.idProduct = 0x8007, /* C-700 */
|
|
|
|
ZAURUS_MASTER_INTERFACE,
|
|
|
|
.driver_info = 0,
|
|
|
|
}, {
|
|
|
|
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
|
|
|
|
| USB_DEVICE_ID_MATCH_DEVICE,
|
|
|
|
.idVendor = 0x04DD,
|
|
|
|
.idProduct = 0x9031, /* C-750 C-760 */
|
|
|
|
ZAURUS_MASTER_INTERFACE,
|
|
|
|
.driver_info = 0,
|
|
|
|
}, {
|
|
|
|
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
|
|
|
|
| USB_DEVICE_ID_MATCH_DEVICE,
|
|
|
|
.idVendor = 0x04DD,
|
|
|
|
.idProduct = 0x9032, /* SL-6000 */
|
|
|
|
ZAURUS_MASTER_INTERFACE,
|
|
|
|
.driver_info = 0,
|
|
|
|
}, {
|
|
|
|
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
|
|
|
|
| USB_DEVICE_ID_MATCH_DEVICE,
|
|
|
|
.idVendor = 0x04DD,
|
|
|
|
/* reported with some C860 units */
|
|
|
|
.idProduct = 0x9050, /* C-860 */
|
|
|
|
ZAURUS_MASTER_INTERFACE,
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
2006-05-31 11:49:29 +08:00
|
|
|
/* Olympus has some models with a Zaurus-compatible option.
|
|
|
|
* R-1000 uses a FreeScale i.MXL cpu (ARMv4T)
|
|
|
|
*/
|
|
|
|
{
|
|
|
|
.match_flags = USB_DEVICE_ID_MATCH_INT_INFO
|
|
|
|
| USB_DEVICE_ID_MATCH_DEVICE,
|
|
|
|
.idVendor = 0x07B4,
|
|
|
|
.idProduct = 0x0F02, /* R-1000 */
|
|
|
|
ZAURUS_MASTER_INTERFACE,
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
2011-03-28 20:56:33 +08:00
|
|
|
/* LG Electronics VL600 wants additional headers on every frame */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(0x1004, 0x61aa, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
2011-11-09 19:48:10 +08:00
|
|
|
.driver_info = 0,
|
2011-03-28 20:56:33 +08:00
|
|
|
},
|
|
|
|
|
2012-02-21 21:06:00 +08:00
|
|
|
/* Logitech Harmony 900 - uses the pseudo-MDLM (BLAN) driver */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(0x046d, 0xc11f, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
2012-10-24 20:10:34 +08:00
|
|
|
/* Novatel USB551L and MC551 - handled by qmi_wwan */
|
|
|
|
{
|
2012-12-17 16:19:46 +08:00
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(NOVATEL_VENDOR_ID, 0xB001, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
2012-10-24 20:10:34 +08:00
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
|
|
|
/* Novatel E362 - handled by qmi_wwan */
|
|
|
|
{
|
2012-12-17 16:19:46 +08:00
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(NOVATEL_VENDOR_ID, 0x9010, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
2012-10-24 20:10:34 +08:00
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
2012-12-17 16:17:41 +08:00
|
|
|
/* Dell Wireless 5800 (Novatel E362) - handled by qmi_wwan */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 0x8195, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
|
|
|
/* Dell Wireless 5800 (Novatel E362) - handled by qmi_wwan */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 0x8196, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
2013-05-06 19:17:37 +08:00
|
|
|
/* Dell Wireless 5804 (Novatel E371) - handled by qmi_wwan */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 0x819b, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
2014-03-28 19:07:18 +08:00
|
|
|
/* Novatel Expedite E371 - handled by qmi_wwan */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(NOVATEL_VENDOR_ID, 0x9011, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
2017-01-24 17:45:38 +08:00
|
|
|
/* HP lt2523 (Novatel E371) - handled by qmi_wwan */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(HP_VENDOR_ID, 0x421d, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
2013-02-19 01:25:09 +08:00
|
|
|
/* AnyDATA ADU960S - handled by qmi_wwan */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(0x16d5, 0x650a, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
qmi_wwan/cdc_ether: let qmi_wwan handle the Huawei E1820
Another QMI speaking Qualcomm based device, which should be
driven by qmi_wwan, while cdc_ether should ignore it.
Like on other Huawei devices, the wwan function can appear
either as a single vendor specific interface or as a CDC ECM
class function using separate control and data interfaces.
The ECM control interface protocol is 0xff, likely in an
attempt to indicate that vendor specific management is
required.
In addition to the near standard CDC class, Huawei also add
vendor specific AT management commands to their firmwares.
This is probably an attempt to support non-Windows systems
using standard class drivers. Unfortunately, this part of
the firmware is often buggy. Linux is much better off using
whatever native vendor specific management protocol the
device offers, and Windows uses, whenever possible. This
means QMI in the case of Qualcomm based devices.
The E1820 has been verified to work fine with QMI.
Matching on interface number is necessary to distiguish the
wwan function from serial functions in the single interface
mode, as both function types will have class/subclass/function
set to ff/ff/ff.
The control interface number does not change in CDC ECM mode,
so the interface number matching rule is sufficient to handle
both modes. The cdc_ether blacklist entry is only relevant in
CDC ECM mode, but using a similar interface number based rule
helps document this as a transfer from one driver to another.
Other Huawei 02/06/ff devices are left with the cdc_ether driver
because we do not know whether they are based on Qualcomm chips.
The Huawei specific AT command management is known to be somewhat
hardware independent, and their usage of these class codes may
also be independent of the modem hardware.
Reported-by: Graham Inggs <graham.inggs@uct.ac.za>
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-06 18:57:02 +08:00
|
|
|
/* Huawei E1820 - handled by qmi_wwan */
|
|
|
|
{
|
|
|
|
USB_DEVICE_INTERFACE_NUMBER(HUAWEI_VENDOR_ID, 0x14ac, 1),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
2013-05-03 00:01:25 +08:00
|
|
|
/* Realtek RTL8152 Based USB 2.0 Ethernet Adapters */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(REALTEK_VENDOR_ID, 0x8152, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
2013-07-08 10:41:21 +08:00
|
|
|
|
|
|
|
/* Realtek RTL8153 Based USB 3.0 Ethernet Adapters */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(REALTEK_VENDOR_ID, 0x8153, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
2013-05-03 00:01:25 +08:00
|
|
|
|
2014-03-04 20:47:48 +08:00
|
|
|
/* Samsung USB Ethernet Adapters */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(SAMSUNG_VENDOR_ID, 0xa101, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
2016-10-18 11:41:48 +08:00
|
|
|
/* ThinkPad USB-C Dock (based on Realtek RTL8153) */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(LENOVO_VENDOR_ID, 0x3062, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
|
|
|
/* ThinkPad Thunderbolt 3 Dock (based on Realtek RTL8153) */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(LENOVO_VENDOR_ID, 0x3069, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
2015-03-31 20:10:07 +08:00
|
|
|
/* Lenovo Thinkpad USB 3.0 Ethernet Adapters (based on Realtek RTL8153) */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(LENOVO_VENDOR_ID, 0x7205, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
2016-10-18 11:41:48 +08:00
|
|
|
/* Lenovo USB C to Ethernet Adapter (based on Realtek RTL8153) */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(LENOVO_VENDOR_ID, 0x720c, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
|
|
|
/* Lenovo USB-C Travel Hub (based on Realtek RTL8153) */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(LENOVO_VENDOR_ID, 0x7214, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
2015-07-08 04:54:12 +08:00
|
|
|
/* NVIDIA Tegra USB 3.0 Ethernet Adapters (based on Realtek RTL8153) */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(NVIDIA_VENDOR_ID, 0x09ff, USB_CLASS_COMM,
|
2017-03-28 13:56:51 +08:00
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
|
|
|
/* Microsoft Surface 2 dock (based on Realtek RTL8152) */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(MICROSOFT_VENDOR_ID, 0x07ab, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
|
|
|
/* Microsoft Surface 3 dock (based on Realtek RTL8153) */
|
|
|
|
{
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(MICROSOFT_VENDOR_ID, 0x07c6, USB_CLASS_COMM,
|
2015-07-08 04:54:12 +08:00
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = 0,
|
|
|
|
},
|
|
|
|
|
2013-09-16 17:47:51 +08:00
|
|
|
/* WHITELIST!!!
|
2005-09-01 00:54:20 +08:00
|
|
|
*
|
|
|
|
* CDC Ether uses two interfaces, not necessarily consecutive.
|
|
|
|
* We match the main interface, ignoring the optional device
|
|
|
|
* class so we could handle devices that aren't exclusively
|
|
|
|
* CDC ether.
|
|
|
|
*
|
|
|
|
* NOTE: this match must come AFTER entries blacklisting devices
|
|
|
|
* because of bugs/quirks in a given product (like Zaurus, above).
|
|
|
|
*/
|
|
|
|
{
|
2012-05-19 11:56:07 +08:00
|
|
|
/* ZTE (Vodafone) K3805-Z */
|
2013-09-16 17:47:52 +08:00
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1003, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET,
|
|
|
|
USB_CDC_PROTO_NONE),
|
2012-05-19 11:56:07 +08:00
|
|
|
.driver_info = (unsigned long)&wwan_info,
|
|
|
|
}, {
|
|
|
|
/* ZTE (Vodafone) K3806-Z */
|
2013-09-16 17:47:52 +08:00
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1015, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET,
|
|
|
|
USB_CDC_PROTO_NONE),
|
2012-05-19 11:56:07 +08:00
|
|
|
.driver_info = (unsigned long)&wwan_info,
|
|
|
|
}, {
|
|
|
|
/* ZTE (Vodafone) K4510-Z */
|
2013-09-16 17:47:52 +08:00
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1173, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET,
|
|
|
|
USB_CDC_PROTO_NONE),
|
2012-05-19 11:56:07 +08:00
|
|
|
.driver_info = (unsigned long)&wwan_info,
|
|
|
|
}, {
|
|
|
|
/* ZTE (Vodafone) K3770-Z */
|
2013-09-16 17:47:52 +08:00
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1177, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET,
|
|
|
|
USB_CDC_PROTO_NONE),
|
2012-05-19 11:56:07 +08:00
|
|
|
.driver_info = (unsigned long)&wwan_info,
|
|
|
|
}, {
|
|
|
|
/* ZTE (Vodafone) K3772-Z */
|
2013-09-16 17:47:52 +08:00
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(ZTE_VENDOR_ID, 0x1181, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET,
|
|
|
|
USB_CDC_PROTO_NONE),
|
2012-05-19 11:56:07 +08:00
|
|
|
.driver_info = (unsigned long)&wwan_info,
|
2013-09-16 17:47:50 +08:00
|
|
|
}, {
|
|
|
|
/* Telit modules */
|
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(0x1bc7, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (kernel_ulong_t) &wwan_info,
|
2015-11-14 01:01:21 +08:00
|
|
|
}, {
|
|
|
|
/* Dell DW5580 modules */
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(DELL_VENDOR_ID, 0x81ba, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (kernel_ulong_t)&wwan_info,
|
cdc_ether: Improve ZTE MF823/831/910 handling
The firmware in several ZTE devices (at least the MF823/831/910
modems/mifis) use OS fingerprinting to determine which type of device to
export. In addition, these devices export a REST API which can be used to
control the type of device. So far, on Linux, the devices have been seen as
RNDIS or CDC Ether.
When CDC Ether is used, devices of the same type are, as with RNDIS,
exported with the same, bogus random MAC address. In addition, the devices
(at least on all firmware revisions I have found) use the bogus MAC when
sending traffic routed from external networks. And as a final feature, the
devices sometimes export the link state incorrectly. There are also
references online to several other ZTE devices displaying this behavior,
with several different PIDs and MAC addresses.
This patch tries to improve the handling of ZTE devices by doing the
following:
* Create a new driver_info-struct that is used by ZTE devices that do not
have an explicit entry in the product table. This struct is the same as the
default cdc_ether driver info, but a new bind- and an rx_fixup-function
have been added.
* In the new bind function, we check if we have read a random MAC from the
device. If we have, then we generate a new random MAC address. This will
ensure that all devices get a unique MAC.
* The rx_fixup-function replaces the destination MAC address in the skb
with that of the device. I have not seen a revision of these devices that
behaves correctly (i.e., sets the right destination MAC), so I chose not to
do any comparison with for example the known, bogus addresses.
* The MF823/MF832/MF910 sometimes export cdc carrier on twice on connect
(the correct behavior is off then on). Work around this by manually setting
carrier to off if an on-notification is received and the NOCARRIER-bit is
not set.
This change will affect all devices, but it should take care of similar
mistakes made by other manufacturers. I tried to think of/look/test for
problems/regressions that could be introduced by this behavior, but could
not find any. However, my familiarity with this code path is not that
great, so there could be something I have overlooked.
I have tested this patch with multiple revisions of all three devices, and
they behave as expected. In other words, they all got a valid, random MAC,
the correct operational state and I can receive/sent traffic without
problems. I also tested with some other cdc_ether devices I have and did
not find any problems/regressions caused by the two general changes.
v3->v4:
* Forgot to remove unused variables, sorry about that (thanks David
Miller).
v2->v3:
* I had forgot to remove the random MAC generation from usbnet_cdc_bind()
(thanks Oliver).
* Rework logic in the ZTE bind-function a bit.
v1->v2:
* Only generate random MAC for ZTE devices (thanks Oliver Neukum).
* Set random MAC and do RX fixup for all ZTE devices that do not have a
product-entry, as the bogus MAC have been seen on devices with several
different PIDs/MAC addresses. In other words, it seems to be the default
behavior of ZTE CDC Ether devices (thanks Lars Melin).
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
Acked-by: Oliver Neukum <oneukum@suse.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-07-21 17:10:06 +08:00
|
|
|
}, {
|
|
|
|
/* ZTE modules */
|
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(ZTE_VENDOR_ID, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET,
|
|
|
|
USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (unsigned long)&zte_cdc_info,
|
2012-05-07 12:24:51 +08:00
|
|
|
}, {
|
2005-09-01 00:54:20 +08:00
|
|
|
USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_ETHERNET,
|
|
|
|
USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (unsigned long) &cdc_info,
|
2009-02-25 12:33:58 +08:00
|
|
|
}, {
|
2010-04-23 09:07:45 +08:00
|
|
|
USB_INTERFACE_INFO(USB_CLASS_COMM, USB_CDC_SUBCLASS_MDLM,
|
|
|
|
USB_CDC_PROTO_NONE),
|
2011-04-27 17:54:28 +08:00
|
|
|
.driver_info = (unsigned long)&wwan_info,
|
2010-04-23 09:07:45 +08:00
|
|
|
|
2011-04-27 17:54:28 +08:00
|
|
|
}, {
|
|
|
|
/* Various Huawei modems with a network port like the UMG1831 */
|
2013-09-16 17:47:52 +08:00
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET, 255),
|
2011-04-27 17:54:28 +08:00
|
|
|
.driver_info = (unsigned long)&wwan_info,
|
2005-09-01 00:54:20 +08:00
|
|
|
},
|
2013-09-16 17:47:51 +08:00
|
|
|
{ }, /* END */
|
2005-09-01 00:54:20 +08:00
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(usb, products);
|
|
|
|
|
|
|
|
static struct usb_driver cdc_driver = {
|
|
|
|
.name = "cdc_ether",
|
|
|
|
.id_table = products,
|
|
|
|
.probe = usbnet_probe,
|
|
|
|
.disconnect = usbnet_disconnect,
|
|
|
|
.suspend = usbnet_suspend,
|
|
|
|
.resume = usbnet_resume,
|
2009-12-03 19:41:07 +08:00
|
|
|
.reset_resume = usbnet_resume,
|
2009-12-04 07:31:18 +08:00
|
|
|
.supports_autosuspend = 1,
|
2012-04-24 01:08:51 +08:00
|
|
|
.disable_hub_initiated_lpm = 1,
|
2005-09-01 00:54:20 +08:00
|
|
|
};
|
|
|
|
|
2011-11-19 01:44:20 +08:00
|
|
|
module_usb_driver(cdc_driver);
|
2005-09-01 00:54:20 +08:00
|
|
|
|
|
|
|
MODULE_AUTHOR("David Brownell");
|
|
|
|
MODULE_DESCRIPTION("USB CDC Ethernet devices");
|
|
|
|
MODULE_LICENSE("GPL");
|