2019-06-04 15:11:33 +07:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-only
|
2012-01-19 22:37:22 +07:00
|
|
|
/*
|
|
|
|
* Copyright (c) 2012 Bjørn Mork <bjorn@mork.no>
|
|
|
|
*
|
2012-06-19 07:42:01 +07: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 22:37:22 +07:00
|
|
|
*/
|
|
|
|
|
|
|
|
#include <linux/module.h>
|
2017-02-03 01:15:33 +07:00
|
|
|
#include <linux/sched/signal.h>
|
2012-01-19 22:37:22 +07:00
|
|
|
#include <linux/netdevice.h>
|
|
|
|
#include <linux/ethtool.h>
|
2013-04-18 19:57:09 +07: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 01:24:21 +07:00
|
|
|
#include <linux/if_arp.h>
|
2012-01-19 22:37:22 +07:00
|
|
|
#include <linux/mii.h>
|
2015-12-07 03:25:50 +07:00
|
|
|
#include <linux/rtnetlink.h>
|
2012-01-19 22:37:22 +07:00
|
|
|
#include <linux/usb.h>
|
|
|
|
#include <linux/usb/cdc.h>
|
|
|
|
#include <linux/usb/usbnet.h>
|
2012-03-09 18:35:05 +07:00
|
|
|
#include <linux/usb/cdc-wdm.h>
|
2019-06-13 00:02:46 +07:00
|
|
|
#include <linux/u64_stats_sync.h>
|
2012-01-19 22:37:22 +07:00
|
|
|
|
2012-06-19 07:42:01 +07:00
|
|
|
/* This driver supports wwan (3G/LTE/?) devices using a vendor
|
2012-01-19 22:37:22 +07: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 07:42:01 +07:00
|
|
|
* Alternatively, control and data functions can be combined in a
|
|
|
|
* single USB interface.
|
|
|
|
*
|
2012-01-19 22:37:22 +07:00
|
|
|
* Handling a protocol like QMI is out of the scope for any driver.
|
2012-06-19 07:42:01 +07: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 22:37:22 +07:00
|
|
|
*
|
|
|
|
* These devices may alternatively/additionally be configured using AT
|
2012-06-19 07:42:01 +07:00
|
|
|
* commands on a serial interface
|
2012-01-19 22:37:22 +07:00
|
|
|
*/
|
|
|
|
|
2012-06-19 07:41:59 +07: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 01:24:21 +07:00
|
|
|
unsigned long flags;
|
2012-06-19 07:42:00 +07:00
|
|
|
struct usb_interface *control;
|
|
|
|
struct usb_interface *data;
|
2012-06-19 07:41:59 +07: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 01:24:21 +07:00
|
|
|
enum qmi_wwan_flags {
|
|
|
|
QMI_WWAN_FLAG_RAWIP = 1 << 0,
|
2017-03-24 20:22:45 +07:00
|
|
|
QMI_WWAN_FLAG_MUX = 1 << 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 01:24:21 +07:00
|
|
|
};
|
|
|
|
|
2016-10-11 02:12:49 +07:00
|
|
|
enum qmi_wwan_quirks {
|
|
|
|
QMI_WWAN_QUIRK_DTR = 1 << 0, /* needs "set DTR" request */
|
qmi_wwan: Add quirk for Quectel dynamic config
Most, if not all, Quectel devices use dynamic interface numbers, and
users are able to change the USB configuration at will. Matching on for
example interface number is therefore not possible.
Instead, the QMI device can be identified by looking at the interface
class, subclass and protocol (all 0xff), as well as the number of
endpoints. The reason we need to look at the number of endpoints, is
that the diagnostic port interface has the same class, subclass and
protocol as QMI. However, the diagnostic port only has two endpoints,
while QMI has three.
Until now, we have identified the QMI device by combining a match on
class, subclass and protocol, with a call to the function
quectel_diag_detect(). In quectel_diag_detect(), we check if the number
of endpoints matches for known Quectel vendor/product ids.
Adding new vendor/product ids to quectel_diag_detect() is not a good
long-term solution. This commit replaces the function with a quirk, and
applies the quirk to affected Quectel devices that I have been able to
test the change with (EP06, EM12 and EC25). If the quirk is set and the
number of endpoints equal two, we return from qmi_wwan_probe() with
-ENODEV.
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-07 20:39:09 +07:00
|
|
|
QMI_WWAN_QUIRK_QUECTEL_DYNCFG = 1 << 1, /* check num. endpoints */
|
2016-10-11 02:12:49 +07:00
|
|
|
};
|
|
|
|
|
2017-03-24 20:22:45 +07:00
|
|
|
struct qmimux_hdr {
|
|
|
|
u8 pad;
|
|
|
|
u8 mux_id;
|
|
|
|
__be16 pkt_len;
|
|
|
|
};
|
|
|
|
|
|
|
|
struct qmimux_priv {
|
|
|
|
struct net_device *real_dev;
|
|
|
|
u8 mux_id;
|
2019-06-13 00:02:46 +07:00
|
|
|
struct pcpu_sw_netstats __percpu *stats64;
|
2017-03-24 20:22:45 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
static int qmimux_open(struct net_device *dev)
|
|
|
|
{
|
|
|
|
struct qmimux_priv *priv = netdev_priv(dev);
|
|
|
|
struct net_device *real_dev = priv->real_dev;
|
|
|
|
|
|
|
|
if (!(priv->real_dev->flags & IFF_UP))
|
|
|
|
return -ENETDOWN;
|
|
|
|
|
|
|
|
if (netif_carrier_ok(real_dev))
|
|
|
|
netif_carrier_on(dev);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int qmimux_stop(struct net_device *dev)
|
|
|
|
{
|
|
|
|
netif_carrier_off(dev);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static netdev_tx_t qmimux_start_xmit(struct sk_buff *skb, struct net_device *dev)
|
|
|
|
{
|
|
|
|
struct qmimux_priv *priv = netdev_priv(dev);
|
|
|
|
unsigned int len = skb->len;
|
|
|
|
struct qmimux_hdr *hdr;
|
2019-06-13 00:02:46 +07:00
|
|
|
netdev_tx_t ret;
|
2017-03-24 20:22:45 +07:00
|
|
|
|
networking: make skb_push & __skb_push return void pointers
It seems like a historic accident that these return unsigned char *,
and in many places that means casts are required, more often than not.
Make these functions return void * and remove all the casts across
the tree, adding a (u8 *) cast only where the unsigned char pointer
was used directly, all done with the following spatch:
@@
expression SKB, LEN;
typedef u8;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
@@
- *(fn(SKB, LEN))
+ *(u8 *)fn(SKB, LEN)
@@
expression E, SKB, LEN;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
type T;
@@
- E = ((T *)(fn(SKB, LEN)))
+ E = fn(SKB, LEN)
@@
expression SKB, LEN;
identifier fn = { skb_push, __skb_push, skb_push_rcsum };
@@
- fn(SKB, LEN)[0]
+ *(u8 *)fn(SKB, LEN)
Note that the last part there converts from push(...)[0] to the
more idiomatic *(u8 *)push(...).
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-06-16 19:29:23 +07:00
|
|
|
hdr = skb_push(skb, sizeof(struct qmimux_hdr));
|
2017-03-24 20:22:45 +07:00
|
|
|
hdr->pad = 0;
|
|
|
|
hdr->mux_id = priv->mux_id;
|
|
|
|
hdr->pkt_len = cpu_to_be16(len);
|
|
|
|
skb->dev = priv->real_dev;
|
2019-06-13 00:02:46 +07:00
|
|
|
ret = dev_queue_xmit(skb);
|
|
|
|
|
|
|
|
if (likely(ret == NET_XMIT_SUCCESS || ret == NET_XMIT_CN)) {
|
|
|
|
struct pcpu_sw_netstats *stats64 = this_cpu_ptr(priv->stats64);
|
|
|
|
|
|
|
|
u64_stats_update_begin(&stats64->syncp);
|
|
|
|
stats64->tx_packets++;
|
|
|
|
stats64->tx_bytes += len;
|
|
|
|
u64_stats_update_end(&stats64->syncp);
|
|
|
|
} else {
|
|
|
|
dev->stats.tx_dropped++;
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void qmimux_get_stats64(struct net_device *net,
|
|
|
|
struct rtnl_link_stats64 *stats)
|
|
|
|
{
|
|
|
|
struct qmimux_priv *priv = netdev_priv(net);
|
|
|
|
unsigned int start;
|
|
|
|
int cpu;
|
|
|
|
|
|
|
|
netdev_stats_to_stats64(stats, &net->stats);
|
|
|
|
|
|
|
|
for_each_possible_cpu(cpu) {
|
|
|
|
struct pcpu_sw_netstats *stats64;
|
|
|
|
u64 rx_packets, rx_bytes;
|
|
|
|
u64 tx_packets, tx_bytes;
|
|
|
|
|
|
|
|
stats64 = per_cpu_ptr(priv->stats64, cpu);
|
|
|
|
|
|
|
|
do {
|
|
|
|
start = u64_stats_fetch_begin_irq(&stats64->syncp);
|
|
|
|
rx_packets = stats64->rx_packets;
|
|
|
|
rx_bytes = stats64->rx_bytes;
|
|
|
|
tx_packets = stats64->tx_packets;
|
|
|
|
tx_bytes = stats64->tx_bytes;
|
|
|
|
} while (u64_stats_fetch_retry_irq(&stats64->syncp, start));
|
|
|
|
|
|
|
|
stats->rx_packets += rx_packets;
|
|
|
|
stats->rx_bytes += rx_bytes;
|
|
|
|
stats->tx_packets += tx_packets;
|
|
|
|
stats->tx_bytes += tx_bytes;
|
|
|
|
}
|
2017-03-24 20:22:45 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static const struct net_device_ops qmimux_netdev_ops = {
|
2019-06-13 00:02:46 +07:00
|
|
|
.ndo_open = qmimux_open,
|
|
|
|
.ndo_stop = qmimux_stop,
|
|
|
|
.ndo_start_xmit = qmimux_start_xmit,
|
|
|
|
.ndo_get_stats64 = qmimux_get_stats64,
|
2017-03-24 20:22:45 +07:00
|
|
|
};
|
|
|
|
|
|
|
|
static void qmimux_setup(struct net_device *dev)
|
|
|
|
{
|
|
|
|
dev->header_ops = NULL; /* No header */
|
|
|
|
dev->type = ARPHRD_NONE;
|
|
|
|
dev->hard_header_len = 0;
|
|
|
|
dev->addr_len = 0;
|
|
|
|
dev->flags = IFF_POINTOPOINT | IFF_NOARP | IFF_MULTICAST;
|
|
|
|
dev->netdev_ops = &qmimux_netdev_ops;
|
2019-01-04 19:26:10 +07:00
|
|
|
dev->mtu = 1500;
|
net: Fix inconsistent teardown and release of private netdev state.
Network devices can allocate reasources and private memory using
netdev_ops->ndo_init(). However, the release of these resources
can occur in one of two different places.
Either netdev_ops->ndo_uninit() or netdev->destructor().
The decision of which operation frees the resources depends upon
whether it is necessary for all netdev refs to be released before it
is safe to perform the freeing.
netdev_ops->ndo_uninit() presumably can occur right after the
NETDEV_UNREGISTER notifier completes and the unicast and multicast
address lists are flushed.
netdev->destructor(), on the other hand, does not run until the
netdev references all go away.
Further complicating the situation is that netdev->destructor()
almost universally does also a free_netdev().
This creates a problem for the logic in register_netdevice().
Because all callers of register_netdevice() manage the freeing
of the netdev, and invoke free_netdev(dev) if register_netdevice()
fails.
If netdev_ops->ndo_init() succeeds, but something else fails inside
of register_netdevice(), it does call ndo_ops->ndo_uninit(). But
it is not able to invoke netdev->destructor().
This is because netdev->destructor() will do a free_netdev() and
then the caller of register_netdevice() will do the same.
However, this means that the resources that would normally be released
by netdev->destructor() will not be.
Over the years drivers have added local hacks to deal with this, by
invoking their destructor parts by hand when register_netdevice()
fails.
Many drivers do not try to deal with this, and instead we have leaks.
Let's close this hole by formalizing the distinction between what
private things need to be freed up by netdev->destructor() and whether
the driver needs unregister_netdevice() to perform the free_netdev().
netdev->priv_destructor() performs all actions to free up the private
resources that used to be freed by netdev->destructor(), except for
free_netdev().
netdev->needs_free_netdev is a boolean that indicates whether
free_netdev() should be done at the end of unregister_netdevice().
Now, register_netdevice() can sanely release all resources after
ndo_ops->ndo_init() succeeds, by invoking both ndo_ops->ndo_uninit()
and netdev->priv_destructor().
And at the end of unregister_netdevice(), we invoke
netdev->priv_destructor() and optionally call free_netdev().
Signed-off-by: David S. Miller <davem@davemloft.net>
2017-05-08 23:52:56 +07:00
|
|
|
dev->needs_free_netdev = true;
|
2017-03-24 20:22:45 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static struct net_device *qmimux_find_dev(struct usbnet *dev, u8 mux_id)
|
|
|
|
{
|
|
|
|
struct qmimux_priv *priv;
|
|
|
|
struct list_head *iter;
|
|
|
|
struct net_device *ldev;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
netdev_for_each_upper_dev_rcu(dev->net, ldev, iter) {
|
|
|
|
priv = netdev_priv(ldev);
|
|
|
|
if (priv->mux_id == mux_id) {
|
|
|
|
rcu_read_unlock();
|
|
|
|
return ldev;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool qmimux_has_slaves(struct usbnet *dev)
|
|
|
|
{
|
|
|
|
return !list_empty(&dev->net->adj_list.upper);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int qmimux_rx_fixup(struct usbnet *dev, struct sk_buff *skb)
|
|
|
|
{
|
2019-06-13 00:02:13 +07:00
|
|
|
unsigned int len, offset = 0, pad_len, pkt_len;
|
2017-03-24 20:22:45 +07:00
|
|
|
struct qmimux_hdr *hdr;
|
|
|
|
struct net_device *net;
|
|
|
|
struct sk_buff *skbn;
|
2018-12-21 19:07:23 +07:00
|
|
|
u8 qmimux_hdr_sz = sizeof(*hdr);
|
2017-03-24 20:22:45 +07:00
|
|
|
|
2018-12-21 19:07:23 +07:00
|
|
|
while (offset + qmimux_hdr_sz < skb->len) {
|
|
|
|
hdr = (struct qmimux_hdr *)(skb->data + offset);
|
2017-03-24 20:22:45 +07:00
|
|
|
len = be16_to_cpu(hdr->pkt_len);
|
|
|
|
|
|
|
|
/* drop the packet, bogus length */
|
2018-12-21 19:07:23 +07:00
|
|
|
if (offset + len + qmimux_hdr_sz > skb->len)
|
2017-03-24 20:22:45 +07:00
|
|
|
return 0;
|
|
|
|
|
|
|
|
/* control packet, we do not know what to do */
|
|
|
|
if (hdr->pad & 0x80)
|
|
|
|
goto skip;
|
|
|
|
|
2019-06-13 00:02:13 +07:00
|
|
|
/* extract padding length and check for valid length info */
|
|
|
|
pad_len = hdr->pad & 0x3f;
|
|
|
|
if (len == 0 || pad_len >= len)
|
|
|
|
goto skip;
|
|
|
|
pkt_len = len - pad_len;
|
|
|
|
|
2017-03-24 20:22:45 +07:00
|
|
|
net = qmimux_find_dev(dev, hdr->mux_id);
|
|
|
|
if (!net)
|
|
|
|
goto skip;
|
2019-06-13 00:02:13 +07:00
|
|
|
skbn = netdev_alloc_skb(net, pkt_len);
|
2017-03-24 20:22:45 +07:00
|
|
|
if (!skbn)
|
|
|
|
return 0;
|
|
|
|
skbn->dev = net;
|
|
|
|
|
2018-12-21 19:07:23 +07:00
|
|
|
switch (skb->data[offset + qmimux_hdr_sz] & 0xf0) {
|
2017-03-24 20:22:45 +07:00
|
|
|
case 0x40:
|
|
|
|
skbn->protocol = htons(ETH_P_IP);
|
|
|
|
break;
|
|
|
|
case 0x60:
|
|
|
|
skbn->protocol = htons(ETH_P_IPV6);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
/* not ip - do not know what to do */
|
|
|
|
goto skip;
|
|
|
|
}
|
|
|
|
|
2019-06-13 00:02:13 +07:00
|
|
|
skb_put_data(skbn, skb->data + offset + qmimux_hdr_sz, pkt_len);
|
2019-06-13 00:02:46 +07:00
|
|
|
if (netif_rx(skbn) != NET_RX_SUCCESS) {
|
|
|
|
net->stats.rx_errors++;
|
2017-03-24 20:22:45 +07:00
|
|
|
return 0;
|
2019-06-13 00:02:46 +07:00
|
|
|
} else {
|
|
|
|
struct pcpu_sw_netstats *stats64;
|
|
|
|
struct qmimux_priv *priv = netdev_priv(net);
|
|
|
|
|
|
|
|
stats64 = this_cpu_ptr(priv->stats64);
|
|
|
|
u64_stats_update_begin(&stats64->syncp);
|
|
|
|
stats64->rx_packets++;
|
|
|
|
stats64->rx_bytes += pkt_len;
|
|
|
|
u64_stats_update_end(&stats64->syncp);
|
|
|
|
}
|
2017-03-24 20:22:45 +07:00
|
|
|
|
|
|
|
skip:
|
2018-12-21 19:07:23 +07:00
|
|
|
offset += len + qmimux_hdr_sz;
|
2017-03-24 20:22:45 +07:00
|
|
|
}
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int qmimux_register_device(struct net_device *real_dev, u8 mux_id)
|
|
|
|
{
|
|
|
|
struct net_device *new_dev;
|
|
|
|
struct qmimux_priv *priv;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
new_dev = alloc_netdev(sizeof(struct qmimux_priv),
|
|
|
|
"qmimux%d", NET_NAME_UNKNOWN, qmimux_setup);
|
|
|
|
if (!new_dev)
|
|
|
|
return -ENOBUFS;
|
|
|
|
|
|
|
|
dev_net_set(new_dev, dev_net(real_dev));
|
|
|
|
priv = netdev_priv(new_dev);
|
|
|
|
priv->mux_id = mux_id;
|
|
|
|
priv->real_dev = real_dev;
|
|
|
|
|
2019-06-13 00:02:46 +07:00
|
|
|
priv->stats64 = netdev_alloc_pcpu_stats(struct pcpu_sw_netstats);
|
|
|
|
if (!priv->stats64) {
|
|
|
|
err = -ENOBUFS;
|
|
|
|
goto out_free_newdev;
|
|
|
|
}
|
|
|
|
|
2017-03-24 20:22:45 +07:00
|
|
|
err = register_netdevice(new_dev);
|
|
|
|
if (err < 0)
|
|
|
|
goto out_free_newdev;
|
|
|
|
|
|
|
|
/* Account for reference in struct qmimux_priv_priv */
|
|
|
|
dev_hold(real_dev);
|
|
|
|
|
2017-10-05 07:48:47 +07:00
|
|
|
err = netdev_upper_dev_link(real_dev, new_dev, NULL);
|
2017-03-24 20:22:45 +07:00
|
|
|
if (err)
|
|
|
|
goto out_unregister_netdev;
|
|
|
|
|
|
|
|
netif_stacked_transfer_operstate(real_dev, new_dev);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
out_unregister_netdev:
|
|
|
|
unregister_netdevice(new_dev);
|
|
|
|
dev_put(real_dev);
|
|
|
|
|
|
|
|
out_free_newdev:
|
|
|
|
free_netdev(new_dev);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2019-06-13 00:03:15 +07:00
|
|
|
static void qmimux_unregister_device(struct net_device *dev,
|
|
|
|
struct list_head *head)
|
2017-03-24 20:22:45 +07:00
|
|
|
{
|
|
|
|
struct qmimux_priv *priv = netdev_priv(dev);
|
|
|
|
struct net_device *real_dev = priv->real_dev;
|
|
|
|
|
2019-06-13 00:02:46 +07:00
|
|
|
free_percpu(priv->stats64);
|
2017-03-24 20:22:45 +07:00
|
|
|
netdev_upper_dev_unlink(real_dev, dev);
|
2019-06-13 00:03:15 +07:00
|
|
|
unregister_netdevice_queue(dev, head);
|
2017-03-24 20:22:45 +07:00
|
|
|
|
|
|
|
/* Get rid of the reference to real_dev */
|
|
|
|
dev_put(real_dev);
|
|
|
|
}
|
|
|
|
|
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 01:24:21 +07:00
|
|
|
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;
|
2017-12-07 02:21:24 +07:00
|
|
|
set_bit(EVENT_NO_IP_ALIGN, &dev->flags);
|
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 01:24:21 +07:00
|
|
|
netdev_dbg(net, "mode: raw IP\n");
|
|
|
|
} else if (!net->header_ops) { /* don't bother if already set */
|
|
|
|
ether_setup(net);
|
2017-12-07 02:21:24 +07:00
|
|
|
clear_bit(EVENT_NO_IP_ALIGN, &dev->flags);
|
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 01:24:21 +07:00
|
|
|
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 03:25:50 +07: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 01:24:21 +07:00
|
|
|
|
|
|
|
if (strtobool(buf, &enable))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* no change? */
|
|
|
|
if (enable == (info->flags & QMI_WWAN_FLAG_RAWIP))
|
|
|
|
return len;
|
|
|
|
|
2015-12-07 03:25:50 +07: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 01:24:21 +07: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 03:25:50 +07: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 01:24:21 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* let other drivers deny the change */
|
2015-12-07 03:25:50 +07: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 01:24:21 +07:00
|
|
|
netdev_err(dev->net, "Type change was refused\n");
|
2015-12-07 03:25:50 +07: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 01:24:21 +07: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 03:25:50 +07: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 01:24:21 +07:00
|
|
|
}
|
|
|
|
|
2017-03-24 20:22:45 +07:00
|
|
|
static ssize_t add_mux_show(struct device *d, struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
struct net_device *dev = to_net_dev(d);
|
|
|
|
struct qmimux_priv *priv;
|
|
|
|
struct list_head *iter;
|
|
|
|
struct net_device *ldev;
|
|
|
|
ssize_t count = 0;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
netdev_for_each_upper_dev_rcu(dev, ldev, iter) {
|
|
|
|
priv = netdev_priv(ldev);
|
|
|
|
count += scnprintf(&buf[count], PAGE_SIZE - count,
|
|
|
|
"0x%02x\n", priv->mux_id);
|
|
|
|
}
|
|
|
|
rcu_read_unlock();
|
|
|
|
return count;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t add_mux_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;
|
|
|
|
u8 mux_id;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (kstrtou8(buf, 0, &mux_id))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2019-06-13 00:03:50 +07:00
|
|
|
/* mux_id [1 - 254] for compatibility with ip(8) and the rmnet driver */
|
|
|
|
if (mux_id < 1 || mux_id > 254)
|
2017-03-24 20:22:45 +07:00
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!rtnl_trylock())
|
|
|
|
return restart_syscall();
|
|
|
|
|
|
|
|
if (qmimux_find_dev(dev, mux_id)) {
|
|
|
|
netdev_err(dev->net, "mux_id already present\n");
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* we don't want to modify a running netdev */
|
|
|
|
if (netif_running(dev->net)) {
|
|
|
|
netdev_err(dev->net, "Cannot change a running device\n");
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = qmimux_register_device(dev->net, mux_id);
|
|
|
|
if (!ret) {
|
|
|
|
info->flags |= QMI_WWAN_FLAG_MUX;
|
|
|
|
ret = len;
|
|
|
|
}
|
|
|
|
err:
|
|
|
|
rtnl_unlock();
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t del_mux_show(struct device *d, struct device_attribute *attr, char *buf)
|
|
|
|
{
|
|
|
|
return add_mux_show(d, attr, buf);
|
|
|
|
}
|
|
|
|
|
|
|
|
static ssize_t del_mux_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;
|
|
|
|
struct net_device *del_dev;
|
|
|
|
u8 mux_id;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
if (kstrtou8(buf, 0, &mux_id))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!rtnl_trylock())
|
|
|
|
return restart_syscall();
|
|
|
|
|
|
|
|
/* we don't want to modify a running netdev */
|
|
|
|
if (netif_running(dev->net)) {
|
|
|
|
netdev_err(dev->net, "Cannot change a running device\n");
|
|
|
|
ret = -EBUSY;
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
|
|
|
|
del_dev = qmimux_find_dev(dev, mux_id);
|
|
|
|
if (!del_dev) {
|
|
|
|
netdev_err(dev->net, "mux_id not present\n");
|
|
|
|
ret = -EINVAL;
|
|
|
|
goto err;
|
|
|
|
}
|
2019-06-13 00:03:15 +07:00
|
|
|
qmimux_unregister_device(del_dev, NULL);
|
2017-03-24 20:22:45 +07:00
|
|
|
|
|
|
|
if (!qmimux_has_slaves(dev))
|
|
|
|
info->flags &= ~QMI_WWAN_FLAG_MUX;
|
|
|
|
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 01:24:21 +07:00
|
|
|
static DEVICE_ATTR_RW(raw_ip);
|
2017-03-24 20:22:45 +07:00
|
|
|
static DEVICE_ATTR_RW(add_mux);
|
|
|
|
static DEVICE_ATTR_RW(del_mux);
|
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 01:24:21 +07:00
|
|
|
|
|
|
|
static struct attribute *qmi_wwan_sysfs_attrs[] = {
|
|
|
|
&dev_attr_raw_ip.attr,
|
2017-03-24 20:22:45 +07:00
|
|
|
&dev_attr_add_mux.attr,
|
|
|
|
&dev_attr_del_mux.attr,
|
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 01:24:21 +07:00
|
|
|
NULL,
|
|
|
|
};
|
|
|
|
|
|
|
|
static struct attribute_group qmi_wwan_sysfs_attr_group = {
|
|
|
|
.name = "qmi",
|
|
|
|
.attrs = qmi_wwan_sysfs_attrs,
|
|
|
|
};
|
|
|
|
|
2013-04-18 19:57:11 +07:00
|
|
|
/* default ethernet address used by the modem */
|
|
|
|
static const u8 default_modem_addr[ETH_ALEN] = {0x02, 0x50, 0xf3};
|
|
|
|
|
2015-01-02 22:21:45 +07:00
|
|
|
static const u8 buggy_fw_addr[ETH_ALEN] = {0x00, 0xa0, 0xc6, 0x00, 0x00, 0x00};
|
|
|
|
|
2013-04-18 19:57:09 +07: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 19:57:10 +07: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 19:57:09 +07: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 01:24:21 +07:00
|
|
|
struct qmi_wwan_state *info = (void *)&dev->data;
|
|
|
|
bool rawip = info->flags & QMI_WWAN_FLAG_RAWIP;
|
2013-04-18 19:57:09 +07:00
|
|
|
__be16 proto;
|
|
|
|
|
2014-02-13 23:50:19 +07:00
|
|
|
/* This check is no longer done by usbnet */
|
|
|
|
if (skb->len < dev->net->hard_header_len)
|
|
|
|
return 0;
|
|
|
|
|
2017-03-24 20:22:45 +07:00
|
|
|
if (info->flags & QMI_WWAN_FLAG_MUX)
|
|
|
|
return qmimux_rx_fixup(dev, skb);
|
|
|
|
|
2013-04-18 19:57:09 +07: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 19:57:10 +07: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 01:24:21 +07: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 19:57:10 +07: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 19:57:09 +07: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 01:24:21 +07:00
|
|
|
if (rawip)
|
|
|
|
return 0;
|
2013-04-18 19:57:09 +07: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 01:24:21 +07:00
|
|
|
if (rawip) {
|
2017-11-07 19:47:56 +07:00
|
|
|
skb_reset_mac_header(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 01:24:21 +07:00
|
|
|
skb->dev = dev->net; /* normally set by eth_type_trans */
|
|
|
|
skb->protocol = proto;
|
|
|
|
return 1;
|
|
|
|
}
|
|
|
|
|
2013-04-18 19:57:09 +07: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 10:54:48 +07: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 19:57:10 +07:00
|
|
|
fix_dest:
|
2013-04-18 19:57:09 +07: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,
|
2017-04-03 12:50:03 +07:00
|
|
|
.ndo_get_stats64 = usbnet_get_stats64,
|
2013-04-18 19:57:09 +07:00
|
|
|
.ndo_set_mac_address = qmi_wwan_mac_addr,
|
|
|
|
.ndo_validate_addr = eth_validate_addr,
|
|
|
|
};
|
|
|
|
|
2013-09-25 16:21:26 +07:00
|
|
|
/* using a counter to merge subdriver requests with our own into a
|
|
|
|
* combined state
|
|
|
|
*/
|
2012-06-19 07:42:00 +07:00
|
|
|
static int qmi_wwan_manage_power(struct usbnet *dev, int on)
|
|
|
|
{
|
|
|
|
struct qmi_wwan_state *info = (void *)&dev->data;
|
2013-11-01 20:18:53 +07:00
|
|
|
int rv;
|
2012-06-19 07:42:00 +07:00
|
|
|
|
2013-09-25 16:21:26 +07:00
|
|
|
dev_dbg(&dev->intf->dev, "%s() pmcount=%d, on=%d\n", __func__,
|
|
|
|
atomic_read(&info->pmcount), on);
|
2012-06-19 07:42:00 +07:00
|
|
|
|
2013-09-25 16:21:26 +07: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 07:42:00 +07:00
|
|
|
rv = usb_autopm_get_interface(dev->intf);
|
|
|
|
dev->intf->needs_remote_wakeup = on;
|
2013-11-01 20:18:53 +07:00
|
|
|
if (!rv)
|
|
|
|
usb_autopm_put_interface(dev->intf);
|
2012-06-19 07:42:00 +07:00
|
|
|
}
|
2013-11-01 20:18:53 +07:00
|
|
|
return 0;
|
2012-06-19 07:42:00 +07: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 07:37:00 +07:00
|
|
|
|
|
|
|
/* can be called while disconnecting */
|
|
|
|
if (!dev)
|
|
|
|
return 0;
|
2012-06-19 07:42:00 +07: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 16:21:26 +07:00
|
|
|
subdriver = usb_cdc_wdm_register(info->control, &dev->status->desc,
|
|
|
|
4096, &qmi_wwan_cdc_wdm_manage_power);
|
2012-06-19 07:42:00 +07: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 01:24:18 +07: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 22:37:22 +07: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 21:05:41 +07:00
|
|
|
struct usb_cdc_union_desc *cdc_union;
|
|
|
|
struct usb_cdc_ether_desc *cdc_ether;
|
2012-06-19 07:42:01 +07:00
|
|
|
struct usb_driver *driver = driver_of(intf);
|
2012-06-19 07:41:59 +07:00
|
|
|
struct qmi_wwan_state *info = (void *)&dev->data;
|
2015-09-07 21:05:41 +07:00
|
|
|
struct usb_cdc_parsed_header hdr;
|
2012-06-19 07:41:59 +07:00
|
|
|
|
2013-09-25 16:21:26 +07:00
|
|
|
BUILD_BUG_ON((sizeof(((struct usbnet *)0)->data) <
|
|
|
|
sizeof(struct qmi_wwan_state)));
|
2012-03-09 18:35:05 +07:00
|
|
|
|
2013-03-13 09:25:17 +07:00
|
|
|
/* set up initial state */
|
|
|
|
info->control = intf;
|
|
|
|
info->data = intf;
|
2012-01-19 22:37:22 +07:00
|
|
|
|
2012-09-07 14:36:07 +07:00
|
|
|
/* and a number of CDC descriptors */
|
2015-09-07 21:05:41 +07: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 22:37:22 +07:00
|
|
|
|
2013-03-13 09:25:17 +07:00
|
|
|
/* Use separate control and data interfaces if we found a CDC Union */
|
|
|
|
if (cdc_union) {
|
2013-09-25 16:21:26 +07: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 18:44:04 +07:00
|
|
|
|
|
|
|
/* ignore and continue... */
|
|
|
|
cdc_union = NULL;
|
|
|
|
info->data = intf;
|
2013-03-13 09:25:17 +07:00
|
|
|
}
|
2012-01-19 22:37:22 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/* errors aren't fatal - we can live with the dynamic address */
|
2017-11-06 21:32:18 +07:00
|
|
|
if (cdc_ether && cdc_ether->wMaxSegmentSize) {
|
2012-01-19 22:37:22 +07:00
|
|
|
dev->hard_mtu = le16_to_cpu(cdc_ether->wMaxSegmentSize);
|
|
|
|
usbnet_get_ethernet_addr(dev, cdc_ether->iMACAddress);
|
|
|
|
}
|
|
|
|
|
2012-06-19 07:42:01 +07:00
|
|
|
/* claim data interface and set it up */
|
2013-03-13 09:25:17 +07:00
|
|
|
if (info->control != info->data) {
|
|
|
|
status = usb_driver_claim_interface(driver, info->data, dev);
|
|
|
|
if (status < 0)
|
|
|
|
goto err;
|
|
|
|
}
|
2012-01-19 22:37:22 +07:00
|
|
|
|
2012-06-19 07:42:01 +07:00
|
|
|
status = qmi_wwan_register_subdriver(dev);
|
2012-09-07 14:36:07 +07:00
|
|
|
if (status < 0 && info->control != info->data) {
|
2012-06-19 07:42:01 +07:00
|
|
|
usb_set_intfdata(info->data, NULL);
|
|
|
|
usb_driver_release_interface(driver, info->data);
|
|
|
|
}
|
2012-01-19 22:37:22 +07:00
|
|
|
|
2015-12-04 01:24:18 +07: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
|
2016-10-11 02:12:49 +07:00
|
|
|
* this fact to enable the quirk for all USB3 devices.
|
|
|
|
*
|
|
|
|
* There are also chipsets with the same "set DTR" requirement
|
|
|
|
* but without USB3 support. Devices based on these chips
|
|
|
|
* need a quirk flag in the device ID table.
|
2015-12-04 01:24:18 +07:00
|
|
|
*/
|
2016-10-11 02:12:49 +07:00
|
|
|
if (dev->driver_info->data & QMI_WWAN_QUIRK_DTR ||
|
|
|
|
le16_to_cpu(dev->udev->descriptor.bcdUSB) >= 0x0201) {
|
2015-12-04 01:24:18 +07:00
|
|
|
qmi_wwan_manage_power(dev, 1);
|
|
|
|
qmi_wwan_change_dtr(dev, true);
|
|
|
|
}
|
|
|
|
|
2015-01-02 22:21:45 +07: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 19:57:11 +07:00
|
|
|
*/
|
2015-01-02 22:21:45 +07: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 19:57:11 +07:00
|
|
|
eth_hw_addr_random(dev->net);
|
|
|
|
|
2013-04-18 19:57:09 +07: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 01:24:21 +07:00
|
|
|
dev->net->sysfs_groups[0] = &qmi_wwan_sysfs_attr_group;
|
2012-01-19 22:37:22 +07:00
|
|
|
err:
|
|
|
|
return status;
|
|
|
|
}
|
|
|
|
|
2012-06-19 07:42:01 +07:00
|
|
|
static void qmi_wwan_unbind(struct usbnet *dev, struct usb_interface *intf)
|
2012-03-09 18:35:05 +07:00
|
|
|
{
|
2012-06-19 07:41:59 +07:00
|
|
|
struct qmi_wwan_state *info = (void *)&dev->data;
|
2012-06-19 07:42:01 +07:00
|
|
|
struct usb_driver *driver = driver_of(intf);
|
|
|
|
struct usb_interface *other;
|
2012-03-09 18:35:05 +07:00
|
|
|
|
2012-06-19 07:41:59 +07:00
|
|
|
if (info->subdriver && info->subdriver->disconnect)
|
2012-06-19 07:42:01 +07:00
|
|
|
info->subdriver->disconnect(info->control);
|
|
|
|
|
2015-12-04 01:24:18 +07: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 07:42:01 +07: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 18:35:05 +07:00
|
|
|
|
2012-06-19 07:41:59 +07:00
|
|
|
info->subdriver = NULL;
|
2012-06-19 07:42:01 +07:00
|
|
|
info->data = NULL;
|
|
|
|
info->control = NULL;
|
2012-03-09 18:35:05 +07: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 07:41:59 +07:00
|
|
|
struct qmi_wwan_state *info = (void *)&dev->data;
|
2012-03-09 18:35:05 +07:00
|
|
|
int ret;
|
|
|
|
|
2013-09-25 16:21:26 +07:00
|
|
|
/* Both usbnet_suspend() and subdriver->suspend() MUST return 0
|
2013-03-15 11:08:57 +07:00
|
|
|
* in system sleep context, otherwise, the resume callback has
|
|
|
|
* to recover device from previous suspend failure.
|
|
|
|
*/
|
2012-03-09 18:35:05 +07:00
|
|
|
ret = usbnet_suspend(intf, message);
|
|
|
|
if (ret < 0)
|
|
|
|
goto err;
|
|
|
|
|
2013-09-25 16:21:26 +07:00
|
|
|
if (intf == info->control && info->subdriver &&
|
|
|
|
info->subdriver->suspend)
|
2012-06-19 07:41:59 +07:00
|
|
|
ret = info->subdriver->suspend(intf, message);
|
2012-03-09 18:35:05 +07: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 07:41:59 +07:00
|
|
|
struct qmi_wwan_state *info = (void *)&dev->data;
|
2012-03-09 18:35:05 +07:00
|
|
|
int ret = 0;
|
2013-09-25 16:21:26 +07:00
|
|
|
bool callsub = (intf == info->control && info->subdriver &&
|
|
|
|
info->subdriver->resume);
|
2012-03-09 18:35:05 +07:00
|
|
|
|
2012-09-13 03:44:35 +07:00
|
|
|
if (callsub)
|
2012-06-19 07:41:59 +07:00
|
|
|
ret = info->subdriver->resume(intf);
|
2012-03-09 18:35:05 +07:00
|
|
|
if (ret < 0)
|
|
|
|
goto err;
|
|
|
|
ret = usbnet_resume(intf);
|
2013-11-01 20:18:54 +07:00
|
|
|
if (ret < 0 && callsub)
|
2012-06-19 07:41:59 +07:00
|
|
|
info->subdriver->suspend(intf, PMSG_SUSPEND);
|
2012-03-09 18:35:05 +07:00
|
|
|
err:
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-01-19 22:37:22 +07:00
|
|
|
static const struct driver_info qmi_wwan_info = {
|
2012-06-19 07:42:02 +07:00
|
|
|
.description = "WWAN/QMI device",
|
2017-12-15 01:55:50 +07:00
|
|
|
.flags = FLAG_WWAN | FLAG_SEND_ZLP,
|
2012-01-19 22:37:22 +07:00
|
|
|
.bind = qmi_wwan_bind,
|
2012-06-19 07:42:01 +07:00
|
|
|
.unbind = qmi_wwan_unbind,
|
2012-01-19 22:37:22 +07:00
|
|
|
.manage_power = qmi_wwan_manage_power,
|
2013-04-18 19:57:09 +07:00
|
|
|
.rx_fixup = qmi_wwan_rx_fixup,
|
2012-01-19 22:37:22 +07:00
|
|
|
};
|
|
|
|
|
2016-10-11 02:12:49 +07:00
|
|
|
static const struct driver_info qmi_wwan_info_quirk_dtr = {
|
|
|
|
.description = "WWAN/QMI device",
|
2017-12-15 01:55:50 +07:00
|
|
|
.flags = FLAG_WWAN | FLAG_SEND_ZLP,
|
2016-10-11 02:12:49 +07:00
|
|
|
.bind = qmi_wwan_bind,
|
|
|
|
.unbind = qmi_wwan_unbind,
|
|
|
|
.manage_power = qmi_wwan_manage_power,
|
|
|
|
.rx_fixup = qmi_wwan_rx_fixup,
|
|
|
|
.data = QMI_WWAN_QUIRK_DTR,
|
|
|
|
};
|
|
|
|
|
qmi_wwan: Add quirk for Quectel dynamic config
Most, if not all, Quectel devices use dynamic interface numbers, and
users are able to change the USB configuration at will. Matching on for
example interface number is therefore not possible.
Instead, the QMI device can be identified by looking at the interface
class, subclass and protocol (all 0xff), as well as the number of
endpoints. The reason we need to look at the number of endpoints, is
that the diagnostic port interface has the same class, subclass and
protocol as QMI. However, the diagnostic port only has two endpoints,
while QMI has three.
Until now, we have identified the QMI device by combining a match on
class, subclass and protocol, with a call to the function
quectel_diag_detect(). In quectel_diag_detect(), we check if the number
of endpoints matches for known Quectel vendor/product ids.
Adding new vendor/product ids to quectel_diag_detect() is not a good
long-term solution. This commit replaces the function with a quirk, and
applies the quirk to affected Quectel devices that I have been able to
test the change with (EP06, EM12 and EC25). If the quirk is set and the
number of endpoints equal two, we return from qmi_wwan_probe() with
-ENODEV.
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-07 20:39:09 +07:00
|
|
|
static const struct driver_info qmi_wwan_info_quirk_quectel_dyncfg = {
|
|
|
|
.description = "WWAN/QMI device",
|
|
|
|
.flags = FLAG_WWAN | FLAG_SEND_ZLP,
|
|
|
|
.bind = qmi_wwan_bind,
|
|
|
|
.unbind = qmi_wwan_unbind,
|
|
|
|
.manage_power = qmi_wwan_manage_power,
|
|
|
|
.rx_fixup = qmi_wwan_rx_fixup,
|
|
|
|
.data = QMI_WWAN_QUIRK_DTR | QMI_WWAN_QUIRK_QUECTEL_DYNCFG,
|
|
|
|
};
|
|
|
|
|
2012-01-19 22:37:22 +07:00
|
|
|
#define HUAWEI_VENDOR_ID 0x12D1
|
2012-06-21 09:45:58 +07:00
|
|
|
|
2012-08-12 16:16:30 +07: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 14:36:07 +07:00
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info
|
2012-08-12 16:16:30 +07:00
|
|
|
|
2016-10-11 02:12:49 +07:00
|
|
|
/* devices requiring "set DTR" quirk */
|
|
|
|
#define QMI_QUIRK_SET_DTR(vend, prod, num) \
|
|
|
|
USB_DEVICE_INTERFACE_NUMBER(vend, prod, num), \
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info_quirk_dtr
|
|
|
|
|
2012-06-21 09:45:58 +07:00
|
|
|
/* Gobi 1000 QMI/wwan interface number is 3 according to qcserial */
|
|
|
|
#define QMI_GOBI1K_DEVICE(vend, prod) \
|
2012-08-12 16:16:30 +07:00
|
|
|
QMI_FIXED_INTF(vend, prod, 3)
|
2012-06-21 09:45:58 +07:00
|
|
|
|
2012-08-12 16:16:30 +07:00
|
|
|
/* Gobi 2000/3000 QMI/wwan interface number is 0 according to qcserial */
|
2012-03-09 18:35:06 +07:00
|
|
|
#define QMI_GOBI_DEVICE(vend, prod) \
|
2012-08-12 16:16:30 +07:00
|
|
|
QMI_FIXED_INTF(vend, prod, 0)
|
2012-01-19 22:37:22 +07:00
|
|
|
|
qmi_wwan: Add quirk for Quectel dynamic config
Most, if not all, Quectel devices use dynamic interface numbers, and
users are able to change the USB configuration at will. Matching on for
example interface number is therefore not possible.
Instead, the QMI device can be identified by looking at the interface
class, subclass and protocol (all 0xff), as well as the number of
endpoints. The reason we need to look at the number of endpoints, is
that the diagnostic port interface has the same class, subclass and
protocol as QMI. However, the diagnostic port only has two endpoints,
while QMI has three.
Until now, we have identified the QMI device by combining a match on
class, subclass and protocol, with a call to the function
quectel_diag_detect(). In quectel_diag_detect(), we check if the number
of endpoints matches for known Quectel vendor/product ids.
Adding new vendor/product ids to quectel_diag_detect() is not a good
long-term solution. This commit replaces the function with a quirk, and
applies the quirk to affected Quectel devices that I have been able to
test the change with (EP06, EM12 and EC25). If the quirk is set and the
number of endpoints equal two, we return from qmi_wwan_probe() with
-ENODEV.
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-07 20:39:09 +07:00
|
|
|
/* Quectel does not use fixed interface numbers on at least some of their
|
|
|
|
* devices. We need to check the number of endpoints to ensure that we bind to
|
|
|
|
* the correct interface.
|
|
|
|
*/
|
|
|
|
#define QMI_QUIRK_QUECTEL_DYNCFG(vend, prod) \
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(vend, prod, USB_CLASS_VENDOR_SPEC, \
|
|
|
|
USB_SUBCLASS_VENDOR_SPEC, 0xff), \
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info_quirk_quectel_dyncfg
|
|
|
|
|
2012-01-19 22:37:22 +07:00
|
|
|
static const struct usb_device_id products[] = {
|
2012-08-12 16:16:30 +07:00
|
|
|
/* 1. CDC ECM like devices match on the control interface */
|
2012-03-09 18:35:05 +07:00
|
|
|
{ /* Huawei E392, E398 and possibly others sharing both device id and more... */
|
2012-08-12 16:16:32 +07:00
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 9),
|
2012-03-09 18:35:05 +07:00
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
2012-05-19 14:20:31 +07:00
|
|
|
{ /* Vodafone/Huawei K5005 (12d1:14c8) and similar modems */
|
2012-08-12 16:16:32 +07:00
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 57),
|
2012-05-19 14:20:31 +07:00
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
2013-02-06 12:22:08 +07: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,
|
|
|
|
},
|
2017-03-19 23:19:57 +07:00
|
|
|
{ /* Motorola Mapphone devices with MDM6600 */
|
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(0x22b8, USB_CLASS_VENDOR_SPEC, 0xfb, 0xff),
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
2012-08-12 16:16:30 +07:00
|
|
|
|
|
|
|
/* 2. Combined interface devices matching on class+protocol */
|
2012-09-19 17:03:36 +07:00
|
|
|
{ /* Huawei E367 and possibly others in "Windows mode" */
|
2012-09-20 04:18:05 +07: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 16:16:30 +07:00
|
|
|
{ /* Huawei E392, E398 and possibly others in "Windows mode" */
|
2012-08-12 16:16:32 +07:00
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 1, 17),
|
2012-09-07 14:36:07 +07:00
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
2012-03-09 18:35:05 +07:00
|
|
|
},
|
2013-02-06 12:22:08 +07: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 17:03:36 +07:00
|
|
|
{ /* Pantech UML290, P4200 and more */
|
2012-09-20 04:18:05 +07:00
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC, 0xf0, 0xff),
|
2012-09-07 14:36:07 +07:00
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
2012-03-09 18:35:06 +07:00
|
|
|
},
|
2012-08-15 10:42:57 +07:00
|
|
|
{ /* Pantech UML290 - newer firmware */
|
2012-09-20 04:18:05 +07:00
|
|
|
USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC, 0xf1, 0xff),
|
2012-09-07 14:36:07 +07:00
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
2012-08-15 10:42:57 +07:00
|
|
|
},
|
2012-10-24 19:10:34 +07: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 18:07:18 +07: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 15:17:41 +07: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 00:25:09 +07:00
|
|
|
USB_CDC_SUBCLASS_ETHERNET,
|
|
|
|
USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
2013-05-06 18:17:37 +07: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 00:25:09 +07:00
|
|
|
{ /* ADU960S */
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(0x16d5, 0x650a,
|
|
|
|
USB_CLASS_COMM,
|
2012-12-17 15:17:41 +07:00
|
|
|
USB_CDC_SUBCLASS_ETHERNET,
|
|
|
|
USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
2017-01-24 16:45:38 +07:00
|
|
|
{ /* HP lt2523 (Novatel E371) */
|
|
|
|
USB_DEVICE_AND_INTERFACE_INFO(0x03f0, 0x421d,
|
|
|
|
USB_CLASS_COMM,
|
|
|
|
USB_CDC_SUBCLASS_ETHERNET,
|
|
|
|
USB_CDC_PROTO_NONE),
|
|
|
|
.driver_info = (unsigned long)&qmi_wwan_info,
|
|
|
|
},
|
2015-11-01 07:34:50 +07: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,
|
|
|
|
},
|
qmi_wwan: Add quirk for Quectel dynamic config
Most, if not all, Quectel devices use dynamic interface numbers, and
users are able to change the USB configuration at will. Matching on for
example interface number is therefore not possible.
Instead, the QMI device can be identified by looking at the interface
class, subclass and protocol (all 0xff), as well as the number of
endpoints. The reason we need to look at the number of endpoints, is
that the diagnostic port interface has the same class, subclass and
protocol as QMI. However, the diagnostic port only has two endpoints,
while QMI has three.
Until now, we have identified the QMI device by combining a match on
class, subclass and protocol, with a call to the function
quectel_diag_detect(). In quectel_diag_detect(), we check if the number
of endpoints matches for known Quectel vendor/product ids.
Adding new vendor/product ids to quectel_diag_detect() is not a good
long-term solution. This commit replaces the function with a quirk, and
applies the quirk to affected Quectel devices that I have been able to
test the change with (EP06, EM12 and EC25). If the quirk is set and the
number of endpoints equal two, we return from qmi_wwan_probe() with
-ENODEV.
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-07 20:39:09 +07:00
|
|
|
{QMI_QUIRK_QUECTEL_DYNCFG(0x2c7c, 0x0125)}, /* Quectel EC25, EC20 R2.0 Mini PCIe */
|
|
|
|
{QMI_QUIRK_QUECTEL_DYNCFG(0x2c7c, 0x0306)}, /* Quectel EP06/EG06/EM06 */
|
|
|
|
{QMI_QUIRK_QUECTEL_DYNCFG(0x2c7c, 0x0512)}, /* Quectel EG12/EM12 */
|
2012-06-21 09:45:58 +07:00
|
|
|
|
2012-08-12 16:16:30 +07:00
|
|
|
/* 3. Combined interface devices matching on interface number */
|
2013-02-12 09:42:50 +07:00
|
|
|
{QMI_FIXED_INTF(0x0408, 0xea42, 4)}, /* Yota / Megafon M100-1 */
|
2016-02-12 22:42:14 +07:00
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x6001, 3)}, /* 4G LTE usb-modem U901 */
|
2013-09-10 20:06:20 +07: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)},
|
2018-04-26 13:30:13 +07:00
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x90b2, 3)}, /* ublox R410M */
|
2013-09-10 20:06:20 +07:00
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x920d, 0)},
|
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x920d, 5)},
|
2017-12-29 16:02:17 +07:00
|
|
|
{QMI_QUIRK_SET_DTR(0x05c6, 0x9625, 4)}, /* YUGA CLM920-NC5 */
|
2014-07-17 18:33:51 +07:00
|
|
|
{QMI_FIXED_INTF(0x0846, 0x68a2, 8)},
|
2018-05-28 07:10:41 +07:00
|
|
|
{QMI_FIXED_INTF(0x0846, 0x68d3, 8)}, /* Netgear Aircard 779S */
|
2012-11-25 13:03:59 +07: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 17:57:02 +07:00
|
|
|
{QMI_FIXED_INTF(0x12d1, 0x14ac, 1)}, /* Huawei E1820 */
|
2019-04-25 00:12:46 +07:00
|
|
|
{QMI_FIXED_INTF(0x1435, 0x0918, 3)}, /* Wistron NeWeb D16Q1 */
|
|
|
|
{QMI_FIXED_INTF(0x1435, 0x0918, 4)}, /* Wistron NeWeb D16Q1 */
|
|
|
|
{QMI_FIXED_INTF(0x1435, 0x0918, 5)}, /* Wistron NeWeb D16Q1 */
|
|
|
|
{QMI_FIXED_INTF(0x1435, 0x3185, 4)}, /* Wistron NeWeb M18Q5 */
|
|
|
|
{QMI_FIXED_INTF(0x1435, 0xd111, 4)}, /* M9615A DM11-1 D51QC */
|
2018-03-26 21:34:39 +07:00
|
|
|
{QMI_FIXED_INTF(0x1435, 0xd181, 3)}, /* Wistron NeWeb D18Q1 */
|
|
|
|
{QMI_FIXED_INTF(0x1435, 0xd181, 4)}, /* Wistron NeWeb D18Q1 */
|
|
|
|
{QMI_FIXED_INTF(0x1435, 0xd181, 5)}, /* Wistron NeWeb D18Q1 */
|
2019-04-25 00:12:46 +07:00
|
|
|
{QMI_FIXED_INTF(0x1435, 0xd182, 4)}, /* Wistron NeWeb D18 */
|
|
|
|
{QMI_FIXED_INTF(0x1435, 0xd182, 5)}, /* Wistron NeWeb D18 */
|
2018-04-18 21:03:24 +07:00
|
|
|
{QMI_FIXED_INTF(0x1435, 0xd191, 4)}, /* Wistron NeWeb D19Q1 */
|
2018-12-13 04:45:34 +07:00
|
|
|
{QMI_QUIRK_SET_DTR(0x1508, 0x1001, 4)}, /* Fibocom NL668 series */
|
2014-04-26 00:00:33 +07: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 12:11:29 +07:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0002, 1)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0012, 1)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0017, 3)},
|
2013-06-29 20:39:19 +07: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 12:11:29 +07: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 16:16:30 +07: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 12:11:29 +07:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0058, 4)},
|
2012-08-12 16:16:30 +07: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 12:11:29 +07: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 04:18:05 +07: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 12:11:29 +07:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0158, 3)},
|
2012-08-12 16:16:30 +07: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 12:11:29 +07: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 11:26:34 +07:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0265, 4)}, /* ONDA MT8205 4G LTE */
|
2012-12-19 11:15:51 +07:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0284, 4)}, /* ZTE MF880 */
|
2012-08-12 16:16:30 +07:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0326, 4)}, /* ZTE MF821D */
|
2019-04-25 00:12:46 +07:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0396, 3)}, /* ZTE ZM8620 */
|
2013-05-03 06:05:13 +07:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x0412, 4)}, /* Telewell TW-LTE 4G */
|
2012-08-12 16:16:30 +07: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 12:11:29 +07:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1012, 4)},
|
2012-08-15 10:42:57 +07: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 12:11:29 +07: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 04:01:02 +07: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 12:11:29 +07:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1401, 2)},
|
2012-08-12 16:16:30 +07: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 12:11:29 +07:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1424, 2)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1425, 2)},
|
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1426, 2)}, /* ZTE MF91 */
|
2014-07-02 02:01:09 +07:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1428, 2)}, /* Telewell TW-LTE 4G v2 */
|
2019-04-25 00:12:46 +07:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x1432, 3)}, /* ZTE ME3620 */
|
2012-08-12 16:16:30 +07:00
|
|
|
{QMI_FIXED_INTF(0x19d2, 0x2002, 4)}, /* ZTE (Vodafone) K3765-Z */
|
2019-04-25 00:12:46 +07:00
|
|
|
{QMI_FIXED_INTF(0x2001, 0x7e16, 3)}, /* D-Link DWM-221 */
|
2016-03-29 03:38:16 +07:00
|
|
|
{QMI_FIXED_INTF(0x2001, 0x7e19, 4)}, /* D-Link DWM-221 B1 */
|
2017-08-01 22:45:44 +07:00
|
|
|
{QMI_FIXED_INTF(0x2001, 0x7e35, 4)}, /* D-Link DWM-222 */
|
2019-07-17 16:14:33 +07:00
|
|
|
{QMI_FIXED_INTF(0x2001, 0x7e3d, 4)}, /* D-Link DWM-222 A2 */
|
2019-03-27 21:26:01 +07:00
|
|
|
{QMI_FIXED_INTF(0x2020, 0x2031, 4)}, /* Olicard 600 */
|
2018-03-25 04:08:14 +07:00
|
|
|
{QMI_FIXED_INTF(0x2020, 0x2033, 4)}, /* BroadMobi BM806U */
|
2012-08-12 16:16:31 +07:00
|
|
|
{QMI_FIXED_INTF(0x0f3d, 0x68a2, 8)}, /* Sierra Wireless MC7700 */
|
|
|
|
{QMI_FIXED_INTF(0x114f, 0x68a2, 8)}, /* Sierra Wireless MC7750 */
|
2012-08-12 16:16:30 +07: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 */
|
2019-02-15 19:20:42 +07:00
|
|
|
{QMI_QUIRK_SET_DTR(0x1199, 0x68c0, 8)}, /* Sierra Wireless MC7304/MC7354, WP76xx */
|
|
|
|
{QMI_QUIRK_SET_DTR(0x1199, 0x68c0, 10)},/* Sierra Wireless MC7304/MC7354 */
|
2012-08-12 16:16:31 +07:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x901c, 8)}, /* Sierra Wireless EM7700 */
|
2014-04-26 00:00:28 +07:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x901f, 8)}, /* Sierra Wireless EM7355 */
|
2014-04-26 00:00:30 +07:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9041, 8)}, /* Sierra Wireless MC7305/MC7355 */
|
2015-07-17 04:28:14 +07:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9041, 10)}, /* Sierra Wireless MC7305/MC7355 */
|
2014-02-04 19:04:33 +07:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9051, 8)}, /* Netgear AirCard 340U */
|
2014-05-29 18:44:45 +07:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9053, 8)}, /* Sierra Wireless Modem */
|
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9054, 8)}, /* Sierra Wireless Modem */
|
2014-05-29 02:05:03 +07:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9055, 8)}, /* Netgear AirCard 341U */
|
2014-05-29 18:44:45 +07:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9056, 8)}, /* Sierra Wireless Modem */
|
2014-07-17 18:33:51 +07:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9057, 8)},
|
2014-05-29 18:44:45 +07:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9061, 8)}, /* Sierra Wireless Modem */
|
2017-06-14 00:10:18 +07:00
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9063, 8)}, /* Sierra Wireless EM7305 */
|
|
|
|
{QMI_FIXED_INTF(0x1199, 0x9063, 10)}, /* Sierra Wireless EM7305 */
|
2018-09-18 03:00:24 +07:00
|
|
|
{QMI_QUIRK_SET_DTR(0x1199, 0x9071, 8)}, /* Sierra Wireless MC74xx */
|
|
|
|
{QMI_QUIRK_SET_DTR(0x1199, 0x9071, 10)},/* Sierra Wireless MC74xx */
|
|
|
|
{QMI_QUIRK_SET_DTR(0x1199, 0x9079, 8)}, /* Sierra Wireless EM74xx */
|
|
|
|
{QMI_QUIRK_SET_DTR(0x1199, 0x9079, 10)},/* Sierra Wireless EM74xx */
|
|
|
|
{QMI_QUIRK_SET_DTR(0x1199, 0x907b, 8)}, /* Sierra Wireless EM74xx */
|
|
|
|
{QMI_QUIRK_SET_DTR(0x1199, 0x907b, 10)},/* Sierra Wireless EM74xx */
|
|
|
|
{QMI_QUIRK_SET_DTR(0x1199, 0x9091, 8)}, /* Sierra Wireless EM7565 */
|
2012-12-28 13:30:55 +07:00
|
|
|
{QMI_FIXED_INTF(0x1bbb, 0x011e, 4)}, /* Telekom Speedstick LTE II (Alcatel One Touch L100V LTE) */
|
2014-04-26 00:00:32 +07:00
|
|
|
{QMI_FIXED_INTF(0x1bbb, 0x0203, 2)}, /* Alcatel L800MA */
|
2013-01-15 06:19:50 +07:00
|
|
|
{QMI_FIXED_INTF(0x2357, 0x0201, 4)}, /* TP-LINK HSUPA Modem MA180 */
|
2013-06-28 22:17:51 +07:00
|
|
|
{QMI_FIXED_INTF(0x2357, 0x9000, 4)}, /* TP-LINK MA260 */
|
2016-12-01 22:52:05 +07:00
|
|
|
{QMI_QUIRK_SET_DTR(0x1bc7, 0x1040, 2)}, /* Telit LE922A */
|
2017-05-03 15:30:11 +07:00
|
|
|
{QMI_FIXED_INTF(0x1bc7, 0x1100, 3)}, /* Telit ME910 */
|
2017-12-14 22:56:14 +07:00
|
|
|
{QMI_FIXED_INTF(0x1bc7, 0x1101, 3)}, /* Telit ME910 dual modem */
|
2013-01-30 09:47:06 +07:00
|
|
|
{QMI_FIXED_INTF(0x1bc7, 0x1200, 5)}, /* Telit LE920 */
|
2017-04-10 22:34:23 +07:00
|
|
|
{QMI_QUIRK_SET_DTR(0x1bc7, 0x1201, 2)}, /* Telit LE920, LE920A4 */
|
2019-05-15 22:29:43 +07:00
|
|
|
{QMI_QUIRK_SET_DTR(0x1bc7, 0x1260, 2)}, /* Telit LE910Cx */
|
|
|
|
{QMI_QUIRK_SET_DTR(0x1bc7, 0x1261, 2)}, /* Telit LE910Cx */
|
2018-12-13 23:00:35 +07:00
|
|
|
{QMI_QUIRK_SET_DTR(0x1bc7, 0x1900, 1)}, /* Telit LN940 series */
|
2017-06-14 00:10:18 +07:00
|
|
|
{QMI_FIXED_INTF(0x1c9e, 0x9801, 3)}, /* Telewell TW-3G HSPA+ */
|
|
|
|
{QMI_FIXED_INTF(0x1c9e, 0x9803, 4)}, /* Telewell TW-3G HSPA+ */
|
2015-11-19 03:13:07 +07:00
|
|
|
{QMI_FIXED_INTF(0x1c9e, 0x9b01, 3)}, /* XS Stick W100-2 from 4G Systems */
|
2014-06-06 22:27:59 +07: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 00:00:31 +07:00
|
|
|
{QMI_FIXED_INTF(0x0b3c, 0xc00b, 4)}, /* Olivetti Olicard 500 */
|
2013-09-25 22:02:36 +07:00
|
|
|
{QMI_FIXED_INTF(0x1e2d, 0x0060, 4)}, /* Cinterion PLxx */
|
2014-02-12 21:55:14 +07:00
|
|
|
{QMI_FIXED_INTF(0x1e2d, 0x0053, 4)}, /* Cinterion PHxx,PXxx */
|
2018-10-11 01:05:53 +07:00
|
|
|
{QMI_FIXED_INTF(0x1e2d, 0x0063, 10)}, /* Cinterion ALASxx (1 RmNet) */
|
2016-03-17 17:07:56 +07: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 00:00:34 +07: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 15:14:13 +07:00
|
|
|
{QMI_FIXED_INTF(0x413c, 0x81b1, 8)}, /* Dell Wireless 5809e Gobi(TM) 4G LTE Mobile Broadband Card */
|
2016-02-21 00:49:40 +07:00
|
|
|
{QMI_FIXED_INTF(0x413c, 0x81b3, 8)}, /* Dell Wireless 5809e Gobi(TM) 4G LTE Mobile Broadband Card (rev3) */
|
2017-03-17 23:20:48 +07:00
|
|
|
{QMI_FIXED_INTF(0x413c, 0x81b6, 8)}, /* Dell Wireless 5811e */
|
|
|
|
{QMI_FIXED_INTF(0x413c, 0x81b6, 10)}, /* Dell Wireless 5811e */
|
2018-07-24 06:31:07 +07:00
|
|
|
{QMI_FIXED_INTF(0x413c, 0x81d7, 0)}, /* Dell Wireless 5821e */
|
2015-08-16 07:12:30 +07:00
|
|
|
{QMI_FIXED_INTF(0x03f0, 0x4e1d, 8)}, /* HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module */
|
2018-03-26 12:19:57 +07:00
|
|
|
{QMI_FIXED_INTF(0x03f0, 0x9d1d, 1)}, /* HP lt4120 Snapdragon X5 LTE */
|
2016-01-06 20:15:50 +07:00
|
|
|
{QMI_FIXED_INTF(0x22de, 0x9061, 3)}, /* WeTelecom WPD-600N */
|
2018-05-25 20:00:20 +07:00
|
|
|
{QMI_QUIRK_SET_DTR(0x1e0e, 0x9001, 5)}, /* SIMCom 7100E, 7230E, 7600E ++ */
|
2016-10-11 02:12:49 +07:00
|
|
|
{QMI_QUIRK_SET_DTR(0x2c7c, 0x0121, 4)}, /* Quectel EC21 Mini PCIe */
|
2018-07-04 23:12:48 +07:00
|
|
|
{QMI_QUIRK_SET_DTR(0x2c7c, 0x0191, 4)}, /* Quectel EG91 */
|
2017-11-21 01:05:17 +07:00
|
|
|
{QMI_FIXED_INTF(0x2c7c, 0x0296, 4)}, /* Quectel BG96 */
|
2018-12-21 21:38:52 +07:00
|
|
|
{QMI_QUIRK_SET_DTR(0x2cb7, 0x0104, 4)}, /* Fibocom NL678 series */
|
2012-08-12 16:16:30 +07:00
|
|
|
|
|
|
|
/* 4. Gobi 1000 devices */
|
2012-06-21 09:45:58 +07: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 04:10:59 +07: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 09:45:58 +07: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 16:16:30 +07:00
|
|
|
/* 5. Gobi 2000 and 3000 devices */
|
2012-03-09 18:35:06 +07:00
|
|
|
{QMI_GOBI_DEVICE(0x413c, 0x8186)}, /* Dell Gobi 2000 Modem device (N0218, VU936) */
|
2012-09-01 10:47:26 +07:00
|
|
|
{QMI_GOBI_DEVICE(0x413c, 0x8194)}, /* Dell Gobi 3000 Composite */
|
2012-03-09 18:35:06 +07: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 18:55:01 +07:00
|
|
|
{QMI_FIXED_INTF(0x05c6, 0x9215, 4)}, /* Quectel EC20 Mini PCIe */
|
2012-03-09 18:35:06 +07: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 22:17:50 +07:00
|
|
|
{QMI_GOBI_DEVICE(0x0af0, 0x8120)}, /* Option GTM681W */
|
2012-08-12 16:16:31 +07:00
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x68a5)}, /* Sierra Wireless Modem */
|
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x68a9)}, /* Sierra Wireless Modem */
|
2012-03-09 18:35:06 +07: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 14:02:59 +07:00
|
|
|
{QMI_GOBI_DEVICE(0x03f0, 0x371d)}, /* HP un2430 Mobile Broadband Module */
|
2012-05-24 06:19:32 +07: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 16:16:31 +07:00
|
|
|
{QMI_GOBI_DEVICE(0x1199, 0x901b)}, /* Sierra Wireless MC7770 */
|
2012-09-01 10:47:26 +07:00
|
|
|
{QMI_GOBI_DEVICE(0x12d1, 0x14f1)}, /* Sony Gobi 3000 Composite */
|
2012-08-28 09:30:32 +07:00
|
|
|
{QMI_GOBI_DEVICE(0x1410, 0xa021)}, /* Foxconn Gobi 3000 Modem device (Novatel E396) */
|
2012-08-12 16:16:31 +07:00
|
|
|
|
2012-03-09 18:35:06 +07:00
|
|
|
{ } /* END */
|
2012-01-19 22:37:22 +07:00
|
|
|
};
|
|
|
|
MODULE_DEVICE_TABLE(usb, products);
|
|
|
|
|
2015-11-05 18:55:01 +07: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 16:21:26 +07:00
|
|
|
static int qmi_wwan_probe(struct usb_interface *intf,
|
|
|
|
const struct usb_device_id *prod)
|
2012-07-17 18:14:32 +07:00
|
|
|
{
|
|
|
|
struct usb_device_id *id = (struct usb_device_id *)prod;
|
2015-11-05 18:55:01 +07:00
|
|
|
struct usb_interface_descriptor *desc = &intf->cur_altsetting->desc;
|
qmi_wwan: Add quirk for Quectel dynamic config
Most, if not all, Quectel devices use dynamic interface numbers, and
users are able to change the USB configuration at will. Matching on for
example interface number is therefore not possible.
Instead, the QMI device can be identified by looking at the interface
class, subclass and protocol (all 0xff), as well as the number of
endpoints. The reason we need to look at the number of endpoints, is
that the diagnostic port interface has the same class, subclass and
protocol as QMI. However, the diagnostic port only has two endpoints,
while QMI has three.
Until now, we have identified the QMI device by combining a match on
class, subclass and protocol, with a call to the function
quectel_diag_detect(). In quectel_diag_detect(), we check if the number
of endpoints matches for known Quectel vendor/product ids.
Adding new vendor/product ids to quectel_diag_detect() is not a good
long-term solution. This commit replaces the function with a quirk, and
applies the quirk to affected Quectel devices that I have been able to
test the change with (EP06, EM12 and EC25). If the quirk is set and the
number of endpoints equal two, we return from qmi_wwan_probe() with
-ENODEV.
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-07 20:39:09 +07:00
|
|
|
const struct driver_info *info;
|
2012-07-17 18:14:32 +07: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 14:36:07 +07:00
|
|
|
id->driver_info = (unsigned long)&qmi_wwan_info;
|
2012-07-17 18:14:32 +07:00
|
|
|
}
|
|
|
|
|
2018-05-03 03:22:54 +07:00
|
|
|
/* There are devices where the same interface number can be
|
|
|
|
* configured as different functions. We should only bind to
|
|
|
|
* vendor specific functions when matching on interface number
|
|
|
|
*/
|
|
|
|
if (id->match_flags & USB_DEVICE_ID_MATCH_INT_NUMBER &&
|
|
|
|
desc->bInterfaceClass != USB_CLASS_VENDOR_SPEC) {
|
|
|
|
dev_dbg(&intf->dev,
|
|
|
|
"Rejecting interface number match for class %02x\n",
|
|
|
|
desc->bInterfaceClass);
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
2015-11-05 18:55:01 +07: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;
|
|
|
|
}
|
|
|
|
|
2019-03-02 19:32:26 +07:00
|
|
|
/* Several Quectel modems supports dynamic interface configuration, so
|
2018-09-08 18:50:48 +07:00
|
|
|
* we need to match on class/subclass/protocol. These values are
|
|
|
|
* identical for the diagnostic- and QMI-interface, but bNumEndpoints is
|
|
|
|
* different. Ignore the current interface if the number of endpoints
|
qmi_wwan: Add quirk for Quectel dynamic config
Most, if not all, Quectel devices use dynamic interface numbers, and
users are able to change the USB configuration at will. Matching on for
example interface number is therefore not possible.
Instead, the QMI device can be identified by looking at the interface
class, subclass and protocol (all 0xff), as well as the number of
endpoints. The reason we need to look at the number of endpoints, is
that the diagnostic port interface has the same class, subclass and
protocol as QMI. However, the diagnostic port only has two endpoints,
while QMI has three.
Until now, we have identified the QMI device by combining a match on
class, subclass and protocol, with a call to the function
quectel_diag_detect(). In quectel_diag_detect(), we check if the number
of endpoints matches for known Quectel vendor/product ids.
Adding new vendor/product ids to quectel_diag_detect() is not a good
long-term solution. This commit replaces the function with a quirk, and
applies the quirk to affected Quectel devices that I have been able to
test the change with (EP06, EM12 and EC25). If the quirk is set and the
number of endpoints equal two, we return from qmi_wwan_probe() with
-ENODEV.
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-07 20:39:09 +07:00
|
|
|
* equals the number for the diag interface (two).
|
2018-09-08 18:50:48 +07:00
|
|
|
*/
|
2019-06-24 23:45:11 +07:00
|
|
|
info = (void *)id->driver_info;
|
qmi_wwan: Add quirk for Quectel dynamic config
Most, if not all, Quectel devices use dynamic interface numbers, and
users are able to change the USB configuration at will. Matching on for
example interface number is therefore not possible.
Instead, the QMI device can be identified by looking at the interface
class, subclass and protocol (all 0xff), as well as the number of
endpoints. The reason we need to look at the number of endpoints, is
that the diagnostic port interface has the same class, subclass and
protocol as QMI. However, the diagnostic port only has two endpoints,
while QMI has three.
Until now, we have identified the QMI device by combining a match on
class, subclass and protocol, with a call to the function
quectel_diag_detect(). In quectel_diag_detect(), we check if the number
of endpoints matches for known Quectel vendor/product ids.
Adding new vendor/product ids to quectel_diag_detect() is not a good
long-term solution. This commit replaces the function with a quirk, and
applies the quirk to affected Quectel devices that I have been able to
test the change with (EP06, EM12 and EC25). If the quirk is set and the
number of endpoints equal two, we return from qmi_wwan_probe() with
-ENODEV.
Signed-off-by: Kristian Evensen <kristian.evensen@gmail.com>
Acked-by: Bjørn Mork <bjorn@mork.no>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-04-07 20:39:09 +07:00
|
|
|
|
|
|
|
if (info->data & QMI_WWAN_QUIRK_QUECTEL_DYNCFG) {
|
|
|
|
if (desc->bNumEndpoints == 2)
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
2018-09-08 18:50:48 +07:00
|
|
|
|
2012-07-17 18:14:32 +07:00
|
|
|
return usbnet_probe(intf, id);
|
|
|
|
}
|
|
|
|
|
2017-03-24 20:22:45 +07:00
|
|
|
static void qmi_wwan_disconnect(struct usb_interface *intf)
|
|
|
|
{
|
|
|
|
struct usbnet *dev = usb_get_intfdata(intf);
|
2017-08-08 23:02:11 +07:00
|
|
|
struct qmi_wwan_state *info;
|
2017-03-24 20:22:45 +07:00
|
|
|
struct list_head *iter;
|
|
|
|
struct net_device *ldev;
|
2019-06-13 00:03:15 +07:00
|
|
|
LIST_HEAD(list);
|
2017-03-24 20:22:45 +07:00
|
|
|
|
2017-08-08 23:02:11 +07:00
|
|
|
/* called twice if separate control and data intf */
|
|
|
|
if (!dev)
|
|
|
|
return;
|
|
|
|
info = (void *)&dev->data;
|
2017-03-24 20:22:45 +07:00
|
|
|
if (info->flags & QMI_WWAN_FLAG_MUX) {
|
|
|
|
if (!rtnl_trylock()) {
|
|
|
|
restart_syscall();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
rcu_read_lock();
|
|
|
|
netdev_for_each_upper_dev_rcu(dev->net, ldev, iter)
|
2019-06-13 00:03:15 +07:00
|
|
|
qmimux_unregister_device(ldev, &list);
|
2017-03-24 20:22:45 +07:00
|
|
|
rcu_read_unlock();
|
2019-06-13 00:03:15 +07:00
|
|
|
unregister_netdevice_many(&list);
|
2017-03-24 20:22:45 +07:00
|
|
|
rtnl_unlock();
|
|
|
|
info->flags &= ~QMI_WWAN_FLAG_MUX;
|
|
|
|
}
|
|
|
|
usbnet_disconnect(intf);
|
|
|
|
}
|
|
|
|
|
2012-01-19 22:37:22 +07:00
|
|
|
static struct usb_driver qmi_wwan_driver = {
|
|
|
|
.name = "qmi_wwan",
|
|
|
|
.id_table = products,
|
2012-07-17 18:14:32 +07:00
|
|
|
.probe = qmi_wwan_probe,
|
2017-03-24 20:22:45 +07:00
|
|
|
.disconnect = qmi_wwan_disconnect,
|
2012-03-09 18:35:05 +07:00
|
|
|
.suspend = qmi_wwan_suspend,
|
|
|
|
.resume = qmi_wwan_resume,
|
|
|
|
.reset_resume = qmi_wwan_resume,
|
2012-01-19 22:37:22 +07:00
|
|
|
.supports_autosuspend = 1,
|
2012-04-24 00:08:51 +07:00
|
|
|
.disable_hub_initiated_lpm = 1,
|
2012-01-19 22:37:22 +07:00
|
|
|
};
|
|
|
|
|
2012-06-19 07:42:03 +07:00
|
|
|
module_usb_driver(qmi_wwan_driver);
|
2012-01-19 22:37:22 +07:00
|
|
|
|
|
|
|
MODULE_AUTHOR("Bjørn Mork <bjorn@mork.no>");
|
|
|
|
MODULE_DESCRIPTION("Qualcomm MSM Interface (QMI) WWAN driver");
|
|
|
|
MODULE_LICENSE("GPL");
|