2012-01-19 23:37:22 +08:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2012 Bjørn Mork <bjorn@mork.no>
|
|
|
|
*
|
2012-06-19 08:42:01 +08:00
|
|
|
* The probing code is heavily inspired by cdc_ether, which is:
|
|
|
|
* Copyright (C) 2003-2005 by David Brownell
|
|
|
|
* Copyright (C) 2006 by Ole Andre Vadla Ravnas (ActiveSync)
|
|
|
|
*
|
2012-01-19 23:37:22 +08:00
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* version 2 as published by the Free Software Foundation.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/netdevice.h>
|
|
|
|
#include <linux/ethtool.h>
|
2013-04-18 20:57:09 +08:00
|
|
|
#include <linux/etherdevice.h>
|
net: qmi_wwan: support "raw IP" mode
QMI wwan devices have traditionally emulated ethernet devices
by default. But they have always had the capability of operating
without any L2 header at all, transmitting and receiving "raw"
IP packets over the USB link. This firmware feature used to be
configurable through the QMI management protocol.
Traditionally there was no way to verify the firmware mode
without attempting to change it. And the firmware would often
disallow changes anyway, i.e. due to a session already being
established. In some cases, this could be a hidden firmware
internal session, completely outside host control. For these
reasons, sticking with the "well known" default mode was safest.
But newer generations of QMI hardware and firmware have moved
towards defaulting to "raw IP" mode instead, followed by an
increasing number of bugs in the already buggy "802.3" firmware
implementation. At the same time, the QMI management protocol
gained the ability to detect the current mode. This has enabled
the userspace QMI management application to verify the current
firmware mode without trying to modify it.
Following this development, the latest QMI hardware and firmware
(the MDM9x30 generation) has dropped support for "802.3" mode
entirely. Support for "raw IP" framing in the driver is therefore
necessary for these devices, and to a certain degree to work
around problems with the previous generation,
This patch adds support for "raw IP" framing for QMI devices,
changing the netdev from an ethernet device to an ARPHRD_NONE
p-t-p device when "raw IP" framing is enabled.
The firmware setup is fully delegated to the QMI userspace
management application, through simple tunneling of the QMI
protocol. The driver will therefore not know which mode has been
"negotiated" between firmware and userspace. Allowing userspace
to inform the driver of the result through a sysfs switch is
considered a better alternative than to change the well established
clean delegation of firmware management to userspace.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-04 02:24:21 +08:00
|
|
|
#include <linux/if_arp.h>
|
2012-01-19 23:37:22 +08:00
|
|
|
#include <linux/mii.h>
|
2015-12-07 04:25:50 +08:00
|
|
|
#include <linux/rtnetlink.h>
|
2012-01-19 23:37:22 +08:00
|
|
|
#include <linux/usb.h>
|
|
|
|
#include <linux/usb/cdc.h>
|
|
|
|
#include <linux/usb/usbnet.h>
|
2012-03-09 19:35:05 +08:00
|
|
|
#include <linux/usb/cdc-wdm.h>
|
2012-01-19 23:37:22 +08:00
|
|
|
|
2012-06-19 08:42:01 +08:00
|
|
|
/* This driver supports wwan (3G/LTE/?) devices using a vendor
|
2012-01-19 23:37:22 +08:00
|
|
|
* specific management protocol called Qualcomm MSM Interface (QMI) -
|
|
|
|
* in addition to the more common AT commands over serial interface
|
|
|
|
* management
|
|
|
|
*
|
|
|
|
* QMI is wrapped in CDC, using CDC encapsulated commands on the
|
|
|
|
* control ("master") interface of a two-interface CDC Union
|
|
|
|
* resembling standard CDC ECM. The devices do not use the control
|
|
|
|
* interface for any other CDC messages. Most likely because the
|
|
|
|
* management protocol is used in place of the standard CDC
|
|
|
|
* notifications NOTIFY_NETWORK_CONNECTION and NOTIFY_SPEED_CHANGE
|
|
|
|
*
|
2012-06-19 08:42:01 +08:00
|
|
|
* Alternatively, control and data functions can be combined in a
|
|
|
|
* single USB interface.
|
|
|
|
*
|
2012-01-19 23:37:22 +08:00
|
|
|
* Handling a protocol like QMI is out of the scope for any driver.
|
2012-06-19 08:42:01 +08:00
|
|
|
* It is exported as a character device using the cdc-wdm driver as
|
|
|
|
* a subdriver, enabling userspace applications ("modem managers") to
|
|
|
|
* handle it.
|
2012-01-19 23:37:22 +08:00
|
|
|
*
|
|
|
|
* These devices may alternatively/additionally be configured using AT
|
2012-06-19 08:42:01 +08:00
|
|
|
* commands on a serial interface
|
2012-01-19 23:37:22 +08:00
|
|
|
*/
|
|
|
|
|
2012-06-19 08:41:59 +08:00
|
|
|
/* driver specific data */
|
|
|
|
struct qmi_wwan_state {
|
|
|
|
struct usb_driver *subdriver;
|
|
|
|
atomic_t pmcount;
|
net: qmi_wwan: support "raw IP" mode
QMI wwan devices have traditionally emulated ethernet devices
by default. But they have always had the capability of operating
without any L2 header at all, transmitting and receiving "raw"
IP packets over the USB link. This firmware feature used to be
configurable through the QMI management protocol.
Traditionally there was no way to verify the firmware mode
without attempting to change it. And the firmware would often
disallow changes anyway, i.e. due to a session already being
established. In some cases, this could be a hidden firmware
internal session, completely outside host control. For these
reasons, sticking with the "well known" default mode was safest.
But newer generations of QMI hardware and firmware have moved
towards defaulting to "raw IP" mode instead, followed by an
increasing number of bugs in the already buggy "802.3" firmware
implementation. At the same time, the QMI management protocol
gained the ability to detect the current mode. This has enabled
the userspace QMI management application to verify the current
firmware mode without trying to modify it.
Following this development, the latest QMI hardware and firmware
(the MDM9x30 generation) has dropped support for "802.3" mode
entirely. Support for "raw IP" framing in the driver is therefore
necessary for these devices, and to a certain degree to work
around problems with the previous generation,
This patch adds support for "raw IP" framing for QMI devices,
changing the netdev from an ethernet device to an ARPHRD_NONE
p-t-p device when "raw IP" framing is enabled.
The firmware setup is fully delegated to the QMI userspace
management application, through simple tunneling of the QMI
protocol. The driver will therefore not know which mode has been
"negotiated" between firmware and userspace. Allowing userspace
to inform the driver of the result through a sysfs switch is
considered a better alternative than to change the well established
clean delegation of firmware management to userspace.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-04 02:24:21 +08:00
|
|
|
unsigned long flags;
|
2012-06-19 08:42:00 +08:00
|
|
|
struct usb_interface *control;
|
|
|
|
struct usb_interface *data;
|
2012-06-19 08:41:59 +08:00
|
|
|
};
|
|
|
|
|
net: qmi_wwan: support "raw IP" mode
QMI wwan devices have traditionally emulated ethernet devices
by default. But they have always had the capability of operating
without any L2 header at all, transmitting and receiving "raw"
IP packets over the USB link. This firmware feature used to be
configurable through the QMI management protocol.
Traditionally there was no way to verify the firmware mode
without attempting to change it. And the firmware would often
disallow changes anyway, i.e. due to a session already being
established. In some cases, this could be a hidden firmware
internal session, completely outside host control. For these
reasons, sticking with the "well known" default mode was safest.
But newer generations of QMI hardware and firmware have moved
towards defaulting to "raw IP" mode instead, followed by an
increasing number of bugs in the already buggy "802.3" firmware
implementation. At the same time, the QMI management protocol
gained the ability to detect the current mode. This has enabled
the userspace QMI management application to verify the current
firmware mode without trying to modify it.
Following this development, the latest QMI hardware and firmware
(the MDM9x30 generation) has dropped support for "802.3" mode
entirely. Support for "raw IP" framing in the driver is therefore
necessary for these devices, and to a certain degree to work
around problems with the previous generation,
This patch adds support for "raw IP" framing for QMI devices,
changing the netdev from an ethernet device to an ARPHRD_NONE
p-t-p device when "raw IP" framing is enabled.
The firmware setup is fully delegated to the QMI userspace
management application, through simple tunneling of the QMI
protocol. The driver will therefore not know which mode has been
"negotiated" between firmware and userspace. Allowing userspace
to inform the driver of the result through a sysfs switch is
considered a better alternative than to change the well established
clean delegation of firmware management to userspace.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-04 02:24:21 +08:00
|
|
|
enum qmi_wwan_flags {
|
|
|
|
QMI_WWAN_FLAG_RAWIP = 1 << 0,
|
|
|
|
};
|
|
|
|
|
|
|
|
static void qmi_wwan_netdev_setup(struct net_device *net)
|
|
|
|
{
|
|
|
|
struct usbnet *dev = netdev_priv(net);
|
|
|
|
struct qmi_wwan_state *info = (void *)&dev->data;
|
|
|
|
|
|
|
|
if (info->flags & QMI_WWAN_FLAG_RAWIP) {
|
|
|
|
net->header_ops = NULL; /* No header */
|
|
|
|
net->type = ARPHRD_NONE;
|
|
|
|
net->hard_header_len = 0;
|
|
|
|
net->addr_len = 0;
|
|
|
|
net->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST;
|
|
|
|
netdev_dbg(net, "mode: raw IP\n");
|
|
|
|
} else if (!net->header_ops) { /* don't bother if already set */
|
|
|
|
ether_setup(net);
|
|
|
|
netdev_dbg(net, "mode: Ethernet\n");
|
|
|
|
}
|
|
|
|
|
|
|
|
/* recalculate buffers after changing hard_header_len */
|
|
|
|
usbnet_change_mtu(net, net->mtu);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t raw_ip_show(struct device *d, struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct usbnet *dev = netdev_priv(to_net_dev(d));
|
|
|
|
struct qmi_wwan_state *info = (void *)&dev->data;
|
|
|
|
|
|
|
|
return sprintf(buf, "%c\n", info->flags & QMI_WWAN_FLAG_RAWIP ? 'Y' : 'N');
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t raw_ip_store(struct device *d, struct device_attribute *attr, const char *buf, size_t len)
|
|
|
|
{
|
|
|
|
struct usbnet *dev = netdev_priv(to_net_dev(d));
|
|
|
|
struct qmi_wwan_state *info = (void *)&dev->data;
|
|
|
|
bool enable;
|
2015-12-07 04:25:50 +08:00
|
|
|
int ret;
|
net: qmi_wwan: support "raw IP" mode
QMI wwan devices have traditionally emulated ethernet devices
by default. But they have always had the capability of operating
without any L2 header at all, transmitting and receiving "raw"
IP packets over the USB link. This firmware feature used to be
configurable through the QMI management protocol.
Traditionally there was no way to verify the firmware mode
without attempting to change it. And the firmware would often
disallow changes anyway, i.e. due to a session already being
established. In some cases, this could be a hidden firmware
internal session, completely outside host control. For these
reasons, sticking with the "well known" default mode was safest.
But newer generations of QMI hardware and firmware have moved
towards defaulting to "raw IP" mode instead, followed by an
increasing number of bugs in the already buggy "802.3" firmware
implementation. At the same time, the QMI management protocol
gained the ability to detect the current mode. This has enabled
the userspace QMI management application to verify the current
firmware mode without trying to modify it.
Following this development, the latest QMI hardware and firmware
(the MDM9x30 generation) has dropped support for "802.3" mode
entirely. Support for "raw IP" framing in the driver is therefore
necessary for these devices, and to a certain degree to work
around problems with the previous generation,
This patch adds support for "raw IP" framing for QMI devices,
changing the netdev from an ethernet device to an ARPHRD_NONE
p-t-p device when "raw IP" framing is enabled.
The firmware setup is fully delegated to the QMI userspace
management application, through simple tunneling of the QMI
protocol. The driver will therefore not know which mode has been
"negotiated" between firmware and userspace. Allowing userspace
to inform the driver of the result through a sysfs switch is
considered a better alternative than to change the well established
clean delegation of firmware management to userspace.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-04 02:24:21 +08:00
|
|
|
|
|
|
|
if (strtobool(buf, &enable))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* no change? */
|
|
|
|
if (enable == (info->flags & QMI_WWAN_FLAG_RAWIP))
|
|
|
|
return len;
|
|
|
|
|
2015-12-07 04:25:50 +08:00
|
|
|
if (!rtnl_trylock())
|
|
|
|
return restart_syscall();
|
|
|
|
|
net: qmi_wwan: support "raw IP" mode
QMI wwan devices have traditionally emulated ethernet devices
by default. But they have always had the capability of operating
without any L2 header at all, transmitting and receiving "raw"
IP packets over the USB link. This firmware feature used to be
configurable through the QMI management protocol.
Traditionally there was no way to verify the firmware mode
without attempting to change it. And the firmware would often
disallow changes anyway, i.e. due to a session already being
established. In some cases, this could be a hidden firmware
internal session, completely outside host control. For these
reasons, sticking with the "well known" default mode was safest.
But newer generations of QMI hardware and firmware have moved
towards defaulting to "raw IP" mode instead, followed by an
increasing number of bugs in the already buggy "802.3" firmware
implementation. At the same time, the QMI management protocol
gained the ability to detect the current mode. This has enabled
the userspace QMI management application to verify the current
firmware mode without trying to modify it.
Following this development, the latest QMI hardware and firmware
(the MDM9x30 generation) has dropped support for "802.3" mode
entirely. Support for "raw IP" framing in the driver is therefore
necessary for these devices, and to a certain degree to work
around problems with the previous generation,
This patch adds support for "raw IP" framing for QMI devices,
changing the netdev from an ethernet device to an ARPHRD_NONE
p-t-p device when "raw IP" framing is enabled.
The firmware setup is fully delegated to the QMI userspace
management application, through simple tunneling of the QMI
protocol. The driver will therefore not know which mode has been
"negotiated" between firmware and userspace. Allowing userspace
to inform the driver of the result through a sysfs switch is
considered a better alternative than to change the well established
clean delegation of firmware management to userspace.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-04 02:24:21 +08:00
|
|
|
/* we don't want to modify a running netdev */
|
|
|
|
if (netif_running(dev->net)) {
|
|
|
|
netdev_err(dev->net, "Cannot change a running device\n");
|
2015-12-07 04:25:50 +08:00
|
|
|
ret = -EBUSY;
|
|
|
|
goto err;
|
net: qmi_wwan: support "raw IP" mode
QMI wwan devices have traditionally emulated ethernet devices
by default. But they have always had the capability of operating
without any L2 header at all, transmitting and receiving "raw"
IP packets over the USB link. This firmware feature used to be
configurable through the QMI management protocol.
Traditionally there was no way to verify the firmware mode
without attempting to change it. And the firmware would often
disallow changes anyway, i.e. due to a session already being
established. In some cases, this could be a hidden firmware
internal session, completely outside host control. For these
reasons, sticking with the "well known" default mode was safest.
But newer generations of QMI hardware and firmware have moved
towards defaulting to "raw IP" mode instead, followed by an
increasing number of bugs in the already buggy "802.3" firmware
implementation. At the same time, the QMI management protocol
gained the ability to detect the current mode. This has enabled
the userspace QMI management application to verify the current
firmware mode without trying to modify it.
Following this development, the latest QMI hardware and firmware
(the MDM9x30 generation) has dropped support for "802.3" mode
entirely. Support for "raw IP" framing in the driver is therefore
necessary for these devices, and to a certain degree to work
around problems with the previous generation,
This patch adds support for "raw IP" framing for QMI devices,
changing the netdev from an ethernet device to an ARPHRD_NONE
p-t-p device when "raw IP" framing is enabled.
The firmware setup is fully delegated to the QMI userspace
management application, through simple tunneling of the QMI
protocol. The driver will therefore not know which mode has been
"negotiated" between firmware and userspace. Allowing userspace
to inform the driver of the result through a sysfs switch is
considered a better alternative than to change the well established
clean delegation of firmware management to userspace.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-04 02:24:21 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* let other drivers deny the change */
|
2015-12-07 04:25:50 +08:00
|
|
|
ret = call_netdevice_notifiers(NETDEV_PRE_TYPE_CHANGE, dev->net);
|
|
|
|
ret = notifier_to_errno(ret);
|
|
|
|
if (ret) {
|
net: qmi_wwan: support "raw IP" mode
QMI wwan devices have traditionally emulated ethernet devices
by default. But they have always had the capability of operating
without any L2 header at all, transmitting and receiving "raw"
IP packets over the USB link. This firmware feature used to be
configurable through the QMI management protocol.
Traditionally there was no way to verify the firmware mode
without attempting to change it. And the firmware would often
disallow changes anyway, i.e. due to a session already being
established. In some cases, this could be a hidden firmware
internal session, completely outside host control. For these
reasons, sticking with the "well known" default mode was safest.
But newer generations of QMI hardware and firmware have moved
towards defaulting to "raw IP" mode instead, followed by an
increasing number of bugs in the already buggy "802.3" firmware
implementation. At the same time, the QMI management protocol
gained the ability to detect the current mode. This has enabled
the userspace QMI management application to verify the current
firmware mode without trying to modify it.
Following this development, the latest QMI hardware and firmware
(the MDM9x30 generation) has dropped support for "802.3" mode
entirely. Support for "raw IP" framing in the driver is therefore
necessary for these devices, and to a certain degree to work
around problems with the previous generation,
This patch adds support for "raw IP" framing for QMI devices,
changing the netdev from an ethernet device to an ARPHRD_NONE
p-t-p device when "raw IP" framing is enabled.
The firmware setup is fully delegated to the QMI userspace
management application, through simple tunneling of the QMI
protocol. The driver will therefore not know which mode has been
"negotiated" between firmware and userspace. Allowing userspace
to inform the driver of the result through a sysfs switch is
considered a better alternative than to change the well established
clean delegation of firmware management to userspace.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-04 02:24:21 +08:00
|
|
|
netdev_err(dev->net, "Type change was refused\n");
|
2015-12-07 04:25:50 +08:00
|
|
|
goto err;
|
net: qmi_wwan: support "raw IP" mode
QMI wwan devices have traditionally emulated ethernet devices
by default. But they have always had the capability of operating
without any L2 header at all, transmitting and receiving "raw"
IP packets over the USB link. This firmware feature used to be
configurable through the QMI management protocol.
Traditionally there was no way to verify the firmware mode
without attempting to change it. And the firmware would often
disallow changes anyway, i.e. due to a session already being
established. In some cases, this could be a hidden firmware
internal session, completely outside host control. For these
reasons, sticking with the "well known" default mode was safest.
But newer generations of QMI hardware and firmware have moved
towards defaulting to "raw IP" mode instead, followed by an
increasing number of bugs in the already buggy "802.3" firmware
implementation. At the same time, the QMI management protocol
gained the ability to detect the current mode. This has enabled
the userspace QMI management application to verify the current
firmware mode without trying to modify it.
Following this development, the latest QMI hardware and firmware
(the MDM9x30 generation) has dropped support for "802.3" mode
entirely. Support for "raw IP" framing in the driver is therefore
necessary for these devices, and to a certain degree to work
around problems with the previous generation,
This patch adds support for "raw IP" framing for QMI devices,
changing the netdev from an ethernet device to an ARPHRD_NONE
p-t-p device when "raw IP" framing is enabled.
The firmware setup is fully delegated to the QMI userspace
management application, through simple tunneling of the QMI
protocol. The driver will therefore not know which mode has been
"negotiated" between firmware and userspace. Allowing userspace
to inform the driver of the result through a sysfs switch is
considered a better alternative than to change the well established
clean delegation of firmware management to userspace.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-04 02:24:21 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (enable)
|
|
|
|
info->flags |= QMI_WWAN_FLAG_RAWIP;
|
|
|
|
else
|
|
|
|
info->flags &= ~QMI_WWAN_FLAG_RAWIP;
|
|
|
|
qmi_wwan_netdev_setup(dev->net);
|
|
|
|
call_netdevice_notifiers(NETDEV_POST_TYPE_CHANGE, dev->net);
|
2015-12-07 04:25:50 +08:00
|
|
|
ret = len;
|
|
|
|
err:
|
|
|
|
rtnl_unlock();
|
|
|
|
return ret;
|
net: qmi_wwan: support "raw IP" mode
QMI wwan devices have traditionally emulated ethernet devices
by default. But they have always had the capability of operating
without any L2 header at all, transmitting and receiving "raw"
IP packets over the USB link. This firmware feature used to be
configurable through the QMI management protocol.
Traditionally there was no way to verify the firmware mode
without attempting to change it. And the firmware would often
disallow changes anyway, i.e. due to a session already being
established. In some cases, this could be a hidden firmware
internal session, completely outside host control. For these
reasons, sticking with the "well known" default mode was safest.
But newer generations of QMI hardware and firmware have moved
towards defaulting to "raw IP" mode instead, followed by an
increasing number of bugs in the already buggy "802.3" firmware
implementation. At the same time, the QMI management protocol
gained the ability to detect the current mode. This has enabled
the userspace QMI management application to verify the current
firmware mode without trying to modify it.
Following this development, the latest QMI hardware and firmware
(the MDM9x30 generation) has dropped support for "802.3" mode
entirely. Support for "raw IP" framing in the driver is therefore
necessary for these devices, and to a certain degree to work
around problems with the previous generation,
This patch adds support for "raw IP" framing for QMI devices,
changing the netdev from an ethernet device to an ARPHRD_NONE
p-t-p device when "raw IP" framing is enabled.
The firmware setup is fully delegated to the QMI userspace
management application, through simple tunneling of the QMI
protocol. The driver will therefore not know which mode has been
"negotiated" between firmware and userspace. Allowing userspace
to inform the driver of the result through a sysfs switch is
considered a better alternative than to change the well established
clean delegation of firmware management to userspace.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-04 02:24:21 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static DEVICE_ATTR_RW(raw_ip);
|
|
|
|
|
|
|
|
static struct attribute *qmi_wwan_sysfs_attrs[] = {
|
|
|
|
&dev_attr_raw_ip.attr,
|
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct attribute_group qmi_wwan_sysfs_attr_group = {
|
|
|
|
.name = "qmi",
|
|
|
|
.attrs = qmi_wwan_sysfs_attrs,
|
|
|
|
};
|
|
|
|
|
2013-04-18 20:57:11 +08:00
|
|
|
/* default ethernet address used by the modem */
|
|
|
|
static const u8 default_modem_addr[ETH_ALEN] = {0x02, 0x50, 0xf3};
|
|
|
|
|
2015-01-02 23:21:45 +08:00
|
|
|
static const u8 buggy_fw_addr[ETH_ALEN] = {0x00, 0xa0, 0xc6, 0x00, 0x00, 0x00};
|
|
|
|
|
2013-04-18 20:57:09 +08:00
|
|
|
/* Make up an ethernet header if the packet doesn't have one.
|
|
|
|
*
|
|
|
|
* A firmware bug common among several devices cause them to send raw
|
|
|
|
* IP packets under some circumstances. There is no way for the
|
|
|
|
* driver/host to know when this will happen. And even when the bug
|
|
|
|
* hits, some packets will still arrive with an intact header.
|
|
|
|
*
|
|
|
|
* The supported devices are only capably of sending IPv4, IPv6 and
|
|
|
|
* ARP packets on a point-to-point link. Any packet with an ethernet
|
|
|
|
* header will have either our address or a broadcast/multicast
|
|
|
|
* address as destination. ARP packets will always have a header.
|
|
|
|
*
|
|
|
|
* This means that this function will reliably add the appropriate
|
|
|
|
* header iff necessary, provided our hardware address does not start
|
|
|
|
* with 4 or 6.
|
net: qmi_wwan: fixup destination address (firmware bug workaround)
Received packets are sometimes addressed to 00:a0:c6:00:00:00
instead of the address the device firmware should have learned
from the host:
321.224126 77.16.85.204 -> 148.122.171.134 ICMP 98 Echo (ping) request id=0x4025, seq=64/16384, ttl=64
0000 82 c0 82 c9 f1 67 82 c0 82 c9 f1 67 08 00 45 00 .....g.....g..E.
0010 00 54 00 00 40 00 40 01 57 cc 4d 10 55 cc 94 7a .T..@.@.W.M.U..z
0020 ab 86 08 00 62 fc 40 25 00 40 b2 bc 6e 51 00 00 ....b.@%.@..nQ..
0030 00 00 6b bd 09 00 00 00 00 00 10 11 12 13 14 15 ..k.............
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0060 36 37 67
321.240607 148.122.171.134 -> 77.16.85.204 ICMP 98 Echo (ping) reply id=0x4025, seq=64/16384, ttl=55
0000 00 a0 c6 00 00 00 02 50 f3 00 00 00 08 00 45 00 .......P......E.
0010 00 54 00 56 00 00 37 01 a0 76 94 7a ab 86 4d 10 .T.V..7..v.z..M.
0020 55 cc 00 00 6a fc 40 25 00 40 b2 bc 6e 51 00 00 U...j.@%.@..nQ..
0030 00 00 6b bd 09 00 00 00 00 00 10 11 12 13 14 15 ..k.............
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0060 36 37 67
The bogus address is always the same, and matches the address
suggested by many devices as a default address. It is likely a
hardcoded firmware default.
The circumstances where this bug has been observed indicates that
the trigger is related to timing or some other factor the host
cannot control. Repeating the exact same configuration sequence
that caused it to trigger once, will not necessarily cause it to
trigger the next time. Reproducing the bug is therefore difficult.
This opens up a possibility that the bug is more common than we can
confirm, because affected devices often will work properly again
after a reset. A procedure most users are likely to try out before
reporting a bug.
Unconditionally rewriting the destination address if the first digit
of the received packet is 0, is considered an acceptable compromise
since we already have to inspect this digit. The simplification will
cause unnecessary rewrites if the real address starts with 0, but this
is still better than adding additional tests for this particular case.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-18 20:57:10 +08:00
|
|
|
*
|
|
|
|
* Another common firmware bug results in all packets being addressed
|
|
|
|
* to 00:a0:c6:00:00:00 despite the host address being different.
|
|
|
|
* This function will also fixup such packets.
|
2013-04-18 20:57:09 +08:00
|
|
|
*/
|
|
|
|
static int qmi_wwan_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
|
|
|
|
{
|
net: qmi_wwan: support "raw IP" mode
QMI wwan devices have traditionally emulated ethernet devices
by default. But they have always had the capability of operating
without any L2 header at all, transmitting and receiving "raw"
IP packets over the USB link. This firmware feature used to be
configurable through the QMI management protocol.
Traditionally there was no way to verify the firmware mode
without attempting to change it. And the firmware would often
disallow changes anyway, i.e. due to a session already being
established. In some cases, this could be a hidden firmware
internal session, completely outside host control. For these
reasons, sticking with the "well known" default mode was safest.
But newer generations of QMI hardware and firmware have moved
towards defaulting to "raw IP" mode instead, followed by an
increasing number of bugs in the already buggy "802.3" firmware
implementation. At the same time, the QMI management protocol
gained the ability to detect the current mode. This has enabled
the userspace QMI management application to verify the current
firmware mode without trying to modify it.
Following this development, the latest QMI hardware and firmware
(the MDM9x30 generation) has dropped support for "802.3" mode
entirely. Support for "raw IP" framing in the driver is therefore
necessary for these devices, and to a certain degree to work
around problems with the previous generation,
This patch adds support for "raw IP" framing for QMI devices,
changing the netdev from an ethernet device to an ARPHRD_NONE
p-t-p device when "raw IP" framing is enabled.
The firmware setup is fully delegated to the QMI userspace
management application, through simple tunneling of the QMI
protocol. The driver will therefore not know which mode has been
"negotiated" between firmware and userspace. Allowing userspace
to inform the driver of the result through a sysfs switch is
considered a better alternative than to change the well established
clean delegation of firmware management to userspace.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-04 02:24:21 +08:00
|
|
|
struct qmi_wwan_state *info = (void *)&dev->data;
|
|
|
|
bool rawip = info->flags & QMI_WWAN_FLAG_RAWIP;
|
2013-04-18 20:57:09 +08:00
|
|
|
__be16 proto;
|
|
|
|
|
2014-02-14 00:50:19 +08:00
|
|
|
/* This check is no longer done by usbnet */
|
|
|
|
if (skb->len < dev->net->hard_header_len)
|
|
|
|
return 0;
|
|
|
|
|
2013-04-18 20:57:09 +08:00
|
|
|
switch (skb->data[0] & 0xf0) {
|
|
|
|
case 0x40:
|
|
|
|
proto = htons(ETH_P_IP);
|
|
|
|
break;
|
|
|
|
case 0x60:
|
|
|
|
proto = htons(ETH_P_IPV6);
|
|
|
|
break;
|
net: qmi_wwan: fixup destination address (firmware bug workaround)
Received packets are sometimes addressed to 00:a0:c6:00:00:00
instead of the address the device firmware should have learned
from the host:
321.224126 77.16.85.204 -> 148.122.171.134 ICMP 98 Echo (ping) request id=0x4025, seq=64/16384, ttl=64
0000 82 c0 82 c9 f1 67 82 c0 82 c9 f1 67 08 00 45 00 .....g.....g..E.
0010 00 54 00 00 40 00 40 01 57 cc 4d 10 55 cc 94 7a .T..@.@.W.M.U..z
0020 ab 86 08 00 62 fc 40 25 00 40 b2 bc 6e 51 00 00 ....b.@%.@..nQ..
0030 00 00 6b bd 09 00 00 00 00 00 10 11 12 13 14 15 ..k.............
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0060 36 37 67
321.240607 148.122.171.134 -> 77.16.85.204 ICMP 98 Echo (ping) reply id=0x4025, seq=64/16384, ttl=55
0000 00 a0 c6 00 00 00 02 50 f3 00 00 00 08 00 45 00 .......P......E.
0010 00 54 00 56 00 00 37 01 a0 76 94 7a ab 86 4d 10 .T.V..7..v.z..M.
0020 55 cc 00 00 6a fc 40 25 00 40 b2 bc 6e 51 00 00 U...j.@%.@..nQ..
0030 00 00 6b bd 09 00 00 00 00 00 10 11 12 13 14 15 ..k.............
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0060 36 37 67
The bogus address is always the same, and matches the address
suggested by many devices as a default address. It is likely a
hardcoded firmware default.
The circumstances where this bug has been observed indicates that
the trigger is related to timing or some other factor the host
cannot control. Repeating the exact same configuration sequence
that caused it to trigger once, will not necessarily cause it to
trigger the next time. Reproducing the bug is therefore difficult.
This opens up a possibility that the bug is more common than we can
confirm, because affected devices often will work properly again
after a reset. A procedure most users are likely to try out before
reporting a bug.
Unconditionally rewriting the destination address if the first digit
of the received packet is 0, is considered an acceptable compromise
since we already have to inspect this digit. The simplification will
cause unnecessary rewrites if the real address starts with 0, but this
is still better than adding additional tests for this particular case.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-18 20:57:10 +08:00
|
|
|
case 0x00:
|
net: qmi_wwan: support "raw IP" mode
QMI wwan devices have traditionally emulated ethernet devices
by default. But they have always had the capability of operating
without any L2 header at all, transmitting and receiving "raw"
IP packets over the USB link. This firmware feature used to be
configurable through the QMI management protocol.
Traditionally there was no way to verify the firmware mode
without attempting to change it. And the firmware would often
disallow changes anyway, i.e. due to a session already being
established. In some cases, this could be a hidden firmware
internal session, completely outside host control. For these
reasons, sticking with the "well known" default mode was safest.
But newer generations of QMI hardware and firmware have moved
towards defaulting to "raw IP" mode instead, followed by an
increasing number of bugs in the already buggy "802.3" firmware
implementation. At the same time, the QMI management protocol
gained the ability to detect the current mode. This has enabled
the userspace QMI management application to verify the current
firmware mode without trying to modify it.
Following this development, the latest QMI hardware and firmware
(the MDM9x30 generation) has dropped support for "802.3" mode
entirely. Support for "raw IP" framing in the driver is therefore
necessary for these devices, and to a certain degree to work
around problems with the previous generation,
This patch adds support for "raw IP" framing for QMI devices,
changing the netdev from an ethernet device to an ARPHRD_NONE
p-t-p device when "raw IP" framing is enabled.
The firmware setup is fully delegated to the QMI userspace
management application, through simple tunneling of the QMI
protocol. The driver will therefore not know which mode has been
"negotiated" between firmware and userspace. Allowing userspace
to inform the driver of the result through a sysfs switch is
considered a better alternative than to change the well established
clean delegation of firmware management to userspace.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-04 02:24:21 +08:00
|
|
|
if (rawip)
|
|
|
|
return 0;
|
net: qmi_wwan: fixup destination address (firmware bug workaround)
Received packets are sometimes addressed to 00:a0:c6:00:00:00
instead of the address the device firmware should have learned
from the host:
321.224126 77.16.85.204 -> 148.122.171.134 ICMP 98 Echo (ping) request id=0x4025, seq=64/16384, ttl=64
0000 82 c0 82 c9 f1 67 82 c0 82 c9 f1 67 08 00 45 00 .....g.....g..E.
0010 00 54 00 00 40 00 40 01 57 cc 4d 10 55 cc 94 7a .T..@.@.W.M.U..z
0020 ab 86 08 00 62 fc 40 25 00 40 b2 bc 6e 51 00 00 ....b.@%.@..nQ..
0030 00 00 6b bd 09 00 00 00 00 00 10 11 12 13 14 15 ..k.............
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0060 36 37 67
321.240607 148.122.171.134 -> 77.16.85.204 ICMP 98 Echo (ping) reply id=0x4025, seq=64/16384, ttl=55
0000 00 a0 c6 00 00 00 02 50 f3 00 00 00 08 00 45 00 .......P......E.
0010 00 54 00 56 00 00 37 01 a0 76 94 7a ab 86 4d 10 .T.V..7..v.z..M.
0020 55 cc 00 00 6a fc 40 25 00 40 b2 bc 6e 51 00 00 U...j.@%.@..nQ..
0030 00 00 6b bd 09 00 00 00 00 00 10 11 12 13 14 15 ..k.............
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0060 36 37 67
The bogus address is always the same, and matches the address
suggested by many devices as a default address. It is likely a
hardcoded firmware default.
The circumstances where this bug has been observed indicates that
the trigger is related to timing or some other factor the host
cannot control. Repeating the exact same configuration sequence
that caused it to trigger once, will not necessarily cause it to
trigger the next time. Reproducing the bug is therefore difficult.
This opens up a possibility that the bug is more common than we can
confirm, because affected devices often will work properly again
after a reset. A procedure most users are likely to try out before
reporting a bug.
Unconditionally rewriting the destination address if the first digit
of the received packet is 0, is considered an acceptable compromise
since we already have to inspect this digit. The simplification will
cause unnecessary rewrites if the real address starts with 0, but this
is still better than adding additional tests for this particular case.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-18 20:57:10 +08:00
|
|
|
if (is_multicast_ether_addr(skb->data))
|
|
|
|
return 1;
|
|
|
|
/* possibly bogus destination - rewrite just in case */
|
|
|
|
skb_reset_mac_header(skb);
|
|
|
|
goto fix_dest;
|
2013-04-18 20:57:09 +08:00
|
|
|
default:
|
net: qmi_wwan: support "raw IP" mode
QMI wwan devices have traditionally emulated ethernet devices
by default. But they have always had the capability of operating
without any L2 header at all, transmitting and receiving "raw"
IP packets over the USB link. This firmware feature used to be
configurable through the QMI management protocol.
Traditionally there was no way to verify the firmware mode
without attempting to change it. And the firmware would often
disallow changes anyway, i.e. due to a session already being
established. In some cases, this could be a hidden firmware
internal session, completely outside host control. For these
reasons, sticking with the "well known" default mode was safest.
But newer generations of QMI hardware and firmware have moved
towards defaulting to "raw IP" mode instead, followed by an
increasing number of bugs in the already buggy "802.3" firmware
implementation. At the same time, the QMI management protocol
gained the ability to detect the current mode. This has enabled
the userspace QMI management application to verify the current
firmware mode without trying to modify it.
Following this development, the latest QMI hardware and firmware
(the MDM9x30 generation) has dropped support for "802.3" mode
entirely. Support for "raw IP" framing in the driver is therefore
necessary for these devices, and to a certain degree to work
around problems with the previous generation,
This patch adds support for "raw IP" framing for QMI devices,
changing the netdev from an ethernet device to an ARPHRD_NONE
p-t-p device when "raw IP" framing is enabled.
The firmware setup is fully delegated to the QMI userspace
management application, through simple tunneling of the QMI
protocol. The driver will therefore not know which mode has been
"negotiated" between firmware and userspace. Allowing userspace
to inform the driver of the result through a sysfs switch is
considered a better alternative than to change the well established
clean delegation of firmware management to userspace.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-04 02:24:21 +08:00
|
|
|
if (rawip)
|
|
|
|
return 0;
|
2013-04-18 20:57:09 +08:00
|
|
|
/* pass along other packets without modifications */
|
|
|
|
return 1;
|
|
|
|
}
|
net: qmi_wwan: support "raw IP" mode
QMI wwan devices have traditionally emulated ethernet devices
by default. But they have always had the capability of operating
without any L2 header at all, transmitting and receiving "raw"
IP packets over the USB link. This firmware feature used to be
configurable through the QMI management protocol.
Traditionally there was no way to verify the firmware mode
without attempting to change it. And the firmware would often
disallow changes anyway, i.e. due to a session already being
established. In some cases, this could be a hidden firmware
internal session, completely outside host control. For these
reasons, sticking with the "well known" default mode was safest.
But newer generations of QMI hardware and firmware have moved
towards defaulting to "raw IP" mode instead, followed by an
increasing number of bugs in the already buggy "802.3" firmware
implementation. At the same time, the QMI management protocol
gained the ability to detect the current mode. This has enabled
the userspace QMI management application to verify the current
firmware mode without trying to modify it.
Following this development, the latest QMI hardware and firmware
(the MDM9x30 generation) has dropped support for "802.3" mode
entirely. Support for "raw IP" framing in the driver is therefore
necessary for these devices, and to a certain degree to work
around problems with the previous generation,
This patch adds support for "raw IP" framing for QMI devices,
changing the netdev from an ethernet device to an ARPHRD_NONE
p-t-p device when "raw IP" framing is enabled.
The firmware setup is fully delegated to the QMI userspace
management application, through simple tunneling of the QMI
protocol. The driver will therefore not know which mode has been
"negotiated" between firmware and userspace. Allowing userspace
to inform the driver of the result through a sysfs switch is
considered a better alternative than to change the well established
clean delegation of firmware management to userspace.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-04 02:24:21 +08:00
|
|
|
if (rawip) {
|
|
|
|
skb->dev = dev->net; /* normally set by eth_type_trans */
|
|
|
|
skb->protocol = proto;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2013-04-18 20:57:09 +08:00
|
|
|
if (skb_headroom(skb) < ETH_HLEN)
|
|
|
|
return 0;
|
|
|
|
skb_push(skb, ETH_HLEN);
|
|
|
|
skb_reset_mac_header(skb);
|
|
|
|
eth_hdr(skb)->h_proto = proto;
|
2015-03-03 11:54:48 +08:00
|
|
|
eth_zero_addr(eth_hdr(skb)->h_source);
|
net: qmi_wwan: fixup destination address (firmware bug workaround)
Received packets are sometimes addressed to 00:a0:c6:00:00:00
instead of the address the device firmware should have learned
from the host:
321.224126 77.16.85.204 -> 148.122.171.134 ICMP 98 Echo (ping) request id=0x4025, seq=64/16384, ttl=64
0000 82 c0 82 c9 f1 67 82 c0 82 c9 f1 67 08 00 45 00 .....g.....g..E.
0010 00 54 00 00 40 00 40 01 57 cc 4d 10 55 cc 94 7a .T..@.@.W.M.U..z
0020 ab 86 08 00 62 fc 40 25 00 40 b2 bc 6e 51 00 00 ....b.@%.@..nQ..
0030 00 00 6b bd 09 00 00 00 00 00 10 11 12 13 14 15 ..k.............
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0060 36 37 67
321.240607 148.122.171.134 -> 77.16.85.204 ICMP 98 Echo (ping) reply id=0x4025, seq=64/16384, ttl=55
0000 00 a0 c6 00 00 00 02 50 f3 00 00 00 08 00 45 00 .......P......E.
0010 00 54 00 56 00 00 37 01 a0 76 94 7a ab 86 4d 10 .T.V..7..v.z..M.
0020 55 cc 00 00 6a fc 40 25 00 40 b2 bc 6e 51 00 00 U...j.@%.@..nQ..
0030 00 00 6b bd 09 00 00 00 00 00 10 11 12 13 14 15 ..k.............
0040 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 .......... !"#$%
0050 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35 &'()*+,-./012345
0060 36 37 67
The bogus address is always the same, and matches the address
suggested by many devices as a default address. It is likely a
hardcoded firmware default.
The circumstances where this bug has been observed indicates that
the trigger is related to timing or some other factor the host
cannot control. Repeating the exact same configuration sequence
that caused it to trigger once, will not necessarily cause it to
trigger the next time. Reproducing the bug is therefore difficult.
This opens up a possibility that the bug is more common than we can
confirm, because affected devices often will work properly again
after a reset. A procedure most users are likely to try out before
reporting a bug.
Unconditionally rewriting the destination address if the first digit
of the received packet is 0, is considered an acceptable compromise
since we already have to inspect this digit. The simplification will
cause unnecessary rewrites if the real address starts with 0, but this
is still better than adding additional tests for this particular case.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-04-18 20:57:10 +08:00
|
|
|
fix_dest:
|
2013-04-18 20:57:09 +08:00
|
|
|
memcpy(eth_hdr(skb)->h_dest, dev->net->dev_addr, ETH_ALEN);
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* very simplistic detection of IPv4 or IPv6 headers */
|
|
|
|
static bool possibly_iphdr(const char *data)
|
|
|
|
{
|
|
|
|
return (data[0] & 0xd0) == 0x40;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* disallow addresses which may be confused with IP headers */
|
|
|
|
static int qmi_wwan_mac_addr(struct net_device *dev, void *p)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
struct sockaddr *addr = p;
|
|
|
|
|
|
|
|
ret = eth_prepare_mac_addr_change(dev, p);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
if (possibly_iphdr(addr->sa_data))
|
|
|
|
return -EADDRNOTAVAIL;
|
|
|
|
eth_commit_mac_addr_change(dev, p);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct net_device_ops qmi_wwan_netdev_ops = {
|
|
|
|
.ndo_open = usbnet_open,
|
|
|
|
.ndo_stop = usbnet_stop,
|
|
|
|
.ndo_start_xmit = usbnet_start_xmit,
|
|
|
|
.ndo_tx_timeout = usbnet_tx_timeout,
|
|
|
|
.ndo_change_mtu = usbnet_change_mtu,
|
|
|
|
.ndo_set_mac_address = qmi_wwan_mac_addr,
|
|
|
|
.ndo_validate_addr = eth_validate_addr,
|
|
|
|
};
|
|
|
|
|
2013-09-25 17:21:26 +08:00
|
|
|
/* using a counter to merge subdriver requests with our own into a
|
|
|
|
* combined state
|
|
|
|
*/
|
2012-06-19 08:42:00 +08:00
|
|
|
static int qmi_wwan_manage_power(struct usbnet *dev, int on)
|
|
|
|
{
|
|
|
|
struct qmi_wwan_state *info = (void *)&dev->data;
|
2013-11-01 21:18:53 +08:00
|
|
|
int rv;
|
2012-06-19 08:42:00 +08:00
|
|
|
|
2013-09-25 17:21:26 +08:00
|
|
|
dev_dbg(&dev->intf->dev, "%s() pmcount=%d, on=%d\n", __func__,
|
|
|
|
atomic_read(&info->pmcount), on);
|
2012-06-19 08:42:00 +08:00
|
|
|
|
2013-09-25 17:21:26 +08:00
|
|
|
if ((on && atomic_add_return(1, &info->pmcount) == 1) ||
|
|
|
|
(!on && atomic_dec_and_test(&info->pmcount))) {
|
|
|
|
/* need autopm_get/put here to ensure the usbcore sees
|
|
|
|
* the new value
|
|
|
|
*/
|
2012-06-19 08:42:00 +08:00
|
|
|
rv = usb_autopm_get_interface(dev->intf);
|
|
|
|
dev->intf->needs_remote_wakeup = on;
|
2013-11-01 21:18:53 +08:00
|
|
|
if (!rv)
|
|
|
|
usb_autopm_put_interface(dev->intf);
|
2012-06-19 08:42:00 +08:00
|
|
|
}
|
2013-11-01 21:18:53 +08:00
|
|
|
return 0;
|
2012-06-19 08:42:00 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int qmi_wwan_cdc_wdm_manage_power(struct usb_interface *intf, int on)
|
|
|
|
{
|
|
|
|
struct usbnet *dev = usb_get_intfdata(intf);
|
2012-06-29 08:37:00 +08:00
|
|
|
|
|
|
|
/* can be called while disconnecting */
|
|
|
|
if (!dev)
|
|
|
|
return 0;
|
2012-06-19 08:42:00 +08:00
|
|
|
return qmi_wwan_manage_power(dev, on);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* collect all three endpoints and register subdriver */
|
|
|
|
static int qmi_wwan_register_subdriver(struct usbnet *dev)
|
|
|
|
{
|
|
|
|
int rv;
|
|
|
|
struct usb_driver *subdriver = NULL;
|
|
|
|
struct qmi_wwan_state *info = (void *)&dev->data;
|
|
|
|
|
|
|
|
/* collect bulk endpoints */
|
|
|
|
rv = usbnet_get_endpoints(dev, info->data);
|
|
|
|
if (rv < 0)
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
/* update status endpoint if separate control interface */
|
|
|
|
if (info->control != info->data)
|
|
|
|
dev->status = &info->control->cur_altsetting->endpoint[0];
|
|
|
|
|
|
|
|
/* require interrupt endpoint for subdriver */
|
|
|
|
if (!dev->status) {
|
|
|
|
rv = -EINVAL;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* for subdriver power management */
|
|
|
|
atomic_set(&info->pmcount, 0);
|
|
|
|
|
|
|
|
/* register subdriver */
|
2013-09-25 17:21:26 +08:00
|
|
|
subdriver = usb_cdc_wdm_register(info->control, &dev->status->desc,
|
|
|
|
4096, &qmi_wwan_cdc_wdm_manage_power);
|
2012-06-19 08:42:00 +08:00
|
|
|
if (IS_ERR(subdriver)) {
|
|
|
|
dev_err(&info->control->dev, "subdriver registration failed\n");
|
|
|
|
rv = PTR_ERR(subdriver);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* prevent usbnet from using status endpoint */
|
|
|
|
dev->status = NULL;
|
|
|
|
|
|
|
|
/* save subdriver struct for suspend/resume wrappers */
|
|
|
|
info->subdriver = subdriver;
|
|
|
|
|
|
|
|
err:
|
|
|
|
return rv;
|
|
|
|
}
|
|
|
|
|
2015-12-04 02:24:18 +08:00
|
|
|
/* Send CDC SetControlLineState request, setting or clearing the DTR.
|
|
|
|
* "Required for Autoconnect and 9x30 to wake up" according to the
|
|
|
|
* GobiNet driver. The requirement has been verified on an MDM9230
|
|
|
|
* based Sierra Wireless MC7455
|
|
|
|
*/
|
|
|
|
static int qmi_wwan_change_dtr(struct usbnet *dev, bool on)
|
|
|
|
{
|
|
|
|
u8 intf = dev->intf->cur_altsetting->desc.bInterfaceNumber;
|
|
|
|
|
|
|
|
return usbnet_write_cmd(dev, USB_CDC_REQ_SET_CONTROL_LINE_STATE,
|
|
|
|
USB_DIR_OUT | USB_TYPE_CLASS | USB_RECIP_INTERFACE,
|
|
|
|
on ? 0x01 : 0x00, intf, NULL, 0);
|
|
|
|
}
|
|
|
|
|
2012-01-19 23:37:22 +08:00
|
|
|
static int qmi_wwan_bind(struct usbnet *dev, struct usb_interface *intf)
|
|
|
|
{
|
|
|
|
int status = -1;
|
|
|
|
u8 *buf = intf->cur_altsetting->extra;
|
|
|
|
int len = intf->cur_altsetting->extralen;
|
|
|
|
struct usb_interface_descriptor *desc = &intf->cur_altsetting->desc;
|
2015-09-07 22:05:41 +08:00
|
|
|
struct usb_cdc_union_desc *cdc_union;
|
|
|
|
struct usb_cdc_ether_desc *cdc_ether;
|
2012-06-19 08:42:01 +08:00
|
|
|
struct usb_driver *driver = driver_of(intf);
|
2012-06-19 08:41:59 +08:00
|
|
|
struct qmi_wwan_state *info = (void *)&dev->data;
|
2015-09-07 22:05:41 +08:00
|
|
|
struct usb_cdc_parsed_header hdr;
|
2012-06-19 08:41:59 +08:00
|
|
|
|
2013-09-25 17:21:26 +08:00
|
|
|
BUILD_BUG_ON((sizeof(((struct usbnet *)0)->data) <
|
|
|
|
sizeof(struct qmi_wwan_state)));
|
2012-03-09 19:35:05 +08:00
|
|
|
|
2013-03-13 10:25:17 +08:00
|
|
|
/* set up initial state */
|
|
|
|
info->control = intf;
|
|
|
|
info->data = intf;
|
2012-01-19 23:37:22 +08:00
|
|
|
|
2012-09-07 15:36:07 +08:00
|
|
|
/* and a number of CDC descriptors */
|
2015-09-07 22:05:41 +08:00
|
|
|
cdc_parse_cdc_header(&hdr, intf, buf, len);
|
|
|
|
cdc_union = hdr.usb_cdc_union_desc;
|
|
|
|
cdc_ether = hdr.usb_cdc_ether_desc;
|
2012-01-19 23:37:22 +08:00
|
|
|
|
2013-03-13 10:25:17 +08:00
|
|
|
/* Use separate control and data interfaces if we found a CDC Union */
|
|
|
|
if (cdc_union) {
|
2013-09-25 17:21:26 +08:00
|
|
|
info->data = usb_ifnum_to_if(dev->udev,
|
|
|
|
cdc_union->bSlaveInterface0);
|
|
|
|
if (desc->bInterfaceNumber != cdc_union->bMasterInterface0 ||
|
|
|
|
!info->data) {
|
|
|
|
dev_err(&intf->dev,
|
|
|
|
"bogus CDC Union: master=%u, slave=%u\n",
|
|
|
|
cdc_union->bMasterInterface0,
|
|
|
|
cdc_union->bSlaveInterface0);
|
2015-12-17 19:44:04 +08:00
|
|
|
|
|
|
|
/* ignore and continue... */
|
|
|
|
cdc_union = NULL;
|
|
|
|
info->data = intf;
|
2013-03-13 10:25:17 +08:00
|
|
|
}
|
2012-01-19 23:37:22 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* errors aren't fatal - we can live with the dynamic address */
|
|
|
|
if (cdc_ether) {
|
|
|
|
dev->hard_mtu = le16_to_cpu(cdc_ether->wMaxSegmentSize);
|
|
|
|
usbnet_get_ethernet_addr(dev, cdc_ether->iMACAddress);
|
|
|
|
}
|
|
|
|
|
2012-06-19 08:42:01 +08:00
|
|
|
/* claim data interface and set it up */
|
2013-03-13 10:25:17 +08:00
|
|
|
if (info->control != info->data) {
|
|
|
|
status = usb_driver_claim_interface(driver, info->data, dev);
|
|
|
|
if (status < 0)
|
|
|
|
goto err;
|
|
|
|
}
|
2012-01-19 23:37:22 +08:00
|
|
|
|
2012-06-19 08:42:01 +08:00
|
|
|
status = qmi_wwan_register_subdriver(dev);
|
2012-09-07 15:36:07 +08:00
|
|
|
if (status < 0 && info->control != info->data) {
|
2012-06-19 08:42:01 +08:00
|
|
|
usb_set_intfdata(info->data, NULL);
|
|
|
|
usb_driver_release_interface(driver, info->data);
|
|
|
|
}
|
2012-01-19 23:37:22 +08:00
|
|
|
|
2015-12-04 02:24:18 +08:00
|
|
|
/* disabling remote wakeup on MDM9x30 devices has the same
|
|
|
|
* effect as clearing DTR. The device will not respond to QMI
|
|
|
|
* requests until we set DTR again. This is similar to a
|
|
|
|
* QMI_CTL SYNC request, clearing a lot of firmware state
|
|
|
|
* including the client ID allocations.
|
|
|
|
*
|
|
|
|
* Our usage model allows a session to span multiple
|
|
|
|
* open/close events, so we must prevent the firmware from
|
|
|
|
* clearing out state the clients might need.
|
|
|
|
*
|
|
|
|
* MDM9x30 is the first QMI chipset with USB3 support. Abuse
|
|
|
|
* this fact to enable the quirk.
|
|
|
|
*/
|
|
|
|
if (le16_to_cpu(dev->udev->descriptor.bcdUSB) >= 0x0201) {
|
|
|
|
qmi_wwan_manage_power(dev, 1);
|
|
|
|
qmi_wwan_change_dtr(dev, true);
|
|
|
|
}
|
|
|
|
|
2015-01-02 23:21:45 +08:00
|
|
|
/* Never use the same address on both ends of the link, even if the
|
|
|
|
* buggy firmware told us to. Or, if device is assigned the well-known
|
|
|
|
* buggy firmware MAC address, replace it with a random address,
|
2013-04-18 20:57:11 +08:00
|
|
|
*/
|
2015-01-02 23:21:45 +08:00
|
|
|
if (ether_addr_equal(dev->net->dev_addr, default_modem_addr) ||
|
|
|
|
ether_addr_equal(dev->net->dev_addr, buggy_fw_addr))
|
2013-04-18 20:57:11 +08:00
|
|
|
eth_hw_addr_random(dev->net);
|
|
|
|
|
2013-04-18 20:57:09 +08:00
|
|
|
/* make MAC addr easily distinguishable from an IP header */
|
|
|
|
if (possibly_iphdr(dev->net->dev_addr)) {
|
|
|
|
dev->net->dev_addr[0] |= 0x02; /* set local assignment bit */
|
|
|
|
dev->net->dev_addr[0] &= 0xbf; /* clear "IP" bit */
|
|
|
|
}
|
|
|
|
dev->net->netdev_ops = &qmi_wwan_netdev_ops;
|
net: qmi_wwan: support "raw IP" mode
QMI wwan devices have traditionally emulated ethernet devices
by default. But they have always had the capability of operating
without any L2 header at all, transmitting and receiving "raw"
IP packets over the USB link. This firmware feature used to be
configurable through the QMI management protocol.
Traditionally there was no way to verify the firmware mode
without attempting to change it. And the firmware would often
disallow changes anyway, i.e. due to a session already being
established. In some cases, this could be a hidden firmware
internal session, completely outside host control. For these
reasons, sticking with the "well known" default mode was safest.
But newer generations of QMI hardware and firmware have moved
towards defaulting to "raw IP" mode instead, followed by an
increasing number of bugs in the already buggy "802.3" firmware
implementation. At the same time, the QMI management protocol
gained the ability to detect the current mode. This has enabled
the userspace QMI management application to verify the current
firmware mode without trying to modify it.
Following this development, the latest QMI hardware and firmware
(the MDM9x30 generation) has dropped support for "802.3" mode
entirely. Support for "raw IP" framing in the driver is therefore
necessary for these devices, and to a certain degree to work
around problems with the previous generation,
This patch adds support for "raw IP" framing for QMI devices,
changing the netdev from an ethernet device to an ARPHRD_NONE
p-t-p device when "raw IP" framing is enabled.
The firmware setup is fully delegated to the QMI userspace
management application, through simple tunneling of the QMI
protocol. The driver will therefore not know which mode has been
"negotiated" between firmware and userspace. Allowing userspace
to inform the driver of the result through a sysfs switch is
considered a better alternative than to change the well established
clean delegation of firmware management to userspace.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2015-12-04 02:24:21 +08:00
|
|
|
dev->net->sysfs_groups[0] = &qmi_wwan_sysfs_attr_group;
|
2012-01-19 23:37:22 +08:00
|
|
|
err:
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2012-06-19 08:42:01 +08:00
|
|
|
static void qmi_wwan_unbind(struct usbnet *dev, struct usb_interface *intf)
|
2012-03-09 19:35:05 +08:00
|
|
|
{
|
2012-06-19 08:41:59 +08:00
|
|
|
struct qmi_wwan_state *info = (void *)&dev->data;
|
2012-06-19 08:42:01 +08:00
|
|
|
struct usb_driver *driver = driver_of(intf);
|
|
|
|
struct usb_interface *other;
|
2012-03-09 19:35:05 +08:00
|
|
|
|
2012-06-19 08:41:59 +08:00
|
|
|
if (info->subdriver && info->subdriver->disconnect)
|
2012-06-19 08:42:01 +08:00
|
|
|
info->subdriver->disconnect(info->control);
|
|
|
|
|
2015-12-04 02:24:18 +08:00
|
|
|
/* disable MDM9x30 quirk */
|
|
|
|
if (le16_to_cpu(dev->udev->descriptor.bcdUSB) >= 0x0201) {
|
|
|
|
qmi_wwan_change_dtr(dev, false);
|
|
|
|
qmi_wwan_manage_power(dev, 0);
|
|
|
|
}
|
|
|
|
|
2012-06-19 08:42:01 +08:00
|
|
|
/* allow user to unbind using either control or data */
|
|
|
|
if (intf == info->control)
|
|
|
|
other = info->data;
|
|
|
|
else
|
|
|
|
other = info->control;
|
|
|
|
|
|
|
|
/* only if not shared */
|
|
|
|
if (other && intf != other) {
|
|
|
|
usb_set_intfdata(other, NULL);
|
|
|
|
usb_driver_release_interface(driver, other);
|
|
|
|
}
|
2012-03-09 19:35:05 +08:00
|
|
|
|
2012-06-19 08:41:59 +08:00
|
|
|
info->subdriver = NULL;
|
2012-06-19 08:42:01 +08:00
|
|
|
info->data = NULL;
|
|
|
|
info->control = NULL;
|
2012-03-09 19:35:05 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/* suspend/resume wrappers calling both usbnet and the cdc-wdm
|
|
|
|
* subdriver if present.
|
|
|
|
*
|
|
|
|
* NOTE: cdc-wdm also supports pre/post_reset, but we cannot provide
|
|
|
|
* wrappers for those without adding usbnet reset support first.
|
|
|
|
*/
|
|
|
|
static int qmi_wwan_suspend(struct usb_interface *intf, pm_message_t message)
|
|
|
|
{
|
|
|
|
struct usbnet *dev = usb_get_intfdata(intf);
|
2012-06-19 08:41:59 +08:00
|
|
|
struct qmi_wwan_state *info = (void *)&dev->data;
|
2012-03-09 19:35:05 +08:00
|
|
|
int ret;
|
|
|
|
|
2013-09-25 17:21:26 +08:00
|
|
|
/* Both usbnet_suspend() and subdriver->suspend() MUST return 0
|
2013-03-15 12:08:57 +08:00
|
|
|
* in system sleep context, otherwise, the resume callback has
|
|
|
|
* to recover device from previous suspend failure.
|
|
|
|
*/
|
2012-03-09 19:35:05 +08:00
|
|
|
ret = usbnet_suspend(intf, message);
|
|
|
|
if (ret < 0)
|
|
|
|
goto err;
|
|
|
|
|
2013-09-25 17:21:26 +08:00
|
|
|
if (intf == info->control && info->subdriver &&
|
|
|
|
info->subdriver->suspend)
|
2012-06-19 08:41:59 +08:00
|
|
|
ret = info->subdriver->suspend(intf, message);
|
2012-03-09 19:35:05 +08:00
|
|
|
if (ret < 0)
|
|
|
|
usbnet_resume(intf);
|
|
|
|
err:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int qmi_wwan_resume(struct usb_interface *intf)
|
|
|
|
{
|
|
|
|
struct usbnet *dev = usb_get_intfdata(intf);
|
2012-06-19 08:41:59 +08:00
|
|
|
struct qmi_wwan_state *info = (void *)&dev->data;
|
2012-03-09 19:35:05 +08:00
|
|
|
int ret = 0;
|
2013-09-25 17:21:26 +08:00
|
|
|
bool callsub = (intf == info->control && info->subdriver &&
|
|
|
|
info->subdriver->resume);
|
2012-03-09 19:35:05 +08:00
|
|
|
|
2012-09-13 04:44:35 +08:00
|
|
|
if (callsub)
|
2012-06-19 08:41:59 +08:00
|
|
|
ret = info->subdriver->resume(intf);
|
2012-03-09 19:35:05 +08:00
|
|
|
if (ret < 0)
|
|
|
|
goto err;
|
|
|
|
ret = usbnet_resume(intf);
|
2013-11-01 21:18:54 +08:00
|
|
|
if (ret < 0 && callsub)
|
2012-06-19 08:41:59 +08:00
|
|
|
info->subdriver->suspend(intf, PMSG_SUSPEND);
|
2012-03-09 19:35:05 +08:00
|
|
|
err:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-01-19 23:37:22 +08:00
|
|
|
static const struct driver_info qmi_wwan_info = {
|
2012-06-19 08:42:02 +08:00
|
|
|
.description = "WWAN/QMI device",
|
2012-01-19 23:37:22 +08:00
|
|
|
.flags = FLAG_WWAN,
|
|
|
|
.bind = qmi_wwan_bind,
|
2012-06-19 08:42:01 +08:00
|
|
|
.unbind = qmi_wwan_unbind,
|
2012-01-19 23:37:22 +08:00
|
|
|
.manage_power = qmi_wwan_manage_power,
|
2013-04-18 20:57:09 +08:00
|
|
|
.rx_fixup = qmi_wwan_rx_fixup,
|
2012-01-19 23:37:22 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
#define HUAWEI_VENDOR_ID 0x12D1
|
2012-06-21 10:45:58 +08:00
|
|
|
|
2012-08-12 17:16:30 +08:00
|
|
|
/* map QMI/wwan function by a fixed interface number */
|
|
|
|
#define QMI_FIXED_INTF(vend, prod, num) \
|
|
|
|
USB_DEVICE_INTERFACE_NUMBER(vend, prod, num), \
|
2012-09-07 15:36:07 +08:00
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info
|
2012-08-12 17:16:30 +08:00
|
|
|
|
2012-06-21 10:45:58 +08:00
|
|
|
/* Gobi 1000 QMI/wwan interface number is 3 according to qcserial */
|
|
|
|
#define QMI_GOBI1K_DEVICE(vend, prod) \
|
2012-08-12 17:16:30 +08:00
|
|
|
QMI_FIXED_INTF(vend, prod, 3)
|
2012-06-21 10:45:58 +08:00
|
|
|
|
2012-08-12 17:16:30 +08:00
|
|
|
/* Gobi 2000/3000 QMI/wwan interface number is 0 according to qcserial */
|
2012-03-09 19:35:06 +08:00
|
|
|
#define QMI_GOBI_DEVICE(vend, prod) \
|
2012-08-12 17:16:30 +08:00
|
|
|
QMI_FIXED_INTF(vend, prod, 0)
|
2012-01-19 23:37:22 +08:00
|
|
|
|
|
|
|
static const struct usb_device_id products[] = {
|
2012-08-12 17:16:30 +08:00
|
|
|
/* 1. CDC ECM like devices match on the control interface */
|
2012-03-09 19:35:05 +08:00
|
|
|
{ /* Huawei E392, E398 and possibly others sharing both device id and more... */
|
2012-08-12 17:16:32 +08:00
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 9),
|
2012-03-09 19:35:05 +08:00
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
2012-05-19 15:20:31 +08:00
|
|
|
{ /* Vodafone/Huawei K5005 (12d1:14c8) and similar modems */
|
2012-08-12 17:16:32 +08:00
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 57),
|
2012-05-19 15:20:31 +08:00
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
2013-02-06 13:22:08 +08:00
|
|
|
{ /* HUAWEI_INTERFACE_NDIS_CONTROL_QUALCOMM */
|
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 0x01, 0x69),
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
2012-08-12 17:16:30 +08:00
|
|
|
|
|
|
|
/* 2. Combined interface devices matching on class+protocol */
|
2012-09-19 18:03:36 +08:00
|
|
|
{ /* Huawei E367 and possibly others in "Windows mode" */
|
2012-09-20 05:18:05 +08:00
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 7),
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
2012-08-12 17:16:30 +08:00
|
|
|
{ /* Huawei E392, E398 and possibly others in "Windows mode" */
|
2012-08-12 17:16:32 +08:00
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 17),
|
2012-09-07 15:36:07 +08:00
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
2012-03-09 19:35:05 +08:00
|
|
|
},
|
2013-02-06 13:22:08 +08:00
|
|
|
{ /* HUAWEI_NDIS_SINGLE_INTERFACE_VDF */
|
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 0x01, 0x37),
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
|
|
|
{ /* HUAWEI_INTERFACE_NDIS_HW_QUALCOMM */
|
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 0x01, 0x67),
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
2012-09-19 18:03:36 +08:00
|
|
|
{ /* Pantech UML290, P4200 and more */
|
2012-09-20 05:18:05 +08:00
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC, 0xf0, 0xff),
|
2012-09-07 15:36:07 +08:00
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
2012-03-09 19:35:06 +08:00
|
|
|
},
|
2012-08-15 11:42:57 +08:00
|
|
|
{ /* Pantech UML290 - newer firmware */
|
2012-09-20 05:18:05 +08:00
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC, 0xf1, 0xff),
|
2012-09-07 15:36:07 +08:00
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
2012-08-15 11:42:57 +08:00
|
|
|
},
|
2012-10-24 20:10:34 +08:00
|
|
|
{ /* Novatel USB551L and MC551 */
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(0x1410, 0xb001,
|
|
|
|
USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET,
|
|
|
|
USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
|
|
|
{ /* Novatel E362 */
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(0x1410, 0x9010,
|
|
|
|
USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET,
|
|
|
|
USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
2014-03-28 19:07:18 +08:00
|
|
|
{ /* Novatel Expedite E371 */
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(0x1410, 0x9011,
|
|
|
|
USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET,
|
|
|
|
USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
2012-12-17 16:17:41 +08:00
|
|
|
{ /* Dell Wireless 5800 (Novatel E362) */
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(0x413C, 0x8195,
|
|
|
|
USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET,
|
|
|
|
USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
|
|
|
{ /* Dell Wireless 5800 V2 (Novatel E362) */
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(0x413C, 0x8196,
|
|
|
|
USB_CLASS_COMM,
|
2013-02-19 01:25:09 +08:00
|
|
|
USB_CDC_SUBCLASS_ETHERNET,
|
|
|
|
USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
2013-05-06 19:17:37 +08:00
|
|
|
{ /* Dell Wireless 5804 (Novatel E371) */
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(0x413C, 0x819b,
|
|
|
|
USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET,
|
|
|
|
USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
2013-02-19 01:25:09 +08:00
|
|
|
{ /* ADU960S */
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(0x16d5, 0x650a,
|
|
|
|
USB_CLASS_COMM,
|
2012-12-17 16:17:41 +08:00
|
|
|
USB_CDC_SUBCLASS_ETHERNET,
|
|
|
|
USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
2015-11-01 08:34:50 +08:00
|
|
|
{ /* HP lt4112 LTE/HSPA+ Gobi 4G Module (Huawei me906e) */
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(0x03f0, 0x581d, USB_CLASS_VENDOR_SPEC, 1, 7),
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
2012-06-21 10:45:58 +08:00
|
|
|
|
2012-08-12 17:16:30 +08:00
|
|
|
/* 3. Combined interface devices matching on interface number */
|
2013-02-12 10:42:50 +08:00
|
|
|
{QMI_FIXED_INTF(0x0408, 0xea42, 4)}, /* Yota / Megafon M100-1 */
|
2016-02-12 23:42:14 +08:00
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x6001, 3)}, /* 4G LTE usb-modem U901 */
|
2013-09-10 21:06:20 +08:00
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x7000, 0)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x7001, 1)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x7002, 1)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x7101, 1)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x7101, 2)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x7101, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x7102, 1)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x7102, 2)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x7102, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x8000, 7)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x8001, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9000, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9003, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9005, 2)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x900a, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x900b, 2)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x900c, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x900c, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x900c, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x900d, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x900f, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x900f, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x900f, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9010, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9010, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9011, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9011, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9021, 1)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9022, 2)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9025, 4)}, /* Alcatel-sbell ASB TL131 TDD LTE (China Mobile) */
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9026, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x902e, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9031, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9032, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9033, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9033, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9033, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9033, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9034, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9034, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9034, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9034, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9034, 7)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9035, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9036, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9037, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9038, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x903b, 7)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x903c, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x903d, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x903e, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9043, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9046, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9046, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9046, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9047, 2)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9047, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9047, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9048, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9048, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9048, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9048, 7)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9048, 8)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x904c, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x904c, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x904c, 7)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x904c, 8)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9050, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9052, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9053, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9053, 7)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9054, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9054, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9055, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9055, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9055, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9055, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9055, 7)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9056, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9062, 2)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9062, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9062, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9062, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9062, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9062, 7)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9062, 8)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9062, 9)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9064, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9065, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9065, 7)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9066, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9066, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9067, 1)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9068, 2)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9068, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9068, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9068, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9068, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9068, 7)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9069, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9069, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9069, 7)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9069, 8)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9070, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9070, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9075, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9076, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9076, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9076, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9076, 7)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9076, 8)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9077, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9077, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9077, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9077, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9078, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9079, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9079, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9079, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9079, 7)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9079, 8)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9080, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9080, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9080, 7)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9080, 8)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9083, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9084, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x920d, 0)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x920d, 5)},
|
2014-07-17 19:33:51 +08:00
|
|
|
{QMI_FIXED_INTF(0x0846, 0x68a2, 8)},
|
2012-11-25 14:03:59 +08:00
|
|
|
{QMI_FIXED_INTF(0x12d1, 0x140c, 1)}, /* Huawei E173 */
|
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
|
|
|
{QMI_FIXED_INTF(0x12d1, 0x14ac, 1)}, /* Huawei E1820 */
|
2014-04-26 01:00:33 +08:00
|
|
|
{QMI_FIXED_INTF(0x16d8, 0x6003, 0)}, /* CMOTech 6003 */
|
|
|
|
{QMI_FIXED_INTF(0x16d8, 0x6007, 0)}, /* CMOTech CHE-628S */
|
|
|
|
{QMI_FIXED_INTF(0x16d8, 0x6008, 0)}, /* CMOTech CMU-301 */
|
|
|
|
{QMI_FIXED_INTF(0x16d8, 0x6280, 0)}, /* CMOTech CHU-628 */
|
|
|
|
{QMI_FIXED_INTF(0x16d8, 0x7001, 0)}, /* CMOTech CHU-720S */
|
|
|
|
{QMI_FIXED_INTF(0x16d8, 0x7002, 0)}, /* CMOTech 7002 */
|
|
|
|
{QMI_FIXED_INTF(0x16d8, 0x7003, 4)}, /* CMOTech CHU-629K */
|
|
|
|
{QMI_FIXED_INTF(0x16d8, 0x7004, 3)}, /* CMOTech 7004 */
|
|
|
|
{QMI_FIXED_INTF(0x16d8, 0x7006, 5)}, /* CMOTech CGU-629 */
|
|
|
|
{QMI_FIXED_INTF(0x16d8, 0x700a, 4)}, /* CMOTech CHU-629S */
|
|
|
|
{QMI_FIXED_INTF(0x16d8, 0x7211, 0)}, /* CMOTech CHU-720I */
|
|
|
|
{QMI_FIXED_INTF(0x16d8, 0x7212, 0)}, /* CMOTech 7212 */
|
|
|
|
{QMI_FIXED_INTF(0x16d8, 0x7213, 0)}, /* CMOTech 7213 */
|
|
|
|
{QMI_FIXED_INTF(0x16d8, 0x7251, 1)}, /* CMOTech 7251 */
|
|
|
|
{QMI_FIXED_INTF(0x16d8, 0x7252, 1)}, /* CMOTech 7252 */
|
|
|
|
{QMI_FIXED_INTF(0x16d8, 0x7253, 1)}, /* CMOTech 7253 */
|
net: qmi_wwan: adding more ZTE devices
Analyzed a few Windows driver description files, supporting
this long list of devices:
%ztewwan.DeviceDesc0002% = ztewwan.ndi, USB\VID_19D2&PID_0002&MI_01
%ztewwan.DeviceDesc0012% = ztewwan.ndi, USB\VID_19D2&PID_0012&MI_01
%ztewwan.DeviceDesc0017% = ztewwan.ndi, USB\VID_19D2&PID_0017&MI_03
%ztewwan.DeviceDesc0021% = ztewwan.ndi, USB\VID_19D2&PID_0021&MI_04
%ztewwan.DeviceDesc0025% = ztewwan.ndi, USB\VID_19D2&PID_0025&MI_01
%ztewwan.DeviceDesc0031% = ztewwan.ndi, USB\VID_19D2&PID_0031&MI_04
%ztewwan.DeviceDesc0042% = ztewwan.ndi, USB\VID_19D2&PID_0042&MI_04
%ztewwan.DeviceDesc0049% = ztewwan.ndi, USB\VID_19D2&PID_0049&MI_05
%ztewwan.DeviceDesc0052% = ztewwan.ndi, USB\VID_19D2&PID_0052&MI_04
%ztewwan.DeviceDesc0055% = ztewwan.ndi, USB\VID_19D2&PID_0055&MI_01
%ztewwan.DeviceDesc0058% = ztewwan.ndi, USB\VID_19D2&PID_0058&MI_04
%ztewwan.DeviceDesc0063% = ztewwan.ndi, USB\VID_19D2&PID_0063&MI_04
%ztewwan.DeviceDesc2002% = ztewwan.ndi, USB\VID_19D2&PID_2002&MI_04
%ztewwan.DeviceDesc0104% = ztewwan.ndi, USB\VID_19D2&PID_0104&MI_04
%ztewwan.DeviceDesc0113% = ztewwan.ndi, USB\VID_19D2&PID_0113&MI_05
%ztewwan.DeviceDesc0118% = ztewwan.ndi, USB\VID_19D2&PID_0118&MI_05
%ztewwan.DeviceDesc0121% = ztewwan.ndi, USB\VID_19D2&PID_0121&MI_05
%ztewwan.DeviceDesc0123% = ztewwan.ndi, USB\VID_19D2&PID_0123&MI_04
%ztewwan.DeviceDesc0124% = ztewwan.ndi, USB\VID_19D2&PID_0124&MI_05
%ztewwan.DeviceDesc0125% = ztewwan.ndi, USB\VID_19D2&PID_0125&MI_06
%ztewwan.DeviceDesc0126% = ztewwan.ndi, USB\VID_19D2&PID_0126&MI_05
%ztewwan.DeviceDesc1008% = ztewwan.ndi, USB\VID_19D2&PID_1008&MI_04
%ztewwan.DeviceDesc1010% = ztewwan.ndi, USB\VID_19D2&PID_1010&MI_04
%ztewwan.DeviceDesc1012% = ztewwan.ndi, USB\VID_19D2&PID_1012&MI_04
%ztewwan.DeviceDesc1402% = ztewwan.ndi, USB\VID_19D2&PID_1402&MI_02
%ztewwan.DeviceDesc0157% = ztewwan.ndi, USB\VID_19D2&PID_0157&MI_05
%ztewwan.DeviceDesc0158% = ztewwan.ndi, USB\VID_19D2&PID_0158&MI_03
%ztewwan.DeviceDesc1401% = ztewwan.ndi, USB\VID_19D2&PID_1401&MI_02
%ztewwan.DeviceDesc0130% = ztewwan.ndi, USB\VID_19D2&PID_0130&MI_01
%ztewwan.DeviceDesc0133% = ztewwan.ndi, USB\VID_19D2&PID_0133&MI_03
%ztewwan.DeviceDesc0176% = ztewwan.ndi, USB\VID_19D2&PID_0176&MI_03
%ztewwan.DeviceDesc0178% = ztewwan.ndi, USB\VID_19D2&PID_0178&MI_03
%ztewwan.DeviceDesc0168% = ztewwan.ndi, USB\VID_19D2&PID_0168&MI_04
;EuFi890
%ztewwan.DeviceDesc0191% = ztewwan.ndi, USB\VID_19D2&PID_0191&MI_04
;AL621
%ztewwan.DeviceDesc0167% = ztewwan.ndi, USB\VID_19D2&PID_0167&MI_04
;MF821
%ztewwan.DeviceDesc0199% = ztewwan.ndi, USB\VID_19D2&PID_0199&MI_01
%ztewwan.DeviceDesc0200% = ztewwan.ndi, USB\VID_19D2&PID_0200&MI_01
%ztewwan.DeviceDesc0257% = ztewwan.ndi, USB\VID_19D2&PID_0257&MI_03
;MF821V
%ztewwan.DeviceDesc1018% = ztewwan.ndi, USB\VID_19D2&PID_1018&MI_03
;MF91
%ztewwan.DeviceDesc1426% = ztewwan.ndi, USB\VID_19D2&PID_1426&MI_02
;0141
%ztewwan.DeviceDesc1247% = ztewwan.ndi, USB\VID_19D2&PID_1247&MI_04
%ztewwan.DeviceDesc1425% = ztewwan.ndi, USB\VID_19D2&PID_1425&MI_02
%ztewwan.DeviceDesc1424% = ztewwan.ndi, USB\VID_19D2&PID_1424&MI_02
%ztewwan.DeviceDesc1252% = ztewwan.ndi, USB\VID_19D2&PID_1252&MI_04
%ztewwan.DeviceDesc1254% = ztewwan.ndi, USB\VID_19D2&PID_1254&MI_04
%ztewwan.DeviceDesc1255A% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_03
%ztewwan.DeviceDesc1255B% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_04
%ztewwan.DeviceDesc1256% = ztewwan.ndi, USB\VID_19D2&PID_1256&MI_04
%ztewwan.DeviceDesc1245% = ztewwanCombB.ndi, USB\VID_19D2&PID_1245&MI_04
%ztewwan.DeviceDesc1021% = ztewwan.ndi, USB\VID_19D2&PID_1021&MI_02
Adding the ones we were missing.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-10-18 13:11:29 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0002, 1)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0012, 1)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0017, 3)},
|
2013-06-29 21:39:19 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0019, 3)}, /* ONDA MT689DC */
|
net: qmi_wwan: adding more ZTE devices
Analyzed a few Windows driver description files, supporting
this long list of devices:
%ztewwan.DeviceDesc0002% = ztewwan.ndi, USB\VID_19D2&PID_0002&MI_01
%ztewwan.DeviceDesc0012% = ztewwan.ndi, USB\VID_19D2&PID_0012&MI_01
%ztewwan.DeviceDesc0017% = ztewwan.ndi, USB\VID_19D2&PID_0017&MI_03
%ztewwan.DeviceDesc0021% = ztewwan.ndi, USB\VID_19D2&PID_0021&MI_04
%ztewwan.DeviceDesc0025% = ztewwan.ndi, USB\VID_19D2&PID_0025&MI_01
%ztewwan.DeviceDesc0031% = ztewwan.ndi, USB\VID_19D2&PID_0031&MI_04
%ztewwan.DeviceDesc0042% = ztewwan.ndi, USB\VID_19D2&PID_0042&MI_04
%ztewwan.DeviceDesc0049% = ztewwan.ndi, USB\VID_19D2&PID_0049&MI_05
%ztewwan.DeviceDesc0052% = ztewwan.ndi, USB\VID_19D2&PID_0052&MI_04
%ztewwan.DeviceDesc0055% = ztewwan.ndi, USB\VID_19D2&PID_0055&MI_01
%ztewwan.DeviceDesc0058% = ztewwan.ndi, USB\VID_19D2&PID_0058&MI_04
%ztewwan.DeviceDesc0063% = ztewwan.ndi, USB\VID_19D2&PID_0063&MI_04
%ztewwan.DeviceDesc2002% = ztewwan.ndi, USB\VID_19D2&PID_2002&MI_04
%ztewwan.DeviceDesc0104% = ztewwan.ndi, USB\VID_19D2&PID_0104&MI_04
%ztewwan.DeviceDesc0113% = ztewwan.ndi, USB\VID_19D2&PID_0113&MI_05
%ztewwan.DeviceDesc0118% = ztewwan.ndi, USB\VID_19D2&PID_0118&MI_05
%ztewwan.DeviceDesc0121% = ztewwan.ndi, USB\VID_19D2&PID_0121&MI_05
%ztewwan.DeviceDesc0123% = ztewwan.ndi, USB\VID_19D2&PID_0123&MI_04
%ztewwan.DeviceDesc0124% = ztewwan.ndi, USB\VID_19D2&PID_0124&MI_05
%ztewwan.DeviceDesc0125% = ztewwan.ndi, USB\VID_19D2&PID_0125&MI_06
%ztewwan.DeviceDesc0126% = ztewwan.ndi, USB\VID_19D2&PID_0126&MI_05
%ztewwan.DeviceDesc1008% = ztewwan.ndi, USB\VID_19D2&PID_1008&MI_04
%ztewwan.DeviceDesc1010% = ztewwan.ndi, USB\VID_19D2&PID_1010&MI_04
%ztewwan.DeviceDesc1012% = ztewwan.ndi, USB\VID_19D2&PID_1012&MI_04
%ztewwan.DeviceDesc1402% = ztewwan.ndi, USB\VID_19D2&PID_1402&MI_02
%ztewwan.DeviceDesc0157% = ztewwan.ndi, USB\VID_19D2&PID_0157&MI_05
%ztewwan.DeviceDesc0158% = ztewwan.ndi, USB\VID_19D2&PID_0158&MI_03
%ztewwan.DeviceDesc1401% = ztewwan.ndi, USB\VID_19D2&PID_1401&MI_02
%ztewwan.DeviceDesc0130% = ztewwan.ndi, USB\VID_19D2&PID_0130&MI_01
%ztewwan.DeviceDesc0133% = ztewwan.ndi, USB\VID_19D2&PID_0133&MI_03
%ztewwan.DeviceDesc0176% = ztewwan.ndi, USB\VID_19D2&PID_0176&MI_03
%ztewwan.DeviceDesc0178% = ztewwan.ndi, USB\VID_19D2&PID_0178&MI_03
%ztewwan.DeviceDesc0168% = ztewwan.ndi, USB\VID_19D2&PID_0168&MI_04
;EuFi890
%ztewwan.DeviceDesc0191% = ztewwan.ndi, USB\VID_19D2&PID_0191&MI_04
;AL621
%ztewwan.DeviceDesc0167% = ztewwan.ndi, USB\VID_19D2&PID_0167&MI_04
;MF821
%ztewwan.DeviceDesc0199% = ztewwan.ndi, USB\VID_19D2&PID_0199&MI_01
%ztewwan.DeviceDesc0200% = ztewwan.ndi, USB\VID_19D2&PID_0200&MI_01
%ztewwan.DeviceDesc0257% = ztewwan.ndi, USB\VID_19D2&PID_0257&MI_03
;MF821V
%ztewwan.DeviceDesc1018% = ztewwan.ndi, USB\VID_19D2&PID_1018&MI_03
;MF91
%ztewwan.DeviceDesc1426% = ztewwan.ndi, USB\VID_19D2&PID_1426&MI_02
;0141
%ztewwan.DeviceDesc1247% = ztewwan.ndi, USB\VID_19D2&PID_1247&MI_04
%ztewwan.DeviceDesc1425% = ztewwan.ndi, USB\VID_19D2&PID_1425&MI_02
%ztewwan.DeviceDesc1424% = ztewwan.ndi, USB\VID_19D2&PID_1424&MI_02
%ztewwan.DeviceDesc1252% = ztewwan.ndi, USB\VID_19D2&PID_1252&MI_04
%ztewwan.DeviceDesc1254% = ztewwan.ndi, USB\VID_19D2&PID_1254&MI_04
%ztewwan.DeviceDesc1255A% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_03
%ztewwan.DeviceDesc1255B% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_04
%ztewwan.DeviceDesc1256% = ztewwan.ndi, USB\VID_19D2&PID_1256&MI_04
%ztewwan.DeviceDesc1245% = ztewwanCombB.ndi, USB\VID_19D2&PID_1245&MI_04
%ztewwan.DeviceDesc1021% = ztewwan.ndi, USB\VID_19D2&PID_1021&MI_02
Adding the ones we were missing.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-10-18 13:11:29 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0021, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0025, 1)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0031, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0042, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0049, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0052, 4)},
|
2012-08-12 17:16:30 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0055, 1)}, /* ZTE (Vodafone) K3520-Z */
|
net: qmi_wwan: adding more ZTE devices
Analyzed a few Windows driver description files, supporting
this long list of devices:
%ztewwan.DeviceDesc0002% = ztewwan.ndi, USB\VID_19D2&PID_0002&MI_01
%ztewwan.DeviceDesc0012% = ztewwan.ndi, USB\VID_19D2&PID_0012&MI_01
%ztewwan.DeviceDesc0017% = ztewwan.ndi, USB\VID_19D2&PID_0017&MI_03
%ztewwan.DeviceDesc0021% = ztewwan.ndi, USB\VID_19D2&PID_0021&MI_04
%ztewwan.DeviceDesc0025% = ztewwan.ndi, USB\VID_19D2&PID_0025&MI_01
%ztewwan.DeviceDesc0031% = ztewwan.ndi, USB\VID_19D2&PID_0031&MI_04
%ztewwan.DeviceDesc0042% = ztewwan.ndi, USB\VID_19D2&PID_0042&MI_04
%ztewwan.DeviceDesc0049% = ztewwan.ndi, USB\VID_19D2&PID_0049&MI_05
%ztewwan.DeviceDesc0052% = ztewwan.ndi, USB\VID_19D2&PID_0052&MI_04
%ztewwan.DeviceDesc0055% = ztewwan.ndi, USB\VID_19D2&PID_0055&MI_01
%ztewwan.DeviceDesc0058% = ztewwan.ndi, USB\VID_19D2&PID_0058&MI_04
%ztewwan.DeviceDesc0063% = ztewwan.ndi, USB\VID_19D2&PID_0063&MI_04
%ztewwan.DeviceDesc2002% = ztewwan.ndi, USB\VID_19D2&PID_2002&MI_04
%ztewwan.DeviceDesc0104% = ztewwan.ndi, USB\VID_19D2&PID_0104&MI_04
%ztewwan.DeviceDesc0113% = ztewwan.ndi, USB\VID_19D2&PID_0113&MI_05
%ztewwan.DeviceDesc0118% = ztewwan.ndi, USB\VID_19D2&PID_0118&MI_05
%ztewwan.DeviceDesc0121% = ztewwan.ndi, USB\VID_19D2&PID_0121&MI_05
%ztewwan.DeviceDesc0123% = ztewwan.ndi, USB\VID_19D2&PID_0123&MI_04
%ztewwan.DeviceDesc0124% = ztewwan.ndi, USB\VID_19D2&PID_0124&MI_05
%ztewwan.DeviceDesc0125% = ztewwan.ndi, USB\VID_19D2&PID_0125&MI_06
%ztewwan.DeviceDesc0126% = ztewwan.ndi, USB\VID_19D2&PID_0126&MI_05
%ztewwan.DeviceDesc1008% = ztewwan.ndi, USB\VID_19D2&PID_1008&MI_04
%ztewwan.DeviceDesc1010% = ztewwan.ndi, USB\VID_19D2&PID_1010&MI_04
%ztewwan.DeviceDesc1012% = ztewwan.ndi, USB\VID_19D2&PID_1012&MI_04
%ztewwan.DeviceDesc1402% = ztewwan.ndi, USB\VID_19D2&PID_1402&MI_02
%ztewwan.DeviceDesc0157% = ztewwan.ndi, USB\VID_19D2&PID_0157&MI_05
%ztewwan.DeviceDesc0158% = ztewwan.ndi, USB\VID_19D2&PID_0158&MI_03
%ztewwan.DeviceDesc1401% = ztewwan.ndi, USB\VID_19D2&PID_1401&MI_02
%ztewwan.DeviceDesc0130% = ztewwan.ndi, USB\VID_19D2&PID_0130&MI_01
%ztewwan.DeviceDesc0133% = ztewwan.ndi, USB\VID_19D2&PID_0133&MI_03
%ztewwan.DeviceDesc0176% = ztewwan.ndi, USB\VID_19D2&PID_0176&MI_03
%ztewwan.DeviceDesc0178% = ztewwan.ndi, USB\VID_19D2&PID_0178&MI_03
%ztewwan.DeviceDesc0168% = ztewwan.ndi, USB\VID_19D2&PID_0168&MI_04
;EuFi890
%ztewwan.DeviceDesc0191% = ztewwan.ndi, USB\VID_19D2&PID_0191&MI_04
;AL621
%ztewwan.DeviceDesc0167% = ztewwan.ndi, USB\VID_19D2&PID_0167&MI_04
;MF821
%ztewwan.DeviceDesc0199% = ztewwan.ndi, USB\VID_19D2&PID_0199&MI_01
%ztewwan.DeviceDesc0200% = ztewwan.ndi, USB\VID_19D2&PID_0200&MI_01
%ztewwan.DeviceDesc0257% = ztewwan.ndi, USB\VID_19D2&PID_0257&MI_03
;MF821V
%ztewwan.DeviceDesc1018% = ztewwan.ndi, USB\VID_19D2&PID_1018&MI_03
;MF91
%ztewwan.DeviceDesc1426% = ztewwan.ndi, USB\VID_19D2&PID_1426&MI_02
;0141
%ztewwan.DeviceDesc1247% = ztewwan.ndi, USB\VID_19D2&PID_1247&MI_04
%ztewwan.DeviceDesc1425% = ztewwan.ndi, USB\VID_19D2&PID_1425&MI_02
%ztewwan.DeviceDesc1424% = ztewwan.ndi, USB\VID_19D2&PID_1424&MI_02
%ztewwan.DeviceDesc1252% = ztewwan.ndi, USB\VID_19D2&PID_1252&MI_04
%ztewwan.DeviceDesc1254% = ztewwan.ndi, USB\VID_19D2&PID_1254&MI_04
%ztewwan.DeviceDesc1255A% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_03
%ztewwan.DeviceDesc1255B% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_04
%ztewwan.DeviceDesc1256% = ztewwan.ndi, USB\VID_19D2&PID_1256&MI_04
%ztewwan.DeviceDesc1245% = ztewwanCombB.ndi, USB\VID_19D2&PID_1245&MI_04
%ztewwan.DeviceDesc1021% = ztewwan.ndi, USB\VID_19D2&PID_1021&MI_02
Adding the ones we were missing.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-10-18 13:11:29 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0058, 4)},
|
2012-08-12 17:16:30 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0063, 4)}, /* ZTE (Vodafone) K3565-Z */
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0104, 4)}, /* ZTE (Vodafone) K4505-Z */
|
net: qmi_wwan: adding more ZTE devices
Analyzed a few Windows driver description files, supporting
this long list of devices:
%ztewwan.DeviceDesc0002% = ztewwan.ndi, USB\VID_19D2&PID_0002&MI_01
%ztewwan.DeviceDesc0012% = ztewwan.ndi, USB\VID_19D2&PID_0012&MI_01
%ztewwan.DeviceDesc0017% = ztewwan.ndi, USB\VID_19D2&PID_0017&MI_03
%ztewwan.DeviceDesc0021% = ztewwan.ndi, USB\VID_19D2&PID_0021&MI_04
%ztewwan.DeviceDesc0025% = ztewwan.ndi, USB\VID_19D2&PID_0025&MI_01
%ztewwan.DeviceDesc0031% = ztewwan.ndi, USB\VID_19D2&PID_0031&MI_04
%ztewwan.DeviceDesc0042% = ztewwan.ndi, USB\VID_19D2&PID_0042&MI_04
%ztewwan.DeviceDesc0049% = ztewwan.ndi, USB\VID_19D2&PID_0049&MI_05
%ztewwan.DeviceDesc0052% = ztewwan.ndi, USB\VID_19D2&PID_0052&MI_04
%ztewwan.DeviceDesc0055% = ztewwan.ndi, USB\VID_19D2&PID_0055&MI_01
%ztewwan.DeviceDesc0058% = ztewwan.ndi, USB\VID_19D2&PID_0058&MI_04
%ztewwan.DeviceDesc0063% = ztewwan.ndi, USB\VID_19D2&PID_0063&MI_04
%ztewwan.DeviceDesc2002% = ztewwan.ndi, USB\VID_19D2&PID_2002&MI_04
%ztewwan.DeviceDesc0104% = ztewwan.ndi, USB\VID_19D2&PID_0104&MI_04
%ztewwan.DeviceDesc0113% = ztewwan.ndi, USB\VID_19D2&PID_0113&MI_05
%ztewwan.DeviceDesc0118% = ztewwan.ndi, USB\VID_19D2&PID_0118&MI_05
%ztewwan.DeviceDesc0121% = ztewwan.ndi, USB\VID_19D2&PID_0121&MI_05
%ztewwan.DeviceDesc0123% = ztewwan.ndi, USB\VID_19D2&PID_0123&MI_04
%ztewwan.DeviceDesc0124% = ztewwan.ndi, USB\VID_19D2&PID_0124&MI_05
%ztewwan.DeviceDesc0125% = ztewwan.ndi, USB\VID_19D2&PID_0125&MI_06
%ztewwan.DeviceDesc0126% = ztewwan.ndi, USB\VID_19D2&PID_0126&MI_05
%ztewwan.DeviceDesc1008% = ztewwan.ndi, USB\VID_19D2&PID_1008&MI_04
%ztewwan.DeviceDesc1010% = ztewwan.ndi, USB\VID_19D2&PID_1010&MI_04
%ztewwan.DeviceDesc1012% = ztewwan.ndi, USB\VID_19D2&PID_1012&MI_04
%ztewwan.DeviceDesc1402% = ztewwan.ndi, USB\VID_19D2&PID_1402&MI_02
%ztewwan.DeviceDesc0157% = ztewwan.ndi, USB\VID_19D2&PID_0157&MI_05
%ztewwan.DeviceDesc0158% = ztewwan.ndi, USB\VID_19D2&PID_0158&MI_03
%ztewwan.DeviceDesc1401% = ztewwan.ndi, USB\VID_19D2&PID_1401&MI_02
%ztewwan.DeviceDesc0130% = ztewwan.ndi, USB\VID_19D2&PID_0130&MI_01
%ztewwan.DeviceDesc0133% = ztewwan.ndi, USB\VID_19D2&PID_0133&MI_03
%ztewwan.DeviceDesc0176% = ztewwan.ndi, USB\VID_19D2&PID_0176&MI_03
%ztewwan.DeviceDesc0178% = ztewwan.ndi, USB\VID_19D2&PID_0178&MI_03
%ztewwan.DeviceDesc0168% = ztewwan.ndi, USB\VID_19D2&PID_0168&MI_04
;EuFi890
%ztewwan.DeviceDesc0191% = ztewwan.ndi, USB\VID_19D2&PID_0191&MI_04
;AL621
%ztewwan.DeviceDesc0167% = ztewwan.ndi, USB\VID_19D2&PID_0167&MI_04
;MF821
%ztewwan.DeviceDesc0199% = ztewwan.ndi, USB\VID_19D2&PID_0199&MI_01
%ztewwan.DeviceDesc0200% = ztewwan.ndi, USB\VID_19D2&PID_0200&MI_01
%ztewwan.DeviceDesc0257% = ztewwan.ndi, USB\VID_19D2&PID_0257&MI_03
;MF821V
%ztewwan.DeviceDesc1018% = ztewwan.ndi, USB\VID_19D2&PID_1018&MI_03
;MF91
%ztewwan.DeviceDesc1426% = ztewwan.ndi, USB\VID_19D2&PID_1426&MI_02
;0141
%ztewwan.DeviceDesc1247% = ztewwan.ndi, USB\VID_19D2&PID_1247&MI_04
%ztewwan.DeviceDesc1425% = ztewwan.ndi, USB\VID_19D2&PID_1425&MI_02
%ztewwan.DeviceDesc1424% = ztewwan.ndi, USB\VID_19D2&PID_1424&MI_02
%ztewwan.DeviceDesc1252% = ztewwan.ndi, USB\VID_19D2&PID_1252&MI_04
%ztewwan.DeviceDesc1254% = ztewwan.ndi, USB\VID_19D2&PID_1254&MI_04
%ztewwan.DeviceDesc1255A% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_03
%ztewwan.DeviceDesc1255B% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_04
%ztewwan.DeviceDesc1256% = ztewwan.ndi, USB\VID_19D2&PID_1256&MI_04
%ztewwan.DeviceDesc1245% = ztewwanCombB.ndi, USB\VID_19D2&PID_1245&MI_04
%ztewwan.DeviceDesc1021% = ztewwan.ndi, USB\VID_19D2&PID_1021&MI_02
Adding the ones we were missing.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-10-18 13:11:29 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0113, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0118, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0121, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0123, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0124, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0125, 6)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0126, 5)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0130, 1)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0133, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0141, 5)},
|
2012-09-20 05:18:05 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0157, 5)}, /* ZTE MF683 */
|
net: qmi_wwan: adding more ZTE devices
Analyzed a few Windows driver description files, supporting
this long list of devices:
%ztewwan.DeviceDesc0002% = ztewwan.ndi, USB\VID_19D2&PID_0002&MI_01
%ztewwan.DeviceDesc0012% = ztewwan.ndi, USB\VID_19D2&PID_0012&MI_01
%ztewwan.DeviceDesc0017% = ztewwan.ndi, USB\VID_19D2&PID_0017&MI_03
%ztewwan.DeviceDesc0021% = ztewwan.ndi, USB\VID_19D2&PID_0021&MI_04
%ztewwan.DeviceDesc0025% = ztewwan.ndi, USB\VID_19D2&PID_0025&MI_01
%ztewwan.DeviceDesc0031% = ztewwan.ndi, USB\VID_19D2&PID_0031&MI_04
%ztewwan.DeviceDesc0042% = ztewwan.ndi, USB\VID_19D2&PID_0042&MI_04
%ztewwan.DeviceDesc0049% = ztewwan.ndi, USB\VID_19D2&PID_0049&MI_05
%ztewwan.DeviceDesc0052% = ztewwan.ndi, USB\VID_19D2&PID_0052&MI_04
%ztewwan.DeviceDesc0055% = ztewwan.ndi, USB\VID_19D2&PID_0055&MI_01
%ztewwan.DeviceDesc0058% = ztewwan.ndi, USB\VID_19D2&PID_0058&MI_04
%ztewwan.DeviceDesc0063% = ztewwan.ndi, USB\VID_19D2&PID_0063&MI_04
%ztewwan.DeviceDesc2002% = ztewwan.ndi, USB\VID_19D2&PID_2002&MI_04
%ztewwan.DeviceDesc0104% = ztewwan.ndi, USB\VID_19D2&PID_0104&MI_04
%ztewwan.DeviceDesc0113% = ztewwan.ndi, USB\VID_19D2&PID_0113&MI_05
%ztewwan.DeviceDesc0118% = ztewwan.ndi, USB\VID_19D2&PID_0118&MI_05
%ztewwan.DeviceDesc0121% = ztewwan.ndi, USB\VID_19D2&PID_0121&MI_05
%ztewwan.DeviceDesc0123% = ztewwan.ndi, USB\VID_19D2&PID_0123&MI_04
%ztewwan.DeviceDesc0124% = ztewwan.ndi, USB\VID_19D2&PID_0124&MI_05
%ztewwan.DeviceDesc0125% = ztewwan.ndi, USB\VID_19D2&PID_0125&MI_06
%ztewwan.DeviceDesc0126% = ztewwan.ndi, USB\VID_19D2&PID_0126&MI_05
%ztewwan.DeviceDesc1008% = ztewwan.ndi, USB\VID_19D2&PID_1008&MI_04
%ztewwan.DeviceDesc1010% = ztewwan.ndi, USB\VID_19D2&PID_1010&MI_04
%ztewwan.DeviceDesc1012% = ztewwan.ndi, USB\VID_19D2&PID_1012&MI_04
%ztewwan.DeviceDesc1402% = ztewwan.ndi, USB\VID_19D2&PID_1402&MI_02
%ztewwan.DeviceDesc0157% = ztewwan.ndi, USB\VID_19D2&PID_0157&MI_05
%ztewwan.DeviceDesc0158% = ztewwan.ndi, USB\VID_19D2&PID_0158&MI_03
%ztewwan.DeviceDesc1401% = ztewwan.ndi, USB\VID_19D2&PID_1401&MI_02
%ztewwan.DeviceDesc0130% = ztewwan.ndi, USB\VID_19D2&PID_0130&MI_01
%ztewwan.DeviceDesc0133% = ztewwan.ndi, USB\VID_19D2&PID_0133&MI_03
%ztewwan.DeviceDesc0176% = ztewwan.ndi, USB\VID_19D2&PID_0176&MI_03
%ztewwan.DeviceDesc0178% = ztewwan.ndi, USB\VID_19D2&PID_0178&MI_03
%ztewwan.DeviceDesc0168% = ztewwan.ndi, USB\VID_19D2&PID_0168&MI_04
;EuFi890
%ztewwan.DeviceDesc0191% = ztewwan.ndi, USB\VID_19D2&PID_0191&MI_04
;AL621
%ztewwan.DeviceDesc0167% = ztewwan.ndi, USB\VID_19D2&PID_0167&MI_04
;MF821
%ztewwan.DeviceDesc0199% = ztewwan.ndi, USB\VID_19D2&PID_0199&MI_01
%ztewwan.DeviceDesc0200% = ztewwan.ndi, USB\VID_19D2&PID_0200&MI_01
%ztewwan.DeviceDesc0257% = ztewwan.ndi, USB\VID_19D2&PID_0257&MI_03
;MF821V
%ztewwan.DeviceDesc1018% = ztewwan.ndi, USB\VID_19D2&PID_1018&MI_03
;MF91
%ztewwan.DeviceDesc1426% = ztewwan.ndi, USB\VID_19D2&PID_1426&MI_02
;0141
%ztewwan.DeviceDesc1247% = ztewwan.ndi, USB\VID_19D2&PID_1247&MI_04
%ztewwan.DeviceDesc1425% = ztewwan.ndi, USB\VID_19D2&PID_1425&MI_02
%ztewwan.DeviceDesc1424% = ztewwan.ndi, USB\VID_19D2&PID_1424&MI_02
%ztewwan.DeviceDesc1252% = ztewwan.ndi, USB\VID_19D2&PID_1252&MI_04
%ztewwan.DeviceDesc1254% = ztewwan.ndi, USB\VID_19D2&PID_1254&MI_04
%ztewwan.DeviceDesc1255A% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_03
%ztewwan.DeviceDesc1255B% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_04
%ztewwan.DeviceDesc1256% = ztewwan.ndi, USB\VID_19D2&PID_1256&MI_04
%ztewwan.DeviceDesc1245% = ztewwanCombB.ndi, USB\VID_19D2&PID_1245&MI_04
%ztewwan.DeviceDesc1021% = ztewwan.ndi, USB\VID_19D2&PID_1021&MI_02
Adding the ones we were missing.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-10-18 13:11:29 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0158, 3)},
|
2012-08-12 17:16:30 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0167, 4)}, /* ZTE MF820D */
|
net: qmi_wwan: adding more ZTE devices
Analyzed a few Windows driver description files, supporting
this long list of devices:
%ztewwan.DeviceDesc0002% = ztewwan.ndi, USB\VID_19D2&PID_0002&MI_01
%ztewwan.DeviceDesc0012% = ztewwan.ndi, USB\VID_19D2&PID_0012&MI_01
%ztewwan.DeviceDesc0017% = ztewwan.ndi, USB\VID_19D2&PID_0017&MI_03
%ztewwan.DeviceDesc0021% = ztewwan.ndi, USB\VID_19D2&PID_0021&MI_04
%ztewwan.DeviceDesc0025% = ztewwan.ndi, USB\VID_19D2&PID_0025&MI_01
%ztewwan.DeviceDesc0031% = ztewwan.ndi, USB\VID_19D2&PID_0031&MI_04
%ztewwan.DeviceDesc0042% = ztewwan.ndi, USB\VID_19D2&PID_0042&MI_04
%ztewwan.DeviceDesc0049% = ztewwan.ndi, USB\VID_19D2&PID_0049&MI_05
%ztewwan.DeviceDesc0052% = ztewwan.ndi, USB\VID_19D2&PID_0052&MI_04
%ztewwan.DeviceDesc0055% = ztewwan.ndi, USB\VID_19D2&PID_0055&MI_01
%ztewwan.DeviceDesc0058% = ztewwan.ndi, USB\VID_19D2&PID_0058&MI_04
%ztewwan.DeviceDesc0063% = ztewwan.ndi, USB\VID_19D2&PID_0063&MI_04
%ztewwan.DeviceDesc2002% = ztewwan.ndi, USB\VID_19D2&PID_2002&MI_04
%ztewwan.DeviceDesc0104% = ztewwan.ndi, USB\VID_19D2&PID_0104&MI_04
%ztewwan.DeviceDesc0113% = ztewwan.ndi, USB\VID_19D2&PID_0113&MI_05
%ztewwan.DeviceDesc0118% = ztewwan.ndi, USB\VID_19D2&PID_0118&MI_05
%ztewwan.DeviceDesc0121% = ztewwan.ndi, USB\VID_19D2&PID_0121&MI_05
%ztewwan.DeviceDesc0123% = ztewwan.ndi, USB\VID_19D2&PID_0123&MI_04
%ztewwan.DeviceDesc0124% = ztewwan.ndi, USB\VID_19D2&PID_0124&MI_05
%ztewwan.DeviceDesc0125% = ztewwan.ndi, USB\VID_19D2&PID_0125&MI_06
%ztewwan.DeviceDesc0126% = ztewwan.ndi, USB\VID_19D2&PID_0126&MI_05
%ztewwan.DeviceDesc1008% = ztewwan.ndi, USB\VID_19D2&PID_1008&MI_04
%ztewwan.DeviceDesc1010% = ztewwan.ndi, USB\VID_19D2&PID_1010&MI_04
%ztewwan.DeviceDesc1012% = ztewwan.ndi, USB\VID_19D2&PID_1012&MI_04
%ztewwan.DeviceDesc1402% = ztewwan.ndi, USB\VID_19D2&PID_1402&MI_02
%ztewwan.DeviceDesc0157% = ztewwan.ndi, USB\VID_19D2&PID_0157&MI_05
%ztewwan.DeviceDesc0158% = ztewwan.ndi, USB\VID_19D2&PID_0158&MI_03
%ztewwan.DeviceDesc1401% = ztewwan.ndi, USB\VID_19D2&PID_1401&MI_02
%ztewwan.DeviceDesc0130% = ztewwan.ndi, USB\VID_19D2&PID_0130&MI_01
%ztewwan.DeviceDesc0133% = ztewwan.ndi, USB\VID_19D2&PID_0133&MI_03
%ztewwan.DeviceDesc0176% = ztewwan.ndi, USB\VID_19D2&PID_0176&MI_03
%ztewwan.DeviceDesc0178% = ztewwan.ndi, USB\VID_19D2&PID_0178&MI_03
%ztewwan.DeviceDesc0168% = ztewwan.ndi, USB\VID_19D2&PID_0168&MI_04
;EuFi890
%ztewwan.DeviceDesc0191% = ztewwan.ndi, USB\VID_19D2&PID_0191&MI_04
;AL621
%ztewwan.DeviceDesc0167% = ztewwan.ndi, USB\VID_19D2&PID_0167&MI_04
;MF821
%ztewwan.DeviceDesc0199% = ztewwan.ndi, USB\VID_19D2&PID_0199&MI_01
%ztewwan.DeviceDesc0200% = ztewwan.ndi, USB\VID_19D2&PID_0200&MI_01
%ztewwan.DeviceDesc0257% = ztewwan.ndi, USB\VID_19D2&PID_0257&MI_03
;MF821V
%ztewwan.DeviceDesc1018% = ztewwan.ndi, USB\VID_19D2&PID_1018&MI_03
;MF91
%ztewwan.DeviceDesc1426% = ztewwan.ndi, USB\VID_19D2&PID_1426&MI_02
;0141
%ztewwan.DeviceDesc1247% = ztewwan.ndi, USB\VID_19D2&PID_1247&MI_04
%ztewwan.DeviceDesc1425% = ztewwan.ndi, USB\VID_19D2&PID_1425&MI_02
%ztewwan.DeviceDesc1424% = ztewwan.ndi, USB\VID_19D2&PID_1424&MI_02
%ztewwan.DeviceDesc1252% = ztewwan.ndi, USB\VID_19D2&PID_1252&MI_04
%ztewwan.DeviceDesc1254% = ztewwan.ndi, USB\VID_19D2&PID_1254&MI_04
%ztewwan.DeviceDesc1255A% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_03
%ztewwan.DeviceDesc1255B% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_04
%ztewwan.DeviceDesc1256% = ztewwan.ndi, USB\VID_19D2&PID_1256&MI_04
%ztewwan.DeviceDesc1245% = ztewwanCombB.ndi, USB\VID_19D2&PID_1245&MI_04
%ztewwan.DeviceDesc1021% = ztewwan.ndi, USB\VID_19D2&PID_1021&MI_02
Adding the ones we were missing.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-10-18 13:11:29 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0168, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0176, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0178, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0191, 4)}, /* ZTE EuFi890 */
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0199, 1)}, /* ZTE MF820S */
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0200, 1)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0257, 3)}, /* ZTE MF821 */
|
2013-01-18 12:26:34 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0265, 4)}, /* ONDA MT8205 4G LTE */
|
2012-12-19 12:15:51 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0284, 4)}, /* ZTE MF880 */
|
2012-08-12 17:16:30 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0326, 4)}, /* ZTE MF821D */
|
2013-05-03 07:05:13 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0412, 4)}, /* Telewell TW-LTE 4G */
|
2012-08-12 17:16:30 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1008, 4)}, /* ZTE (Vodafone) K3570-Z */
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1010, 4)}, /* ZTE (Vodafone) K3571-Z */
|
net: qmi_wwan: adding more ZTE devices
Analyzed a few Windows driver description files, supporting
this long list of devices:
%ztewwan.DeviceDesc0002% = ztewwan.ndi, USB\VID_19D2&PID_0002&MI_01
%ztewwan.DeviceDesc0012% = ztewwan.ndi, USB\VID_19D2&PID_0012&MI_01
%ztewwan.DeviceDesc0017% = ztewwan.ndi, USB\VID_19D2&PID_0017&MI_03
%ztewwan.DeviceDesc0021% = ztewwan.ndi, USB\VID_19D2&PID_0021&MI_04
%ztewwan.DeviceDesc0025% = ztewwan.ndi, USB\VID_19D2&PID_0025&MI_01
%ztewwan.DeviceDesc0031% = ztewwan.ndi, USB\VID_19D2&PID_0031&MI_04
%ztewwan.DeviceDesc0042% = ztewwan.ndi, USB\VID_19D2&PID_0042&MI_04
%ztewwan.DeviceDesc0049% = ztewwan.ndi, USB\VID_19D2&PID_0049&MI_05
%ztewwan.DeviceDesc0052% = ztewwan.ndi, USB\VID_19D2&PID_0052&MI_04
%ztewwan.DeviceDesc0055% = ztewwan.ndi, USB\VID_19D2&PID_0055&MI_01
%ztewwan.DeviceDesc0058% = ztewwan.ndi, USB\VID_19D2&PID_0058&MI_04
%ztewwan.DeviceDesc0063% = ztewwan.ndi, USB\VID_19D2&PID_0063&MI_04
%ztewwan.DeviceDesc2002% = ztewwan.ndi, USB\VID_19D2&PID_2002&MI_04
%ztewwan.DeviceDesc0104% = ztewwan.ndi, USB\VID_19D2&PID_0104&MI_04
%ztewwan.DeviceDesc0113% = ztewwan.ndi, USB\VID_19D2&PID_0113&MI_05
%ztewwan.DeviceDesc0118% = ztewwan.ndi, USB\VID_19D2&PID_0118&MI_05
%ztewwan.DeviceDesc0121% = ztewwan.ndi, USB\VID_19D2&PID_0121&MI_05
%ztewwan.DeviceDesc0123% = ztewwan.ndi, USB\VID_19D2&PID_0123&MI_04
%ztewwan.DeviceDesc0124% = ztewwan.ndi, USB\VID_19D2&PID_0124&MI_05
%ztewwan.DeviceDesc0125% = ztewwan.ndi, USB\VID_19D2&PID_0125&MI_06
%ztewwan.DeviceDesc0126% = ztewwan.ndi, USB\VID_19D2&PID_0126&MI_05
%ztewwan.DeviceDesc1008% = ztewwan.ndi, USB\VID_19D2&PID_1008&MI_04
%ztewwan.DeviceDesc1010% = ztewwan.ndi, USB\VID_19D2&PID_1010&MI_04
%ztewwan.DeviceDesc1012% = ztewwan.ndi, USB\VID_19D2&PID_1012&MI_04
%ztewwan.DeviceDesc1402% = ztewwan.ndi, USB\VID_19D2&PID_1402&MI_02
%ztewwan.DeviceDesc0157% = ztewwan.ndi, USB\VID_19D2&PID_0157&MI_05
%ztewwan.DeviceDesc0158% = ztewwan.ndi, USB\VID_19D2&PID_0158&MI_03
%ztewwan.DeviceDesc1401% = ztewwan.ndi, USB\VID_19D2&PID_1401&MI_02
%ztewwan.DeviceDesc0130% = ztewwan.ndi, USB\VID_19D2&PID_0130&MI_01
%ztewwan.DeviceDesc0133% = ztewwan.ndi, USB\VID_19D2&PID_0133&MI_03
%ztewwan.DeviceDesc0176% = ztewwan.ndi, USB\VID_19D2&PID_0176&MI_03
%ztewwan.DeviceDesc0178% = ztewwan.ndi, USB\VID_19D2&PID_0178&MI_03
%ztewwan.DeviceDesc0168% = ztewwan.ndi, USB\VID_19D2&PID_0168&MI_04
;EuFi890
%ztewwan.DeviceDesc0191% = ztewwan.ndi, USB\VID_19D2&PID_0191&MI_04
;AL621
%ztewwan.DeviceDesc0167% = ztewwan.ndi, USB\VID_19D2&PID_0167&MI_04
;MF821
%ztewwan.DeviceDesc0199% = ztewwan.ndi, USB\VID_19D2&PID_0199&MI_01
%ztewwan.DeviceDesc0200% = ztewwan.ndi, USB\VID_19D2&PID_0200&MI_01
%ztewwan.DeviceDesc0257% = ztewwan.ndi, USB\VID_19D2&PID_0257&MI_03
;MF821V
%ztewwan.DeviceDesc1018% = ztewwan.ndi, USB\VID_19D2&PID_1018&MI_03
;MF91
%ztewwan.DeviceDesc1426% = ztewwan.ndi, USB\VID_19D2&PID_1426&MI_02
;0141
%ztewwan.DeviceDesc1247% = ztewwan.ndi, USB\VID_19D2&PID_1247&MI_04
%ztewwan.DeviceDesc1425% = ztewwan.ndi, USB\VID_19D2&PID_1425&MI_02
%ztewwan.DeviceDesc1424% = ztewwan.ndi, USB\VID_19D2&PID_1424&MI_02
%ztewwan.DeviceDesc1252% = ztewwan.ndi, USB\VID_19D2&PID_1252&MI_04
%ztewwan.DeviceDesc1254% = ztewwan.ndi, USB\VID_19D2&PID_1254&MI_04
%ztewwan.DeviceDesc1255A% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_03
%ztewwan.DeviceDesc1255B% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_04
%ztewwan.DeviceDesc1256% = ztewwan.ndi, USB\VID_19D2&PID_1256&MI_04
%ztewwan.DeviceDesc1245% = ztewwanCombB.ndi, USB\VID_19D2&PID_1245&MI_04
%ztewwan.DeviceDesc1021% = ztewwan.ndi, USB\VID_19D2&PID_1021&MI_02
Adding the ones we were missing.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-10-18 13:11:29 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1012, 4)},
|
2012-08-15 11:42:57 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1018, 3)}, /* ZTE (Vodafone) K5006-Z */
|
net: qmi_wwan: adding more ZTE devices
Analyzed a few Windows driver description files, supporting
this long list of devices:
%ztewwan.DeviceDesc0002% = ztewwan.ndi, USB\VID_19D2&PID_0002&MI_01
%ztewwan.DeviceDesc0012% = ztewwan.ndi, USB\VID_19D2&PID_0012&MI_01
%ztewwan.DeviceDesc0017% = ztewwan.ndi, USB\VID_19D2&PID_0017&MI_03
%ztewwan.DeviceDesc0021% = ztewwan.ndi, USB\VID_19D2&PID_0021&MI_04
%ztewwan.DeviceDesc0025% = ztewwan.ndi, USB\VID_19D2&PID_0025&MI_01
%ztewwan.DeviceDesc0031% = ztewwan.ndi, USB\VID_19D2&PID_0031&MI_04
%ztewwan.DeviceDesc0042% = ztewwan.ndi, USB\VID_19D2&PID_0042&MI_04
%ztewwan.DeviceDesc0049% = ztewwan.ndi, USB\VID_19D2&PID_0049&MI_05
%ztewwan.DeviceDesc0052% = ztewwan.ndi, USB\VID_19D2&PID_0052&MI_04
%ztewwan.DeviceDesc0055% = ztewwan.ndi, USB\VID_19D2&PID_0055&MI_01
%ztewwan.DeviceDesc0058% = ztewwan.ndi, USB\VID_19D2&PID_0058&MI_04
%ztewwan.DeviceDesc0063% = ztewwan.ndi, USB\VID_19D2&PID_0063&MI_04
%ztewwan.DeviceDesc2002% = ztewwan.ndi, USB\VID_19D2&PID_2002&MI_04
%ztewwan.DeviceDesc0104% = ztewwan.ndi, USB\VID_19D2&PID_0104&MI_04
%ztewwan.DeviceDesc0113% = ztewwan.ndi, USB\VID_19D2&PID_0113&MI_05
%ztewwan.DeviceDesc0118% = ztewwan.ndi, USB\VID_19D2&PID_0118&MI_05
%ztewwan.DeviceDesc0121% = ztewwan.ndi, USB\VID_19D2&PID_0121&MI_05
%ztewwan.DeviceDesc0123% = ztewwan.ndi, USB\VID_19D2&PID_0123&MI_04
%ztewwan.DeviceDesc0124% = ztewwan.ndi, USB\VID_19D2&PID_0124&MI_05
%ztewwan.DeviceDesc0125% = ztewwan.ndi, USB\VID_19D2&PID_0125&MI_06
%ztewwan.DeviceDesc0126% = ztewwan.ndi, USB\VID_19D2&PID_0126&MI_05
%ztewwan.DeviceDesc1008% = ztewwan.ndi, USB\VID_19D2&PID_1008&MI_04
%ztewwan.DeviceDesc1010% = ztewwan.ndi, USB\VID_19D2&PID_1010&MI_04
%ztewwan.DeviceDesc1012% = ztewwan.ndi, USB\VID_19D2&PID_1012&MI_04
%ztewwan.DeviceDesc1402% = ztewwan.ndi, USB\VID_19D2&PID_1402&MI_02
%ztewwan.DeviceDesc0157% = ztewwan.ndi, USB\VID_19D2&PID_0157&MI_05
%ztewwan.DeviceDesc0158% = ztewwan.ndi, USB\VID_19D2&PID_0158&MI_03
%ztewwan.DeviceDesc1401% = ztewwan.ndi, USB\VID_19D2&PID_1401&MI_02
%ztewwan.DeviceDesc0130% = ztewwan.ndi, USB\VID_19D2&PID_0130&MI_01
%ztewwan.DeviceDesc0133% = ztewwan.ndi, USB\VID_19D2&PID_0133&MI_03
%ztewwan.DeviceDesc0176% = ztewwan.ndi, USB\VID_19D2&PID_0176&MI_03
%ztewwan.DeviceDesc0178% = ztewwan.ndi, USB\VID_19D2&PID_0178&MI_03
%ztewwan.DeviceDesc0168% = ztewwan.ndi, USB\VID_19D2&PID_0168&MI_04
;EuFi890
%ztewwan.DeviceDesc0191% = ztewwan.ndi, USB\VID_19D2&PID_0191&MI_04
;AL621
%ztewwan.DeviceDesc0167% = ztewwan.ndi, USB\VID_19D2&PID_0167&MI_04
;MF821
%ztewwan.DeviceDesc0199% = ztewwan.ndi, USB\VID_19D2&PID_0199&MI_01
%ztewwan.DeviceDesc0200% = ztewwan.ndi, USB\VID_19D2&PID_0200&MI_01
%ztewwan.DeviceDesc0257% = ztewwan.ndi, USB\VID_19D2&PID_0257&MI_03
;MF821V
%ztewwan.DeviceDesc1018% = ztewwan.ndi, USB\VID_19D2&PID_1018&MI_03
;MF91
%ztewwan.DeviceDesc1426% = ztewwan.ndi, USB\VID_19D2&PID_1426&MI_02
;0141
%ztewwan.DeviceDesc1247% = ztewwan.ndi, USB\VID_19D2&PID_1247&MI_04
%ztewwan.DeviceDesc1425% = ztewwan.ndi, USB\VID_19D2&PID_1425&MI_02
%ztewwan.DeviceDesc1424% = ztewwan.ndi, USB\VID_19D2&PID_1424&MI_02
%ztewwan.DeviceDesc1252% = ztewwan.ndi, USB\VID_19D2&PID_1252&MI_04
%ztewwan.DeviceDesc1254% = ztewwan.ndi, USB\VID_19D2&PID_1254&MI_04
%ztewwan.DeviceDesc1255A% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_03
%ztewwan.DeviceDesc1255B% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_04
%ztewwan.DeviceDesc1256% = ztewwan.ndi, USB\VID_19D2&PID_1256&MI_04
%ztewwan.DeviceDesc1245% = ztewwanCombB.ndi, USB\VID_19D2&PID_1245&MI_04
%ztewwan.DeviceDesc1021% = ztewwan.ndi, USB\VID_19D2&PID_1021&MI_02
Adding the ones we were missing.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-10-18 13:11:29 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1021, 2)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1245, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1247, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1252, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1254, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1255, 3)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1255, 4)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1256, 4)},
|
2014-02-09 05:01:02 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1270, 5)}, /* ZTE MF667 */
|
net: qmi_wwan: adding more ZTE devices
Analyzed a few Windows driver description files, supporting
this long list of devices:
%ztewwan.DeviceDesc0002% = ztewwan.ndi, USB\VID_19D2&PID_0002&MI_01
%ztewwan.DeviceDesc0012% = ztewwan.ndi, USB\VID_19D2&PID_0012&MI_01
%ztewwan.DeviceDesc0017% = ztewwan.ndi, USB\VID_19D2&PID_0017&MI_03
%ztewwan.DeviceDesc0021% = ztewwan.ndi, USB\VID_19D2&PID_0021&MI_04
%ztewwan.DeviceDesc0025% = ztewwan.ndi, USB\VID_19D2&PID_0025&MI_01
%ztewwan.DeviceDesc0031% = ztewwan.ndi, USB\VID_19D2&PID_0031&MI_04
%ztewwan.DeviceDesc0042% = ztewwan.ndi, USB\VID_19D2&PID_0042&MI_04
%ztewwan.DeviceDesc0049% = ztewwan.ndi, USB\VID_19D2&PID_0049&MI_05
%ztewwan.DeviceDesc0052% = ztewwan.ndi, USB\VID_19D2&PID_0052&MI_04
%ztewwan.DeviceDesc0055% = ztewwan.ndi, USB\VID_19D2&PID_0055&MI_01
%ztewwan.DeviceDesc0058% = ztewwan.ndi, USB\VID_19D2&PID_0058&MI_04
%ztewwan.DeviceDesc0063% = ztewwan.ndi, USB\VID_19D2&PID_0063&MI_04
%ztewwan.DeviceDesc2002% = ztewwan.ndi, USB\VID_19D2&PID_2002&MI_04
%ztewwan.DeviceDesc0104% = ztewwan.ndi, USB\VID_19D2&PID_0104&MI_04
%ztewwan.DeviceDesc0113% = ztewwan.ndi, USB\VID_19D2&PID_0113&MI_05
%ztewwan.DeviceDesc0118% = ztewwan.ndi, USB\VID_19D2&PID_0118&MI_05
%ztewwan.DeviceDesc0121% = ztewwan.ndi, USB\VID_19D2&PID_0121&MI_05
%ztewwan.DeviceDesc0123% = ztewwan.ndi, USB\VID_19D2&PID_0123&MI_04
%ztewwan.DeviceDesc0124% = ztewwan.ndi, USB\VID_19D2&PID_0124&MI_05
%ztewwan.DeviceDesc0125% = ztewwan.ndi, USB\VID_19D2&PID_0125&MI_06
%ztewwan.DeviceDesc0126% = ztewwan.ndi, USB\VID_19D2&PID_0126&MI_05
%ztewwan.DeviceDesc1008% = ztewwan.ndi, USB\VID_19D2&PID_1008&MI_04
%ztewwan.DeviceDesc1010% = ztewwan.ndi, USB\VID_19D2&PID_1010&MI_04
%ztewwan.DeviceDesc1012% = ztewwan.ndi, USB\VID_19D2&PID_1012&MI_04
%ztewwan.DeviceDesc1402% = ztewwan.ndi, USB\VID_19D2&PID_1402&MI_02
%ztewwan.DeviceDesc0157% = ztewwan.ndi, USB\VID_19D2&PID_0157&MI_05
%ztewwan.DeviceDesc0158% = ztewwan.ndi, USB\VID_19D2&PID_0158&MI_03
%ztewwan.DeviceDesc1401% = ztewwan.ndi, USB\VID_19D2&PID_1401&MI_02
%ztewwan.DeviceDesc0130% = ztewwan.ndi, USB\VID_19D2&PID_0130&MI_01
%ztewwan.DeviceDesc0133% = ztewwan.ndi, USB\VID_19D2&PID_0133&MI_03
%ztewwan.DeviceDesc0176% = ztewwan.ndi, USB\VID_19D2&PID_0176&MI_03
%ztewwan.DeviceDesc0178% = ztewwan.ndi, USB\VID_19D2&PID_0178&MI_03
%ztewwan.DeviceDesc0168% = ztewwan.ndi, USB\VID_19D2&PID_0168&MI_04
;EuFi890
%ztewwan.DeviceDesc0191% = ztewwan.ndi, USB\VID_19D2&PID_0191&MI_04
;AL621
%ztewwan.DeviceDesc0167% = ztewwan.ndi, USB\VID_19D2&PID_0167&MI_04
;MF821
%ztewwan.DeviceDesc0199% = ztewwan.ndi, USB\VID_19D2&PID_0199&MI_01
%ztewwan.DeviceDesc0200% = ztewwan.ndi, USB\VID_19D2&PID_0200&MI_01
%ztewwan.DeviceDesc0257% = ztewwan.ndi, USB\VID_19D2&PID_0257&MI_03
;MF821V
%ztewwan.DeviceDesc1018% = ztewwan.ndi, USB\VID_19D2&PID_1018&MI_03
;MF91
%ztewwan.DeviceDesc1426% = ztewwan.ndi, USB\VID_19D2&PID_1426&MI_02
;0141
%ztewwan.DeviceDesc1247% = ztewwan.ndi, USB\VID_19D2&PID_1247&MI_04
%ztewwan.DeviceDesc1425% = ztewwan.ndi, USB\VID_19D2&PID_1425&MI_02
%ztewwan.DeviceDesc1424% = ztewwan.ndi, USB\VID_19D2&PID_1424&MI_02
%ztewwan.DeviceDesc1252% = ztewwan.ndi, USB\VID_19D2&PID_1252&MI_04
%ztewwan.DeviceDesc1254% = ztewwan.ndi, USB\VID_19D2&PID_1254&MI_04
%ztewwan.DeviceDesc1255A% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_03
%ztewwan.DeviceDesc1255B% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_04
%ztewwan.DeviceDesc1256% = ztewwan.ndi, USB\VID_19D2&PID_1256&MI_04
%ztewwan.DeviceDesc1245% = ztewwanCombB.ndi, USB\VID_19D2&PID_1245&MI_04
%ztewwan.DeviceDesc1021% = ztewwan.ndi, USB\VID_19D2&PID_1021&MI_02
Adding the ones we were missing.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-10-18 13:11:29 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1401, 2)},
|
2012-08-12 17:16:30 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1402, 2)}, /* ZTE MF60 */
|
net: qmi_wwan: adding more ZTE devices
Analyzed a few Windows driver description files, supporting
this long list of devices:
%ztewwan.DeviceDesc0002% = ztewwan.ndi, USB\VID_19D2&PID_0002&MI_01
%ztewwan.DeviceDesc0012% = ztewwan.ndi, USB\VID_19D2&PID_0012&MI_01
%ztewwan.DeviceDesc0017% = ztewwan.ndi, USB\VID_19D2&PID_0017&MI_03
%ztewwan.DeviceDesc0021% = ztewwan.ndi, USB\VID_19D2&PID_0021&MI_04
%ztewwan.DeviceDesc0025% = ztewwan.ndi, USB\VID_19D2&PID_0025&MI_01
%ztewwan.DeviceDesc0031% = ztewwan.ndi, USB\VID_19D2&PID_0031&MI_04
%ztewwan.DeviceDesc0042% = ztewwan.ndi, USB\VID_19D2&PID_0042&MI_04
%ztewwan.DeviceDesc0049% = ztewwan.ndi, USB\VID_19D2&PID_0049&MI_05
%ztewwan.DeviceDesc0052% = ztewwan.ndi, USB\VID_19D2&PID_0052&MI_04
%ztewwan.DeviceDesc0055% = ztewwan.ndi, USB\VID_19D2&PID_0055&MI_01
%ztewwan.DeviceDesc0058% = ztewwan.ndi, USB\VID_19D2&PID_0058&MI_04
%ztewwan.DeviceDesc0063% = ztewwan.ndi, USB\VID_19D2&PID_0063&MI_04
%ztewwan.DeviceDesc2002% = ztewwan.ndi, USB\VID_19D2&PID_2002&MI_04
%ztewwan.DeviceDesc0104% = ztewwan.ndi, USB\VID_19D2&PID_0104&MI_04
%ztewwan.DeviceDesc0113% = ztewwan.ndi, USB\VID_19D2&PID_0113&MI_05
%ztewwan.DeviceDesc0118% = ztewwan.ndi, USB\VID_19D2&PID_0118&MI_05
%ztewwan.DeviceDesc0121% = ztewwan.ndi, USB\VID_19D2&PID_0121&MI_05
%ztewwan.DeviceDesc0123% = ztewwan.ndi, USB\VID_19D2&PID_0123&MI_04
%ztewwan.DeviceDesc0124% = ztewwan.ndi, USB\VID_19D2&PID_0124&MI_05
%ztewwan.DeviceDesc0125% = ztewwan.ndi, USB\VID_19D2&PID_0125&MI_06
%ztewwan.DeviceDesc0126% = ztewwan.ndi, USB\VID_19D2&PID_0126&MI_05
%ztewwan.DeviceDesc1008% = ztewwan.ndi, USB\VID_19D2&PID_1008&MI_04
%ztewwan.DeviceDesc1010% = ztewwan.ndi, USB\VID_19D2&PID_1010&MI_04
%ztewwan.DeviceDesc1012% = ztewwan.ndi, USB\VID_19D2&PID_1012&MI_04
%ztewwan.DeviceDesc1402% = ztewwan.ndi, USB\VID_19D2&PID_1402&MI_02
%ztewwan.DeviceDesc0157% = ztewwan.ndi, USB\VID_19D2&PID_0157&MI_05
%ztewwan.DeviceDesc0158% = ztewwan.ndi, USB\VID_19D2&PID_0158&MI_03
%ztewwan.DeviceDesc1401% = ztewwan.ndi, USB\VID_19D2&PID_1401&MI_02
%ztewwan.DeviceDesc0130% = ztewwan.ndi, USB\VID_19D2&PID_0130&MI_01
%ztewwan.DeviceDesc0133% = ztewwan.ndi, USB\VID_19D2&PID_0133&MI_03
%ztewwan.DeviceDesc0176% = ztewwan.ndi, USB\VID_19D2&PID_0176&MI_03
%ztewwan.DeviceDesc0178% = ztewwan.ndi, USB\VID_19D2&PID_0178&MI_03
%ztewwan.DeviceDesc0168% = ztewwan.ndi, USB\VID_19D2&PID_0168&MI_04
;EuFi890
%ztewwan.DeviceDesc0191% = ztewwan.ndi, USB\VID_19D2&PID_0191&MI_04
;AL621
%ztewwan.DeviceDesc0167% = ztewwan.ndi, USB\VID_19D2&PID_0167&MI_04
;MF821
%ztewwan.DeviceDesc0199% = ztewwan.ndi, USB\VID_19D2&PID_0199&MI_01
%ztewwan.DeviceDesc0200% = ztewwan.ndi, USB\VID_19D2&PID_0200&MI_01
%ztewwan.DeviceDesc0257% = ztewwan.ndi, USB\VID_19D2&PID_0257&MI_03
;MF821V
%ztewwan.DeviceDesc1018% = ztewwan.ndi, USB\VID_19D2&PID_1018&MI_03
;MF91
%ztewwan.DeviceDesc1426% = ztewwan.ndi, USB\VID_19D2&PID_1426&MI_02
;0141
%ztewwan.DeviceDesc1247% = ztewwan.ndi, USB\VID_19D2&PID_1247&MI_04
%ztewwan.DeviceDesc1425% = ztewwan.ndi, USB\VID_19D2&PID_1425&MI_02
%ztewwan.DeviceDesc1424% = ztewwan.ndi, USB\VID_19D2&PID_1424&MI_02
%ztewwan.DeviceDesc1252% = ztewwan.ndi, USB\VID_19D2&PID_1252&MI_04
%ztewwan.DeviceDesc1254% = ztewwan.ndi, USB\VID_19D2&PID_1254&MI_04
%ztewwan.DeviceDesc1255A% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_03
%ztewwan.DeviceDesc1255B% = ztewwan.ndi, USB\VID_19D2&PID_1255&MI_04
%ztewwan.DeviceDesc1256% = ztewwan.ndi, USB\VID_19D2&PID_1256&MI_04
%ztewwan.DeviceDesc1245% = ztewwanCombB.ndi, USB\VID_19D2&PID_1245&MI_04
%ztewwan.DeviceDesc1021% = ztewwan.ndi, USB\VID_19D2&PID_1021&MI_02
Adding the ones we were missing.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2012-10-18 13:11:29 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1424, 2)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1425, 2)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1426, 2)}, /* ZTE MF91 */
|
2014-07-02 03:01:09 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1428, 2)}, /* Telewell TW-LTE 4G v2 */
|
2012-08-12 17:16:30 +08:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x2002, 4)}, /* ZTE (Vodafone) K3765-Z */
|
2012-08-12 17:16:31 +08:00
|
|
|
{QMI_FIXED_INTF(0x0f3d, 0x68a2, 8)}, /* Sierra Wireless MC7700 */
|
|
|
|
{QMI_FIXED_INTF(0x114f, 0x68a2, 8)}, /* Sierra Wireless MC7750 */
|
2012-08-12 17:16:30 +08:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x68a2, 8)}, /* Sierra Wireless MC7710 in QMI mode */
|
|
|
|
{QMI_FIXED_INTF(0x1199, 0x68a2, 19)}, /* Sierra Wireless MC7710 in QMI mode */
|
2015-09-01 02:15:14 +08:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x68c0, 8)}, /* Sierra Wireless MC7304/MC7354 */
|
|
|
|
{QMI_FIXED_INTF(0x1199, 0x68c0, 10)}, /* Sierra Wireless MC7304/MC7354 */
|
2012-08-12 17:16:31 +08:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x901c, 8)}, /* Sierra Wireless EM7700 */
|
2014-04-26 01:00:28 +08:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x901f, 8)}, /* Sierra Wireless EM7355 */
|
2014-04-26 01:00:30 +08:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9041, 8)}, /* Sierra Wireless MC7305/MC7355 */
|
2015-07-17 05:28:14 +08:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9041, 10)}, /* Sierra Wireless MC7305/MC7355 */
|
2014-02-04 20:04:33 +08:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9051, 8)}, /* Netgear AirCard 340U */
|
2014-05-29 19:44:45 +08:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9053, 8)}, /* Sierra Wireless Modem */
|
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9054, 8)}, /* Sierra Wireless Modem */
|
2014-05-29 03:05:03 +08:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9055, 8)}, /* Netgear AirCard 341U */
|
2014-05-29 19:44:45 +08:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9056, 8)}, /* Sierra Wireless Modem */
|
2014-07-17 19:33:51 +08:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9057, 8)},
|
2014-05-29 19:44:45 +08:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9061, 8)}, /* Sierra Wireless Modem */
|
2016-03-01 21:31:02 +08:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9071, 8)}, /* Sierra Wireless MC74xx */
|
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9071, 10)}, /* Sierra Wireless MC74xx */
|
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9079, 8)}, /* Sierra Wireless EM74xx */
|
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9079, 10)}, /* Sierra Wireless EM74xx */
|
2012-12-28 14:30:55 +08:00
|
|
|
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)}, /* Telekom Speedstick LTE II (Alcatel One Touch L100V LTE) */
|
2014-04-26 01:00:32 +08:00
|
|
|
{QMI_FIXED_INTF(0x1bbb, 0x0203, 2)}, /* Alcatel L800MA */
|
2013-01-15 07:19:50 +08:00
|
|
|
{QMI_FIXED_INTF(0x2357, 0x0201, 4)}, /* TP-LINK HSUPA Modem MA180 */
|
2013-06-28 23:17:51 +08:00
|
|
|
{QMI_FIXED_INTF(0x2357, 0x9000, 4)}, /* TP-LINK MA260 */
|
2013-01-30 10:47:06 +08:00
|
|
|
{QMI_FIXED_INTF(0x1bc7, 0x1200, 5)}, /* Telit LE920 */
|
2013-09-25 17:21:25 +08:00
|
|
|
{QMI_FIXED_INTF(0x1bc7, 0x1201, 2)}, /* Telit LE920 */
|
2015-11-19 04:13:07 +08:00
|
|
|
{QMI_FIXED_INTF(0x1c9e, 0x9b01, 3)}, /* XS Stick W100-2 from 4G Systems */
|
2014-06-06 23:27:59 +08:00
|
|
|
{QMI_FIXED_INTF(0x0b3c, 0xc000, 4)}, /* Olivetti Olicard 100 */
|
|
|
|
{QMI_FIXED_INTF(0x0b3c, 0xc001, 4)}, /* Olivetti Olicard 120 */
|
|
|
|
{QMI_FIXED_INTF(0x0b3c, 0xc002, 4)}, /* Olivetti Olicard 140 */
|
|
|
|
{QMI_FIXED_INTF(0x0b3c, 0xc004, 6)}, /* Olivetti Olicard 155 */
|
|
|
|
{QMI_FIXED_INTF(0x0b3c, 0xc005, 6)}, /* Olivetti Olicard 200 */
|
|
|
|
{QMI_FIXED_INTF(0x0b3c, 0xc00a, 6)}, /* Olivetti Olicard 160 */
|
2014-04-26 01:00:31 +08:00
|
|
|
{QMI_FIXED_INTF(0x0b3c, 0xc00b, 4)}, /* Olivetti Olicard 500 */
|
2013-09-25 23:02:36 +08:00
|
|
|
{QMI_FIXED_INTF(0x1e2d, 0x0060, 4)}, /* Cinterion PLxx */
|
2014-02-12 22:55:14 +08:00
|
|
|
{QMI_FIXED_INTF(0x1e2d, 0x0053, 4)}, /* Cinterion PHxx,PXxx */
|
2016-03-17 18:07:56 +08:00
|
|
|
{QMI_FIXED_INTF(0x1e2d, 0x0082, 4)}, /* Cinterion PHxx,PXxx (2 RmNet) */
|
|
|
|
{QMI_FIXED_INTF(0x1e2d, 0x0082, 5)}, /* Cinterion PHxx,PXxx (2 RmNet) */
|
|
|
|
{QMI_FIXED_INTF(0x1e2d, 0x0083, 4)}, /* Cinterion PHxx,PXxx (1 RmNet + USB Audio)*/
|
2014-04-26 01:00:34 +08:00
|
|
|
{QMI_FIXED_INTF(0x413c, 0x81a2, 8)}, /* Dell Wireless 5806 Gobi(TM) 4G LTE Mobile Broadband Card */
|
|
|
|
{QMI_FIXED_INTF(0x413c, 0x81a3, 8)}, /* Dell Wireless 5570 HSPA+ (42Mbps) Mobile Broadband Card */
|
|
|
|
{QMI_FIXED_INTF(0x413c, 0x81a4, 8)}, /* Dell Wireless 5570e HSPA+ (42Mbps) Mobile Broadband Card */
|
|
|
|
{QMI_FIXED_INTF(0x413c, 0x81a8, 8)}, /* Dell Wireless 5808 Gobi(TM) 4G LTE Mobile Broadband Card */
|
|
|
|
{QMI_FIXED_INTF(0x413c, 0x81a9, 8)}, /* Dell Wireless 5808e Gobi(TM) 4G LTE Mobile Broadband Card */
|
2015-07-20 16:14:13 +08:00
|
|
|
{QMI_FIXED_INTF(0x413c, 0x81b1, 8)}, /* Dell Wireless 5809e Gobi(TM) 4G LTE Mobile Broadband Card */
|
2016-02-21 01:49:40 +08:00
|
|
|
{QMI_FIXED_INTF(0x413c, 0x81b3, 8)}, /* Dell Wireless 5809e Gobi(TM) 4G LTE Mobile Broadband Card (rev3) */
|
2015-08-16 08:12:30 +08:00
|
|
|
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)}, /* HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module */
|
2016-01-06 21:15:50 +08:00
|
|
|
{QMI_FIXED_INTF(0x22de, 0x9061, 3)}, /* WeTelecom WPD-600N */
|
2016-01-07 23:41:33 +08:00
|
|
|
{QMI_FIXED_INTF(0x1e0e, 0x9001, 5)}, /* SIMCom 7230E */
|
2012-08-12 17:16:30 +08:00
|
|
|
|
|
|
|
/* 4. Gobi 1000 devices */
|
2012-06-21 10:45:58 +08:00
|
|
|
{QMI_GOBI1K_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
|
|
|
|
{QMI_GOBI1K_DEVICE(0x03f0, 0x1f1d)}, /* HP un2400 Gobi Modem Device */
|
|
|
|
{QMI_GOBI1K_DEVICE(0x04da, 0x250d)}, /* Panasonic Gobi Modem device */
|
|
|
|
{QMI_GOBI1K_DEVICE(0x413c, 0x8172)}, /* Dell Gobi Modem device */
|
2013-06-21 05:10:59 +08:00
|
|
|
{QMI_GOBI1K_DEVICE(0x1410, 0xa001)}, /* Novatel/Verizon USB-1000 */
|
|
|
|
{QMI_GOBI1K_DEVICE(0x1410, 0xa002)}, /* Novatel Gobi Modem device */
|
|
|
|
{QMI_GOBI1K_DEVICE(0x1410, 0xa003)}, /* Novatel Gobi Modem device */
|
|
|
|
{QMI_GOBI1K_DEVICE(0x1410, 0xa004)}, /* Novatel Gobi Modem device */
|
|
|
|
{QMI_GOBI1K_DEVICE(0x1410, 0xa005)}, /* Novatel Gobi Modem device */
|
|
|
|
{QMI_GOBI1K_DEVICE(0x1410, 0xa006)}, /* Novatel Gobi Modem device */
|
|
|
|
{QMI_GOBI1K_DEVICE(0x1410, 0xa007)}, /* Novatel Gobi Modem device */
|
2012-06-21 10:45:58 +08:00
|
|
|
{QMI_GOBI1K_DEVICE(0x0b05, 0x1776)}, /* Asus Gobi Modem device */
|
|
|
|
{QMI_GOBI1K_DEVICE(0x19d2, 0xfff3)}, /* ONDA Gobi Modem device */
|
|
|
|
{QMI_GOBI1K_DEVICE(0x05c6, 0x9001)}, /* Generic Gobi Modem device */
|
|
|
|
{QMI_GOBI1K_DEVICE(0x05c6, 0x9002)}, /* Generic Gobi Modem device */
|
|
|
|
{QMI_GOBI1K_DEVICE(0x05c6, 0x9202)}, /* Generic Gobi Modem device */
|
|
|
|
{QMI_GOBI1K_DEVICE(0x05c6, 0x9203)}, /* Generic Gobi Modem device */
|
|
|
|
{QMI_GOBI1K_DEVICE(0x05c6, 0x9222)}, /* Generic Gobi Modem device */
|
|
|
|
{QMI_GOBI1K_DEVICE(0x05c6, 0x9009)}, /* Generic Gobi Modem device */
|
|
|
|
|
2012-08-12 17:16:30 +08:00
|
|
|
/* 5. Gobi 2000 and 3000 devices */
|
2012-03-09 19:35:06 +08:00
|
|
|
{QMI_GOBI_DEVICE(0x413c, 0x8186)}, /* Dell Gobi 2000 Modem device (N0218, VU936) */
|
2012-09-01 11:47:26 +08:00
|
|
|
{QMI_GOBI_DEVICE(0x413c, 0x8194)}, /* Dell Gobi 3000 Composite */
|
2012-03-09 19:35:06 +08:00
|
|
|
{QMI_GOBI_DEVICE(0x05c6, 0x920b)}, /* Generic Gobi 2000 Modem device */
|
|
|
|
{QMI_GOBI_DEVICE(0x05c6, 0x9225)}, /* Sony Gobi 2000 Modem device (N0279, VU730) */
|
|
|
|
{QMI_GOBI_DEVICE(0x05c6, 0x9245)}, /* Samsung Gobi 2000 Modem device (VL176) */
|
|
|
|
{QMI_GOBI_DEVICE(0x03f0, 0x251d)}, /* HP Gobi 2000 Modem device (VP412) */
|
|
|
|
{QMI_GOBI_DEVICE(0x05c6, 0x9215)}, /* Acer Gobi 2000 Modem device (VP413) */
|
2015-11-05 19:55:01 +08:00
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9215, 4)}, /* Quectel EC20 Mini PCIe */
|
2012-03-09 19:35:06 +08:00
|
|
|
{QMI_GOBI_DEVICE(0x05c6, 0x9265)}, /* Asus Gobi 2000 Modem device (VR305) */
|
|
|
|
{QMI_GOBI_DEVICE(0x05c6, 0x9235)}, /* Top Global Gobi 2000 Modem device (VR306) */
|
|
|
|
{QMI_GOBI_DEVICE(0x05c6, 0x9275)}, /* iRex Technologies Gobi 2000 Modem device (VR307) */
|
2013-06-28 23:17:50 +08:00
|
|
|
{QMI_GOBI_DEVICE(0x0af0, 0x8120)}, /* Option GTM681W */
|
2012-08-12 17:16:31 +08:00
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x68a5)}, /* Sierra Wireless Modem */
|
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x68a9)}, /* Sierra Wireless Modem */
|
2012-03-09 19:35:06 +08:00
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x9001)}, /* Sierra Wireless Gobi 2000 Modem device (VT773) */
|
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x9002)}, /* Sierra Wireless Gobi 2000 Modem device (VT773) */
|
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x9003)}, /* Sierra Wireless Gobi 2000 Modem device (VT773) */
|
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x9004)}, /* Sierra Wireless Gobi 2000 Modem device (VT773) */
|
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x9005)}, /* Sierra Wireless Gobi 2000 Modem device (VT773) */
|
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x9006)}, /* Sierra Wireless Gobi 2000 Modem device (VT773) */
|
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x9007)}, /* Sierra Wireless Gobi 2000 Modem device (VT773) */
|
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x9008)}, /* Sierra Wireless Gobi 2000 Modem device (VT773) */
|
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x9009)}, /* Sierra Wireless Gobi 2000 Modem device (VT773) */
|
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x900a)}, /* Sierra Wireless Gobi 2000 Modem device (VT773) */
|
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x9011)}, /* Sierra Wireless Gobi 2000 Modem device (MC8305) */
|
|
|
|
{QMI_GOBI_DEVICE(0x16d8, 0x8002)}, /* CMDTech Gobi 2000 Modem device (VU922) */
|
|
|
|
{QMI_GOBI_DEVICE(0x05c6, 0x9205)}, /* Gobi 2000 Modem device */
|
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x9013)}, /* Sierra Wireless Gobi 3000 Modem device (MC8355) */
|
2012-09-10 15:02:59 +08:00
|
|
|
{QMI_GOBI_DEVICE(0x03f0, 0x371d)}, /* HP un2430 Mobile Broadband Module */
|
2012-05-24 07:19:32 +08:00
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x9015)}, /* Sierra Wireless Gobi 3000 Modem device */
|
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x9019)}, /* Sierra Wireless Gobi 3000 Modem device */
|
2012-08-12 17:16:31 +08:00
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x901b)}, /* Sierra Wireless MC7770 */
|
2012-09-01 11:47:26 +08:00
|
|
|
{QMI_GOBI_DEVICE(0x12d1, 0x14f1)}, /* Sony Gobi 3000 Composite */
|
2012-08-28 10:30:32 +08:00
|
|
|
{QMI_GOBI_DEVICE(0x1410, 0xa021)}, /* Foxconn Gobi 3000 Modem device (Novatel E396) */
|
2012-08-12 17:16:31 +08:00
|
|
|
|
2012-03-09 19:35:06 +08:00
|
|
|
{ } /* END */
|
2012-01-19 23:37:22 +08:00
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(usb, products);
|
|
|
|
|
2015-11-05 19:55:01 +08:00
|
|
|
static bool quectel_ec20_detected(struct usb_interface *intf)
|
|
|
|
{
|
|
|
|
struct usb_device *dev = interface_to_usbdev(intf);
|
|
|
|
|
|
|
|
if (dev->actconfig &&
|
|
|
|
le16_to_cpu(dev->descriptor.idVendor) == 0x05c6 &&
|
|
|
|
le16_to_cpu(dev->descriptor.idProduct) == 0x9215 &&
|
|
|
|
dev->actconfig->desc.bNumInterfaces == 5)
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2013-09-25 17:21:26 +08:00
|
|
|
static int qmi_wwan_probe(struct usb_interface *intf,
|
|
|
|
const struct usb_device_id *prod)
|
2012-07-17 19:14:32 +08:00
|
|
|
{
|
|
|
|
struct usb_device_id *id = (struct usb_device_id *)prod;
|
2015-11-05 19:55:01 +08:00
|
|
|
struct usb_interface_descriptor *desc = &intf->cur_altsetting->desc;
|
2012-07-17 19:14:32 +08:00
|
|
|
|
|
|
|
/* Workaround to enable dynamic IDs. This disables usbnet
|
|
|
|
* blacklisting functionality. Which, if required, can be
|
|
|
|
* reimplemented here by using a magic "blacklist" value
|
|
|
|
* instead of 0 in the static device id table
|
|
|
|
*/
|
|
|
|
if (!id->driver_info) {
|
|
|
|
dev_dbg(&intf->dev, "setting defaults for dynamic device id\n");
|
2012-09-07 15:36:07 +08:00
|
|
|
id->driver_info = (unsigned long)&qmi_wwan_info;
|
2012-07-17 19:14:32 +08:00
|
|
|
}
|
|
|
|
|
2015-11-05 19:55:01 +08:00
|
|
|
/* Quectel EC20 quirk where we've QMI on interface 4 instead of 0 */
|
|
|
|
if (quectel_ec20_detected(intf) && desc->bInterfaceNumber == 0) {
|
|
|
|
dev_dbg(&intf->dev, "Quectel EC20 quirk, skipping interface 0\n");
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
2012-07-17 19:14:32 +08:00
|
|
|
return usbnet_probe(intf, id);
|
|
|
|
}
|
|
|
|
|
2012-01-19 23:37:22 +08:00
|
|
|
static struct usb_driver qmi_wwan_driver = {
|
|
|
|
.name = "qmi_wwan",
|
|
|
|
.id_table = products,
|
2012-07-17 19:14:32 +08:00
|
|
|
.probe = qmi_wwan_probe,
|
2012-01-19 23:37:22 +08:00
|
|
|
.disconnect = usbnet_disconnect,
|
2012-03-09 19:35:05 +08:00
|
|
|
.suspend = qmi_wwan_suspend,
|
|
|
|
.resume = qmi_wwan_resume,
|
|
|
|
.reset_resume = qmi_wwan_resume,
|
2012-01-19 23:37:22 +08:00
|
|
|
.supports_autosuspend = 1,
|
2012-04-24 01:08:51 +08:00
|
|
|
.disable_hub_initiated_lpm = 1,
|
2012-01-19 23:37:22 +08:00
|
|
|
};
|
|
|
|
|
2012-06-19 08:42:03 +08:00
|
|
|
module_usb_driver(qmi_wwan_driver);
|
2012-01-19 23:37:22 +08:00
|
|
|
|
|
|
|
MODULE_AUTHOR("Bjørn Mork <bjorn@mork.no>");
|
|
|
|
MODULE_DESCRIPTION("Qualcomm MSM Interface (QMI) WWAN driver");
|
|
|
|
MODULE_LICENSE("GPL");
|