* [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support
@ 2012-02-29 15:15 Bjørn Mork
2012-02-29 15:15 ` [PATCH net-next v3 4/5] net: qmi_wwan: support devices having a shared QMI/wwan interface Bjørn Mork
` (2 more replies)
0 siblings, 3 replies; 15+ messages in thread
From: Bjørn Mork @ 2012-02-29 15:15 UTC (permalink / raw)
To: linux-usb; +Cc: Dan Williams, Oliver Neukum, Bjørn Mork, netdev
This patch set enables the cdc-wdm USB class driver to be used as a
subdriver, and updates the qmi_wwan usbnet minidriver to use this
new functionality.
The purpose is to support a number of 3G/LTE devices based on Qualcomm
chipsets providing a single USB interface combining usbnet and
Qualcomm Messaging Interface (QMI) protocol support. The usbnet wwan
interface must be initialized via the QMI channel before it is usable.
This initialization is complex and depends on many user policy decisions.
By using the cdc-wdm driver to export the QMI interface as a character
device, all this complexity can be left to userspace applications. This
makes us able to support a large number of different devices with very
different capabilities using a single relatively simple driver.
The 2 previous revisions of this set were considered work-in-progress
and were therefore only posted to the linux-usb list for discussion, to
avoid having them end up unnecessarily in netdev patchworks.
Changes in v3:
- move manage_power call in wdm_open() outside the section where we
hold the wlock mutex
- proper initialization of the pmcount counter
- added all non-QDL Gobi device IDs from qcserial driver
Only patch 4 and 5 of this set applies to, and is crossposted to, netdev.
Note that the netdev patches still depend on the 3 first patches of this
set, and should not be applied independently. The 3 first do not yet
apply to net-next, as they depend on other patches in usb-next and
linux-next. Please let me know if this sort of cross-system
patch set should be handled otherwise.
All 5 patches are verified to apply cleanly to linux-next tag next-20120229.
Patches 1-3 are verified to apply to usb-next commit aac1fc386
Patches 4-5 are verified to apply to net-next commit 9100eb012 , but will
cause build errors there due to the lack of the required 3 first patches
as noted above.
Bjørn Mork (5):
usb: cdc-wdm: split out reusable parts of probe
usb: cdc-wdm: adding list lookup indirection
usb: cdc-wdm: adding usb_cdc_wdm_register subdriver support
net: qmi_wwan: support devices having a shared QMI/wwan interface
net: qmi_wwan: add Gobi and Pantech UML290 device IDs
drivers/net/usb/qmi_wwan.c | 248 ++++++++++++++++++++++++++++++++++++++++---
drivers/usb/class/cdc-wdm.c | 224 +++++++++++++++++++++++++++-----------
include/linux/usb/cdc-wdm.h | 19 ++++
3 files changed, 410 insertions(+), 81 deletions(-)
create mode 100644 include/linux/usb/cdc-wdm.h
--
1.7.9
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH net-next v3 4/5] net: qmi_wwan: support devices having a shared QMI/wwan interface
2012-02-29 15:15 [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support Bjørn Mork
@ 2012-02-29 15:15 ` Bjørn Mork
[not found] ` <1330528507-16551-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
2012-03-06 12:03 ` [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support Bjørn Mork
2 siblings, 0 replies; 15+ messages in thread
From: Bjørn Mork @ 2012-02-29 15:15 UTC (permalink / raw)
To: linux-usb; +Cc: Dan Williams, Oliver Neukum, Bjørn Mork, netdev
Use the new cdc-wdm subdriver interface to create a device management
device even for USB devices having a single combined QMI/wwan USB
interface with three endpoints (int, bulk in, bulk out) instead of
separate data and control interfaces.
Some Huawei devices can be switched to a single interface mode for
use with other operating systems than Linux. This adds support
for these devices when they run in such non-Linux modes.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
Note that this patch requires not yet merged changes to the cdc-wdm
USB class driver (parts 1-3 of this patch set), and will cause build
errors if applied standalone to net-next.
drivers/net/usb/qmi_wwan.c | 168 +++++++++++++++++++++++++++++++++++++++----
1 files changed, 152 insertions(+), 16 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 739e6de..a61c7a1 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -13,6 +13,7 @@
#include <linux/usb.h>
#include <linux/usb/cdc.h>
#include <linux/usb/usbnet.h>
+#include <linux/usb/cdc-wdm.h>
/* The name of the CDC Device Management driver */
#define DM_DRIVER "cdc_wdm"
@@ -64,6 +65,9 @@ static int qmi_wwan_bind(struct usbnet *dev, struct usb_interface *intf)
struct usb_cdc_ether_desc *cdc_ether = NULL;
u32 required = 1 << USB_CDC_HEADER_TYPE | 1 << USB_CDC_UNION_TYPE;
u32 found = 0;
+ atomic_t *pmcount = (void *)&dev->data[1];
+
+ atomic_set(pmcount, 0);
/*
* assume a data interface has no additional descriptors and
@@ -170,13 +174,127 @@ err:
return status;
}
-/* stolen from cdc_ether.c */
+/* using a counter to merge subdriver requests with our own into a combined state */
static int qmi_wwan_manage_power(struct usbnet *dev, int on)
{
- dev->intf->needs_remote_wakeup = on;
- return 0;
+ atomic_t *pmcount = (void *)&dev->data[1];
+ int rv = 0;
+
+ dev_dbg(&dev->intf->dev, "%s() pmcount=%d, on=%d\n", __func__, atomic_read(pmcount), on);
+
+ if ((on && atomic_add_return(1, pmcount) == 1) || (!on && atomic_dec_and_test(pmcount))) {
+ /* need autopm_get/put here to ensure the usbcore sees the new value */
+ rv = usb_autopm_get_interface(dev->intf);
+ if (rv < 0)
+ goto err;
+ dev->intf->needs_remote_wakeup = on;
+ usb_autopm_put_interface(dev->intf);
+ }
+err:
+ return rv;
+}
+
+static int qmi_wwan_cdc_wdm_manage_power(struct usb_interface *intf, int on)
+{
+ struct usbnet *dev = usb_get_intfdata(intf);
+ return qmi_wwan_manage_power(dev, on);
}
+/* Some devices combine the "control" and "data" functions into a
+ * single interface with all three endpoints: interrupt + bulk in and
+ * out
+ *
+ * Setting up cdc-wdm as a subdriver owning the interrupt endpoint
+ * will let it provide userspace access to the encapsulated QMI
+ * protocol without interfering with the usbnet operations.
+ */
+static int qmi_wwan_bind_shared(struct usbnet *dev, struct usb_interface *intf)
+{
+ int rv;
+ struct usb_driver *subdriver = NULL;
+ atomic_t *pmcount = (void *)&dev->data[1];
+
+ atomic_set(pmcount, 0);
+
+ /* collect all three endpoints */
+ rv = usbnet_get_endpoints(dev, intf);
+ if (rv < 0)
+ goto err;
+
+ /* require interrupt endpoint for subdriver */
+ if (!dev->status) {
+ rv = -EINVAL;
+ goto err;
+ }
+
+ subdriver = usb_cdc_wdm_register(intf, &dev->status->desc, 512, &qmi_wwan_cdc_wdm_manage_power);
+ if (IS_ERR(subdriver)) {
+ rv = PTR_ERR(subdriver);
+ goto err;
+ }
+
+ /* can't let usbnet use the interrupt endpoint */
+ dev->status = NULL;
+
+ /* save subdriver struct for suspend/resume wrappers */
+ dev->data[0] = (unsigned long)subdriver;
+
+err:
+ return rv;
+}
+
+static void qmi_wwan_unbind_shared(struct usbnet *dev, struct usb_interface *intf)
+{
+ struct usb_driver *subdriver = (void *)dev->data[0];
+
+ if (subdriver && subdriver->disconnect)
+ subdriver->disconnect(intf);
+
+ dev->data[0] = (unsigned long)NULL;
+}
+
+/* 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);
+ struct usb_driver *subdriver = (void *)dev->data[0];
+ int ret;
+
+ ret = usbnet_suspend(intf, message);
+ if (ret < 0)
+ goto err;
+
+ if (subdriver && subdriver->suspend)
+ ret = subdriver->suspend(intf, message);
+ 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);
+ struct usb_driver *subdriver = (void *)dev->data[0];
+ int ret = 0;
+
+ if (subdriver && subdriver->resume)
+ ret = subdriver->resume(intf);
+ if (ret < 0)
+ goto err;
+ ret = usbnet_resume(intf);
+ if (ret < 0 && subdriver && subdriver->resume && subdriver->suspend)
+ subdriver->suspend(intf, PMSG_SUSPEND);
+err:
+ return ret;
+}
+
+
static const struct driver_info qmi_wwan_info = {
.description = "QMI speaking wwan device",
.flags = FLAG_WWAN,
@@ -184,19 +302,37 @@ static const struct driver_info qmi_wwan_info = {
.manage_power = qmi_wwan_manage_power,
};
+static const struct driver_info qmi_wwan_shared = {
+ .description = "QMI speaking wwan device with combined interface",
+ .flags = FLAG_WWAN,
+ .bind = qmi_wwan_bind_shared,
+ .unbind = qmi_wwan_unbind_shared,
+ .manage_power = qmi_wwan_manage_power,
+};
+
#define HUAWEI_VENDOR_ID 0x12D1
static const struct usb_device_id products[] = {
-{
- /* Huawei E392, E398 and possibly others sharing both device id and more... */
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = HUAWEI_VENDOR_ID,
- .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
- .bInterfaceSubClass = 1,
- .bInterfaceProtocol = 8, /* NOTE: This is the *slave* interface of the CDC Union! */
- .driver_info = (unsigned long)&qmi_wwan_info,
-}, {
-}, /* END */
+ { /* Huawei E392, E398 and possibly others sharing both device id and more... */
+ .match_flags = USB_DEVICE_ID_MATCH_VENDOR | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = HUAWEI_VENDOR_ID,
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 8, /* NOTE: This is the *slave* interface of the CDC Union! */
+ .driver_info = (unsigned long)&qmi_wwan_info,
+ },
+ { /* Huawei E392, E398 and possibly others in "Windows mode"
+ * using a combined control and data interface without any CDC
+ * functional descriptors
+ */
+ .match_flags = USB_DEVICE_ID_MATCH_VENDOR | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = HUAWEI_VENDOR_ID,
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 17,
+ .driver_info = (unsigned long)&qmi_wwan_shared,
+ },
+ { } /* END */
};
MODULE_DEVICE_TABLE(usb, products);
@@ -205,9 +341,9 @@ static struct usb_driver qmi_wwan_driver = {
.id_table = products,
.probe = usbnet_probe,
.disconnect = usbnet_disconnect,
- .suspend = usbnet_suspend,
- .resume = usbnet_resume,
- .reset_resume = usbnet_resume,
+ .suspend = qmi_wwan_suspend,
+ .resume = qmi_wwan_resume,
+ .reset_resume = qmi_wwan_resume,
.supports_autosuspend = 1,
};
--
1.7.9
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH net-next/usb-next v3 5/5] net: qmi_wwan: add Gobi and Pantech UML290 device IDs
[not found] ` <1330528507-16551-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
@ 2012-02-29 15:15 ` Bjørn Mork
0 siblings, 0 replies; 15+ messages in thread
From: Bjørn Mork @ 2012-02-29 15:15 UTC (permalink / raw)
To: linux-usb-u79uwXL29TY76Z2rM5mHXA
Cc: Dan Williams, Oliver Neukum, Bjørn Mork,
netdev-u79uwXL29TY76Z2rM5mHXA
Adding the Pantech UML290 and all non-QDL Gobi device IDs from the
qcserial driver now that we have support for shared net/QMI USB
interfaces. Most of these are not yet tested with this driver, but
should be mostly identical to tested devices, except for device IDs.
Gobi devices provide several different interfaces (serial/net/other)
using the exact same class, subclass and protocol values. This driver
will only support the net/QMI function while there are other drivers
supporting other device functions. The net/QMI interface number may
also differ from device to device. It has been noted that all the
other interfaces have additional functional descriptors, so we use that
to detect the interface supported by this driver.
Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
---
Note that this patch requires not yet merged changes to the cdc-wdm
USB class driver (parts 1-3 of this patch set), and will cause build
errors if applied standalone to net-next.
The Gobi devices are currently supported by an out-of-tree driver,
which provides a non-compatible userspace interface. This patch
may therefore cause regressions for anyone using the out-of-three
driver. I do however not believe that userspace interface ever can
be supported by an in-kernel driver, so this clean break is IMHO
the best option we can give those users. They can of course always
blacklist this driver if they wish.
Bjørn
drivers/net/usb/qmi_wwan.c | 82 +++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 81 insertions(+), 1 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index a61c7a1..e14479d 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -243,6 +243,29 @@ err:
return rv;
}
+/* Gobi devices uses identical class/protocol codes for all interfaces regardless
+ * of function. Some of these are CDC ACM like and have the exact same endpoints
+ * we are looking for. This leaves two possible strategies for identifying the
+ * correct interface:
+ * a) hardcoding interface number, or
+ * b) use the fact that the wwan interface is the only one lacking additional
+ * (CDC functional) descriptors
+ *
+ * Let's see if we can get away with the generic b) solution.
+ */
+static int qmi_wwan_bind_gobi(struct usbnet *dev, struct usb_interface *intf)
+{
+ int rv = -EINVAL;
+
+ /* ignore any interface with additional descriptors */
+ if (intf->cur_altsetting->extralen)
+ goto err;
+
+ rv = qmi_wwan_bind_shared(dev, intf);
+err:
+ return rv;
+}
+
static void qmi_wwan_unbind_shared(struct usbnet *dev, struct usb_interface *intf)
{
struct usb_driver *subdriver = (void *)dev->data[0];
@@ -310,7 +333,18 @@ static const struct driver_info qmi_wwan_shared = {
.manage_power = qmi_wwan_manage_power,
};
+static const struct driver_info qmi_wwan_gobi = {
+ .description = "Qualcomm Gobi wwan/QMI device",
+ .flags = FLAG_WWAN,
+ .bind = qmi_wwan_bind_gobi,
+ .unbind = qmi_wwan_unbind_shared,
+ .manage_power = qmi_wwan_manage_power,
+};
+
#define HUAWEI_VENDOR_ID 0x12D1
+#define QMI_GOBI_DEVICE(vend, prod) \
+ USB_DEVICE(vend, prod), \
+ .driver_info = (unsigned long)&qmi_wwan_gobi
static const struct usb_device_id products[] = {
{ /* Huawei E392, E398 and possibly others sharing both device id and more... */
@@ -332,7 +366,53 @@ static const struct usb_device_id products[] = {
.bInterfaceProtocol = 17,
.driver_info = (unsigned long)&qmi_wwan_shared,
},
- { } /* END */
+ { /* Pantech UML290 */
+ .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x106c,
+ .idProduct = 0x3718,
+ .bInterfaceClass = 0xff,
+ .bInterfaceSubClass = 0xf0,
+ .bInterfaceProtocol = 0xff,
+ .driver_info = (unsigned long)&qmi_wwan_shared,
+ },
+ {QMI_GOBI_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
+ {QMI_GOBI_DEVICE(0x03f0, 0x1f1d)}, /* HP un2400 Gobi Modem Device */
+ {QMI_GOBI_DEVICE(0x03f0, 0x371d)}, /* HP un2430 Mobile Broadband Module */
+ {QMI_GOBI_DEVICE(0x04da, 0x250d)}, /* Panasonic Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x413c, 0x8172)}, /* Dell Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x1410, 0xa001)}, /* Novatel Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x0b05, 0x1776)}, /* Asus Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x19d2, 0xfff3)}, /* ONDA Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x05c6, 0x9001)}, /* Generic Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x05c6, 0x9002)}, /* Generic Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x05c6, 0x9202)}, /* Generic Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x05c6, 0x9203)}, /* Generic Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x05c6, 0x9222)}, /* Generic Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x05c6, 0x9009)}, /* Generic Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x413c, 0x8186)}, /* Dell Gobi 2000 Modem device (N0218, VU936) */
+ {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) */
+ {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) */
+ {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) */
+ { } /* END */
};
MODULE_DEVICE_TABLE(usb, products);
--
1.7.9
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support
2012-02-29 15:15 [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support Bjørn Mork
2012-02-29 15:15 ` [PATCH net-next v3 4/5] net: qmi_wwan: support devices having a shared QMI/wwan interface Bjørn Mork
[not found] ` <1330528507-16551-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
@ 2012-03-06 12:03 ` Bjørn Mork
2012-03-06 14:35 ` Greg KH
[not found] ` <4F608D56.9070704@phoenixhaven.net>
2 siblings, 2 replies; 15+ messages in thread
From: Bjørn Mork @ 2012-03-06 12:03 UTC (permalink / raw)
To: Greg KH; +Cc: linux-usb, Dan Williams, Oliver Neukum, netdev
Bjørn Mork <bjorn@mork.no> writes:
> Note that the netdev patches still depend on the 3 first patches of this
> set, and should not be applied independently. The 3 first do not yet
> apply to net-next, as they depend on other patches in usb-next and
> linux-next. Please let me know if this sort of cross-system
> patch set should be handled otherwise.
>
> All 5 patches are verified to apply cleanly to linux-next tag next-20120229.
> Patches 1-3 are verified to apply to usb-next commit aac1fc386
> Patches 4-5 are verified to apply to net-next commit 9100eb012 , but will
> cause build errors there due to the lack of the required 3 first patches
> as noted above.
>
> Bjørn Mork (5):
> usb: cdc-wdm: split out reusable parts of probe
> usb: cdc-wdm: adding list lookup indirection
> usb: cdc-wdm: adding usb_cdc_wdm_register subdriver support
> net: qmi_wwan: support devices having a shared QMI/wwan interface
> net: qmi_wwan: add Gobi and Pantech UML290 device IDs
>
Hello Greg,
I believe I may have promised to ping you when these patches were
ready. Please apply patch 1-3 from this series to your usb-next branch
(for Linux 3.4). They were acked by Oliver a week ago.
Patches 4 and 5 (for netdev) will have to wait until the first 3 are
merged.
Bjørn
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support
2012-03-06 12:03 ` [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support Bjørn Mork
@ 2012-03-06 14:35 ` Greg KH
2012-03-06 15:41 ` Bjørn Mork
[not found] ` <4F608D56.9070704@phoenixhaven.net>
1 sibling, 1 reply; 15+ messages in thread
From: Greg KH @ 2012-03-06 14:35 UTC (permalink / raw)
To: Bjørn Mork; +Cc: linux-usb, Dan Williams, Oliver Neukum, netdev
On Tue, Mar 06, 2012 at 01:03:11PM +0100, Bjørn Mork wrote:
> Bjørn Mork <bjorn@mork.no> writes:
>
> > Note that the netdev patches still depend on the 3 first patches of this
> > set, and should not be applied independently. The 3 first do not yet
> > apply to net-next, as they depend on other patches in usb-next and
> > linux-next. Please let me know if this sort of cross-system
> > patch set should be handled otherwise.
> >
> > All 5 patches are verified to apply cleanly to linux-next tag next-20120229.
> > Patches 1-3 are verified to apply to usb-next commit aac1fc386
> > Patches 4-5 are verified to apply to net-next commit 9100eb012 , but will
> > cause build errors there due to the lack of the required 3 first patches
> > as noted above.
> >
> > Bjørn Mork (5):
> > usb: cdc-wdm: split out reusable parts of probe
> > usb: cdc-wdm: adding list lookup indirection
> > usb: cdc-wdm: adding usb_cdc_wdm_register subdriver support
> > net: qmi_wwan: support devices having a shared QMI/wwan interface
> > net: qmi_wwan: add Gobi and Pantech UML290 device IDs
> >
>
> Hello Greg,
>
> I believe I may have promised to ping you when these patches were
> ready. Please apply patch 1-3 from this series to your usb-next branch
> (for Linux 3.4). They were acked by Oliver a week ago.
Great, can you resend them to me please, with Oliver's ack? I don't see
them in my to-apply queue anymore as I thought they were still under
review.
> Patches 4 and 5 (for netdev) will have to wait until the first 3 are
> merged.
I can take them through my tree if they are dependant on the first 3,
that's not a problem.
thanks,
greg k-h
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support
2012-03-06 14:35 ` Greg KH
@ 2012-03-06 15:41 ` Bjørn Mork
[not found] ` <87r4x5u478.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
0 siblings, 1 reply; 15+ messages in thread
From: Bjørn Mork @ 2012-03-06 15:41 UTC (permalink / raw)
To: Greg KH; +Cc: linux-usb, Dan Williams, Oliver Neukum, netdev
Greg KH <gregkh@linuxfoundation.org> writes:
> On Tue, Mar 06, 2012 at 01:03:11PM +0100, Bjørn Mork wrote:
>
>> I believe I may have promised to ping you when these patches were
>> ready. Please apply patch 1-3 from this series to your usb-next branch
>> (for Linux 3.4). They were acked by Oliver a week ago.
>
> Great, can you resend them to me please, with Oliver's ack? I don't see
> them in my to-apply queue anymore as I thought they were still under
> review.
OK. Will do.
>> Patches 4 and 5 (for netdev) will have to wait until the first 3 are
>> merged.
>
> I can take them through my tree if they are dependant on the first 3,
> that's not a problem.
I've managed to make them dependent on not-yet-merged patches in
net-next as well (the initial addition of the qmi_wwan driver), so I
believe that will be equally difficult. Bad planning from my side I
guess...
Bjørn
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support
[not found] ` <87r4x5u478.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
@ 2012-03-08 18:53 ` Greg KH
2012-03-08 21:43 ` David Miller
2012-03-09 11:35 ` [PATCH RESEND v3 0/2] qmi_wwan: subdriver support (parts 4/5 and 5/5 previously) Bjørn Mork
0 siblings, 2 replies; 15+ messages in thread
From: Greg KH @ 2012-03-08 18:53 UTC (permalink / raw)
To: Bjørn Mork
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Dan Williams, Oliver Neukum,
netdev-u79uwXL29TY76Z2rM5mHXA
On Tue, Mar 06, 2012 at 04:41:47PM +0100, Bjørn Mork wrote:
> Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org> writes:
> > On Tue, Mar 06, 2012 at 01:03:11PM +0100, Bjørn Mork wrote:
> >
> >> I believe I may have promised to ping you when these patches were
> >> ready. Please apply patch 1-3 from this series to your usb-next branch
> >> (for Linux 3.4). They were acked by Oliver a week ago.
> >
> > Great, can you resend them to me please, with Oliver's ack? I don't see
> > them in my to-apply queue anymore as I thought they were still under
> > review.
>
> OK. Will do.
>
> >> Patches 4 and 5 (for netdev) will have to wait until the first 3 are
> >> merged.
> >
> > I can take them through my tree if they are dependant on the first 3,
> > that's not a problem.
>
> I've managed to make them dependent on not-yet-merged patches in
> net-next as well (the initial addition of the qmi_wwan driver), so I
> believe that will be equally difficult. Bad planning from my side I
> guess...
I can take those patches as well if needed, to help unwind the
dependancy mess, and the network maintainer doesn't mind.
thanks,
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support
2012-03-08 18:53 ` Greg KH
@ 2012-03-08 21:43 ` David Miller
2012-03-09 9:29 ` Bjørn Mork
[not found] ` <20120308.134338.1946356302291460775.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2012-03-09 11:35 ` [PATCH RESEND v3 0/2] qmi_wwan: subdriver support (parts 4/5 and 5/5 previously) Bjørn Mork
1 sibling, 2 replies; 15+ messages in thread
From: David Miller @ 2012-03-08 21:43 UTC (permalink / raw)
To: gregkh; +Cc: bjorn, linux-usb, dcbw, oliver, netdev
From: Greg KH <gregkh@linuxfoundation.org>
Date: Thu, 8 Mar 2012 10:53:24 -0800
> On Tue, Mar 06, 2012 at 04:41:47PM +0100, Bjørn Mork wrote:
>> I've managed to make them dependent on not-yet-merged patches in
>> net-next as well (the initial addition of the qmi_wwan driver), so I
>> believe that will be equally difficult. Bad planning from my side I
>> guess...
>
> I can take those patches as well if needed, to help unwind the
> dependancy mess, and the network maintainer doesn't mind.
I don't mind :)
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support
2012-03-08 21:43 ` David Miller
@ 2012-03-09 9:29 ` Bjørn Mork
[not found] ` <20120308.134338.1946356302291460775.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
1 sibling, 0 replies; 15+ messages in thread
From: Bjørn Mork @ 2012-03-09 9:29 UTC (permalink / raw)
To: David Miller; +Cc: gregkh, linux-usb, dcbw, oliver, netdev
David Miller <davem@davemloft.net> writes:
> From: Greg KH <gregkh@linuxfoundation.org>
> Date: Thu, 8 Mar 2012 10:53:24 -0800
>
>> On Tue, Mar 06, 2012 at 04:41:47PM +0100, Bjørn Mork wrote:
>>> I've managed to make them dependent on not-yet-merged patches in
>>> net-next as well (the initial addition of the qmi_wwan driver), so I
>>> believe that will be equally difficult. Bad planning from my side I
>>> guess...
>>
>> I can take those patches as well if needed, to help unwind the
>> dependancy mess, and the network maintainer doesn't mind.
>
> I don't mind :)
Great. Thanks.
I'll resend patch 4 and 5 of this series to Greg then, noting the
necessary commit IDs from net-next in the cover letter.
Bjørn
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH RESEND v3 0/2] qmi_wwan: subdriver support (parts 4/5 and 5/5 previously)
2012-03-08 18:53 ` Greg KH
2012-03-08 21:43 ` David Miller
@ 2012-03-09 11:35 ` Bjørn Mork
[not found] ` <1331292906-7467-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
2012-03-09 11:35 ` [PATCH RESEND v3 2/2] net: qmi_wwan: add Gobi and Pantech UML290 device IDs Bjørn Mork
1 sibling, 2 replies; 15+ messages in thread
From: Bjørn Mork @ 2012-03-09 11:35 UTC (permalink / raw)
To: Greg KH; +Cc: linux-usb, Dan Williams, Oliver Neukum, netdev, Bjørn Mork
Resending patch 4 and 5 of the previous five patch series, to be applied
to usb-next as already discussed with the usb and network maintainers.
These patches depend on the following commit currently in net-next
(and linux-next):
9b28ecd net: usb: qmi_wwan: New driver for Huawei QMI based WWAN devices
I have verified that they apply cleanly to the current (5db51b5) usb-next
branch after cherry-picking this commit from net-next.
Didn't know how to handle the numbering of this set, which is a partial
resend. Part 1/2 of this set was previously submitted as part 4/5, and
part 2/2 was previously submitted as part 5/5. Sorry for the confusion.
I've just learned yet another issue to be careful with. Won't do partial
resending like that anymore...
I'm CCing this to netdev for information, but have set
"X-Patchwork-Hint: ignore" to prevent the patches from ending up in
netdev patchwork. Hope that's OK.
Thanks.
Bjørn Mork (2):
net: qmi_wwan: support devices having a shared QMI/wwan interface
net: qmi_wwan: add Gobi and Pantech UML290 device IDs
drivers/net/usb/qmi_wwan.c | 248 +++++++++++++++++++++++++++++++++++++++++---
1 files changed, 232 insertions(+), 16 deletions(-)
--
1.7.9.1
^ permalink raw reply [flat|nested] 15+ messages in thread
* [PATCH RESEND v3 1/2] net: qmi_wwan: support devices having a shared QMI/wwan interface
[not found] ` <1331292906-7467-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
@ 2012-03-09 11:35 ` Bjørn Mork
0 siblings, 0 replies; 15+ messages in thread
From: Bjørn Mork @ 2012-03-09 11:35 UTC (permalink / raw)
To: Greg KH
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, Dan Williams, Oliver Neukum,
netdev-u79uwXL29TY76Z2rM5mHXA, Bjørn Mork
Use the new cdc-wdm subdriver interface to create a device management
device even for USB devices having a single combined QMI/wwan USB
interface with three endpoints (int, bulk in, bulk out) instead of
separate data and control interfaces.
Some Huawei devices can be switched to a single interface mode for
use with other operating systems than Linux. This adds support
for these devices when they run in such non-Linux modes.
Signed-off-by: Bjørn Mork <bjorn-yOkvZcmFvRU@public.gmane.org>
---
Previously sent as patch number 4/5.
Requires:
9b28ecd net: usb: qmi_wwan: New driver for Huawei QMI based WWAN devices
drivers/net/usb/qmi_wwan.c | 168 +++++++++++++++++++++++++++++++++++++++----
1 files changed, 152 insertions(+), 16 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index 739e6de..a61c7a1 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -13,6 +13,7 @@
#include <linux/usb.h>
#include <linux/usb/cdc.h>
#include <linux/usb/usbnet.h>
+#include <linux/usb/cdc-wdm.h>
/* The name of the CDC Device Management driver */
#define DM_DRIVER "cdc_wdm"
@@ -64,6 +65,9 @@ static int qmi_wwan_bind(struct usbnet *dev, struct usb_interface *intf)
struct usb_cdc_ether_desc *cdc_ether = NULL;
u32 required = 1 << USB_CDC_HEADER_TYPE | 1 << USB_CDC_UNION_TYPE;
u32 found = 0;
+ atomic_t *pmcount = (void *)&dev->data[1];
+
+ atomic_set(pmcount, 0);
/*
* assume a data interface has no additional descriptors and
@@ -170,13 +174,127 @@ err:
return status;
}
-/* stolen from cdc_ether.c */
+/* using a counter to merge subdriver requests with our own into a combined state */
static int qmi_wwan_manage_power(struct usbnet *dev, int on)
{
- dev->intf->needs_remote_wakeup = on;
- return 0;
+ atomic_t *pmcount = (void *)&dev->data[1];
+ int rv = 0;
+
+ dev_dbg(&dev->intf->dev, "%s() pmcount=%d, on=%d\n", __func__, atomic_read(pmcount), on);
+
+ if ((on && atomic_add_return(1, pmcount) == 1) || (!on && atomic_dec_and_test(pmcount))) {
+ /* need autopm_get/put here to ensure the usbcore sees the new value */
+ rv = usb_autopm_get_interface(dev->intf);
+ if (rv < 0)
+ goto err;
+ dev->intf->needs_remote_wakeup = on;
+ usb_autopm_put_interface(dev->intf);
+ }
+err:
+ return rv;
+}
+
+static int qmi_wwan_cdc_wdm_manage_power(struct usb_interface *intf, int on)
+{
+ struct usbnet *dev = usb_get_intfdata(intf);
+ return qmi_wwan_manage_power(dev, on);
}
+/* Some devices combine the "control" and "data" functions into a
+ * single interface with all three endpoints: interrupt + bulk in and
+ * out
+ *
+ * Setting up cdc-wdm as a subdriver owning the interrupt endpoint
+ * will let it provide userspace access to the encapsulated QMI
+ * protocol without interfering with the usbnet operations.
+ */
+static int qmi_wwan_bind_shared(struct usbnet *dev, struct usb_interface *intf)
+{
+ int rv;
+ struct usb_driver *subdriver = NULL;
+ atomic_t *pmcount = (void *)&dev->data[1];
+
+ atomic_set(pmcount, 0);
+
+ /* collect all three endpoints */
+ rv = usbnet_get_endpoints(dev, intf);
+ if (rv < 0)
+ goto err;
+
+ /* require interrupt endpoint for subdriver */
+ if (!dev->status) {
+ rv = -EINVAL;
+ goto err;
+ }
+
+ subdriver = usb_cdc_wdm_register(intf, &dev->status->desc, 512, &qmi_wwan_cdc_wdm_manage_power);
+ if (IS_ERR(subdriver)) {
+ rv = PTR_ERR(subdriver);
+ goto err;
+ }
+
+ /* can't let usbnet use the interrupt endpoint */
+ dev->status = NULL;
+
+ /* save subdriver struct for suspend/resume wrappers */
+ dev->data[0] = (unsigned long)subdriver;
+
+err:
+ return rv;
+}
+
+static void qmi_wwan_unbind_shared(struct usbnet *dev, struct usb_interface *intf)
+{
+ struct usb_driver *subdriver = (void *)dev->data[0];
+
+ if (subdriver && subdriver->disconnect)
+ subdriver->disconnect(intf);
+
+ dev->data[0] = (unsigned long)NULL;
+}
+
+/* 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);
+ struct usb_driver *subdriver = (void *)dev->data[0];
+ int ret;
+
+ ret = usbnet_suspend(intf, message);
+ if (ret < 0)
+ goto err;
+
+ if (subdriver && subdriver->suspend)
+ ret = subdriver->suspend(intf, message);
+ 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);
+ struct usb_driver *subdriver = (void *)dev->data[0];
+ int ret = 0;
+
+ if (subdriver && subdriver->resume)
+ ret = subdriver->resume(intf);
+ if (ret < 0)
+ goto err;
+ ret = usbnet_resume(intf);
+ if (ret < 0 && subdriver && subdriver->resume && subdriver->suspend)
+ subdriver->suspend(intf, PMSG_SUSPEND);
+err:
+ return ret;
+}
+
+
static const struct driver_info qmi_wwan_info = {
.description = "QMI speaking wwan device",
.flags = FLAG_WWAN,
@@ -184,19 +302,37 @@ static const struct driver_info qmi_wwan_info = {
.manage_power = qmi_wwan_manage_power,
};
+static const struct driver_info qmi_wwan_shared = {
+ .description = "QMI speaking wwan device with combined interface",
+ .flags = FLAG_WWAN,
+ .bind = qmi_wwan_bind_shared,
+ .unbind = qmi_wwan_unbind_shared,
+ .manage_power = qmi_wwan_manage_power,
+};
+
#define HUAWEI_VENDOR_ID 0x12D1
static const struct usb_device_id products[] = {
-{
- /* Huawei E392, E398 and possibly others sharing both device id and more... */
- .match_flags = USB_DEVICE_ID_MATCH_VENDOR | USB_DEVICE_ID_MATCH_INT_INFO,
- .idVendor = HUAWEI_VENDOR_ID,
- .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
- .bInterfaceSubClass = 1,
- .bInterfaceProtocol = 8, /* NOTE: This is the *slave* interface of the CDC Union! */
- .driver_info = (unsigned long)&qmi_wwan_info,
-}, {
-}, /* END */
+ { /* Huawei E392, E398 and possibly others sharing both device id and more... */
+ .match_flags = USB_DEVICE_ID_MATCH_VENDOR | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = HUAWEI_VENDOR_ID,
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 8, /* NOTE: This is the *slave* interface of the CDC Union! */
+ .driver_info = (unsigned long)&qmi_wwan_info,
+ },
+ { /* Huawei E392, E398 and possibly others in "Windows mode"
+ * using a combined control and data interface without any CDC
+ * functional descriptors
+ */
+ .match_flags = USB_DEVICE_ID_MATCH_VENDOR | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = HUAWEI_VENDOR_ID,
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 17,
+ .driver_info = (unsigned long)&qmi_wwan_shared,
+ },
+ { } /* END */
};
MODULE_DEVICE_TABLE(usb, products);
@@ -205,9 +341,9 @@ static struct usb_driver qmi_wwan_driver = {
.id_table = products,
.probe = usbnet_probe,
.disconnect = usbnet_disconnect,
- .suspend = usbnet_suspend,
- .resume = usbnet_resume,
- .reset_resume = usbnet_resume,
+ .suspend = qmi_wwan_suspend,
+ .resume = qmi_wwan_resume,
+ .reset_resume = qmi_wwan_resume,
.supports_autosuspend = 1,
};
--
1.7.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 15+ messages in thread
* [PATCH RESEND v3 2/2] net: qmi_wwan: add Gobi and Pantech UML290 device IDs
2012-03-09 11:35 ` [PATCH RESEND v3 0/2] qmi_wwan: subdriver support (parts 4/5 and 5/5 previously) Bjørn Mork
[not found] ` <1331292906-7467-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
@ 2012-03-09 11:35 ` Bjørn Mork
1 sibling, 0 replies; 15+ messages in thread
From: Bjørn Mork @ 2012-03-09 11:35 UTC (permalink / raw)
To: Greg KH; +Cc: linux-usb, Dan Williams, Oliver Neukum, netdev, Bjørn Mork
Adding the Pantech UML290 and all non-QDL Gobi device IDs from the
qcserial driver now that we have support for shared net/QMI USB
interfaces. Most of these are not yet tested with this driver, but
should be mostly identical to tested devices, except for device IDs.
Gobi devices provide several different interfaces (serial/net/other)
using the exact same class, subclass and protocol values. This driver
will only support the net/QMI function while there are other drivers
supporting other device functions. The net/QMI interface number may
also differ from device to device. It has been noted that all the
other interfaces have additional functional descriptors, so we use that
to detect the interface supported by this driver.
Signed-off-by: Bjørn Mork <bjorn@mork.no>
---
Previously sent as patch number 5/5.
drivers/net/usb/qmi_wwan.c | 82 +++++++++++++++++++++++++++++++++++++++++++-
1 files changed, 81 insertions(+), 1 deletions(-)
diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
index a61c7a1..e14479d 100644
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c
@@ -243,6 +243,29 @@ err:
return rv;
}
+/* Gobi devices uses identical class/protocol codes for all interfaces regardless
+ * of function. Some of these are CDC ACM like and have the exact same endpoints
+ * we are looking for. This leaves two possible strategies for identifying the
+ * correct interface:
+ * a) hardcoding interface number, or
+ * b) use the fact that the wwan interface is the only one lacking additional
+ * (CDC functional) descriptors
+ *
+ * Let's see if we can get away with the generic b) solution.
+ */
+static int qmi_wwan_bind_gobi(struct usbnet *dev, struct usb_interface *intf)
+{
+ int rv = -EINVAL;
+
+ /* ignore any interface with additional descriptors */
+ if (intf->cur_altsetting->extralen)
+ goto err;
+
+ rv = qmi_wwan_bind_shared(dev, intf);
+err:
+ return rv;
+}
+
static void qmi_wwan_unbind_shared(struct usbnet *dev, struct usb_interface *intf)
{
struct usb_driver *subdriver = (void *)dev->data[0];
@@ -310,7 +333,18 @@ static const struct driver_info qmi_wwan_shared = {
.manage_power = qmi_wwan_manage_power,
};
+static const struct driver_info qmi_wwan_gobi = {
+ .description = "Qualcomm Gobi wwan/QMI device",
+ .flags = FLAG_WWAN,
+ .bind = qmi_wwan_bind_gobi,
+ .unbind = qmi_wwan_unbind_shared,
+ .manage_power = qmi_wwan_manage_power,
+};
+
#define HUAWEI_VENDOR_ID 0x12D1
+#define QMI_GOBI_DEVICE(vend, prod) \
+ USB_DEVICE(vend, prod), \
+ .driver_info = (unsigned long)&qmi_wwan_gobi
static const struct usb_device_id products[] = {
{ /* Huawei E392, E398 and possibly others sharing both device id and more... */
@@ -332,7 +366,53 @@ static const struct usb_device_id products[] = {
.bInterfaceProtocol = 17,
.driver_info = (unsigned long)&qmi_wwan_shared,
},
- { } /* END */
+ { /* Pantech UML290 */
+ .match_flags = USB_DEVICE_ID_MATCH_DEVICE | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x106c,
+ .idProduct = 0x3718,
+ .bInterfaceClass = 0xff,
+ .bInterfaceSubClass = 0xf0,
+ .bInterfaceProtocol = 0xff,
+ .driver_info = (unsigned long)&qmi_wwan_shared,
+ },
+ {QMI_GOBI_DEVICE(0x05c6, 0x9212)}, /* Acer Gobi Modem Device */
+ {QMI_GOBI_DEVICE(0x03f0, 0x1f1d)}, /* HP un2400 Gobi Modem Device */
+ {QMI_GOBI_DEVICE(0x03f0, 0x371d)}, /* HP un2430 Mobile Broadband Module */
+ {QMI_GOBI_DEVICE(0x04da, 0x250d)}, /* Panasonic Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x413c, 0x8172)}, /* Dell Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x1410, 0xa001)}, /* Novatel Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x0b05, 0x1776)}, /* Asus Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x19d2, 0xfff3)}, /* ONDA Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x05c6, 0x9001)}, /* Generic Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x05c6, 0x9002)}, /* Generic Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x05c6, 0x9202)}, /* Generic Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x05c6, 0x9203)}, /* Generic Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x05c6, 0x9222)}, /* Generic Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x05c6, 0x9009)}, /* Generic Gobi Modem device */
+ {QMI_GOBI_DEVICE(0x413c, 0x8186)}, /* Dell Gobi 2000 Modem device (N0218, VU936) */
+ {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) */
+ {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) */
+ {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) */
+ { } /* END */
};
MODULE_DEVICE_TABLE(usb, products);
--
1.7.9.1
^ permalink raw reply related [flat|nested] 15+ messages in thread
* Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support
[not found] ` <20120308.134338.1946356302291460775.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
@ 2012-03-09 21:13 ` Greg KH
0 siblings, 0 replies; 15+ messages in thread
From: Greg KH @ 2012-03-09 21:13 UTC (permalink / raw)
To: David Miller
Cc: bjorn-yOkvZcmFvRU, linux-usb-u79uwXL29TY76Z2rM5mHXA,
dcbw-H+wXaHxf7aLQT0dZR+AlfA, oliver-GvhC2dPhHPQdnm+yROfE0A,
netdev-u79uwXL29TY76Z2rM5mHXA
On Thu, Mar 08, 2012 at 01:43:38PM -0800, David Miller wrote:
> From: Greg KH <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.org>
> Date: Thu, 8 Mar 2012 10:53:24 -0800
>
> > On Tue, Mar 06, 2012 at 04:41:47PM +0100, Bjørn Mork wrote:
> >> I've managed to make them dependent on not-yet-merged patches in
> >> net-next as well (the initial addition of the qmi_wwan driver), so I
> >> believe that will be equally difficult. Bad planning from my side I
> >> guess...
> >
> > I can take those patches as well if needed, to help unwind the
> > dependancy mess, and the network maintainer doesn't mind.
>
> I don't mind :)
Thanks, I've picked the one patch in your tree up, and applied these new
ones as well.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support
[not found] ` <4F608D56.9070704@phoenixhaven.net>
@ 2012-03-14 12:51 ` Bjørn Mork
2012-03-14 15:20 ` Nin Lil'izi
0 siblings, 1 reply; 15+ messages in thread
From: Bjørn Mork @ 2012-03-14 12:51 UTC (permalink / raw)
To: Nin Lil'izi; +Cc: Greg KH, linux-usb, Dan Williams, Oliver Neukum, netdev
"Nin Lil'izi" <nin-lil-izi@cf-protected.phoenixhaven.net> writes:
> Please forgive me for spamming this list.
> But is this module going to make it into the 3.3.0 final release?
>
> I've been testing it on my laptop while travelling on trains and things
> using recent git pulls. And it releaves so much frustration vs the
> option module.
> As in spotty signal areas it drops in and out seamlessly without having
> to manually reconnect everytime the train passes through a deadspot. And
> generally the connection is noticiably more stable in this use case :D
>
> Anyway I'd like to try it on my home connection which is run off an atom
> device in a radio blackspot from hell. Which results in stuff having to
> be reconnected very often, even with huge external antenna attached. So
> this is like a dream come true in frustration saving but it takes
> 12hours to build a kernel. And cross compilation is labour intensive
> when you don't have the toolchain setup first. So am waiting for this to
> hit a stable release before building it on that machine to save my sanity.
Thanks for the nice feedback.
This was submitted far too late for it to be considered 3.3 material.
Not much to do about that. Most of the developement happened after
3.3-rc1 anyway. So I'm afraid you'll have to wait a couple months more
for the 3.4 release.
I understand that wasn't the message you wanted, but it does give us all
a chance to test it thoroughly on different types of hardware. And maybe
even prepare some userspace tools :-)
Which brings me to a couple of questions I have for you: What radio
hardware do you use (lsusb -v), and which userspace tools?
But we should maybe continue any userspace tool discussion here instead,
where it's a bit more on topic:
http://lists.freedesktop.org/mailman/listinfo/libqmi-devel
Bjørn
^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support
2012-03-14 12:51 ` [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support Bjørn Mork
@ 2012-03-14 15:20 ` Nin Lil'izi
0 siblings, 0 replies; 15+ messages in thread
From: Nin Lil'izi @ 2012-03-14 15:20 UTC (permalink / raw)
To: Bjørn Mork
Cc: Nin Lil'izi, Greg KH, linux-usb, Dan Williams, Oliver Neukum,
netdev
[-- Attachment #1: Type: text/plain, Size: 11999 bytes --]
Radio hardware is a gimped Huaweii E398. Gimped as in supplied by the
telco with the 2g chip missing.
These are currently /the/ device supplied by the network '3' in the UK.
And as such are fast becoming very common devices over here.
I should also mention that I've made some modifications to the device
myself. Namely updating the firmware to someting more recent then
shipped as stock, and replacing the zerocd installer volume with the
most recent generic debranded huaweii image.
I'll take the userspace discussion to the other list.
lusb output below while in use using the option module on the stock arch
kernel (Linux Ninki 3.2.9-1-ARCH #1 SMP PREEMPT Thu Mar 1 09:31:13 CET
2012 x86_64 AMD C-60 APU with Radeon(tm) HD Graphics AuthenticAMD GNU/Linux)
[nin-lil-izi@Ninki ~]$ sudo lsusb -v -d 12d1:1506
Bus 001 Device 002: ID 12d1:1506 Huawei Technologies Co., Ltd. E398
LTE/UMTS/GSM Modem/Networkcard
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
idVendor 0x12d1 Huawei Technologies Co., Ltd.
idProduct 0x1506 E398 LTE/UMTS/GSM Modem/Networkcard
bcdDevice 0.00
iManufacturer 3 Huawei Technologies
iProduct 2 HUAWEI Mobile
iSerial 0
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 161
bNumInterfaces 6
bConfigurationValue 1
iConfiguration 1 Huawei Configuration
bmAttributes 0xc0
Self Powered
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 1
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82 EP 2 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01 EP 1 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 1
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 7
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 5
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84 EP 4 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 2
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 3
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x85 EP 5 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03 EP 3 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 3
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 1
bInterfaceProtocol 2
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x86 EP 6 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x04 EP 4 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 32
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 4
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x87 EP 7 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x05 EP 5 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 5
bAlternateSetting 0
bNumEndpoints 2
bInterfaceClass 8 Mass Storage
bInterfaceSubClass 6 SCSI
bInterfaceProtocol 80 Bulk (Zip)
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x06 EP 6 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x88 EP 8 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0200 1x 512 bytes
bInterval 0
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 0 (Defined at Interface level)
bDeviceSubClass 0
bDeviceProtocol 0
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
Regards,
/Nin lil'izi/
Skype: Nin-lil-izi
/Help me stay fed, order a certain and enevitable demise off me today!/
GPG Fingerprint: C510 909B 811E D6F5 0DFF 5D91 CF03 8FEA FD69 4622
On 14/03/12 12:51, Bjørn Mork wrote:
> "Nin Lil'izi" <nin-lil-izi@cf-protected.phoenixhaven.net> writes:
>
>> Please forgive me for spamming this list.
>> But is this module going to make it into the 3.3.0 final release?
>>
>> I've been testing it on my laptop while travelling on trains and things
>> using recent git pulls. And it releaves so much frustration vs the
>> option module.
>> As in spotty signal areas it drops in and out seamlessly without having
>> to manually reconnect everytime the train passes through a deadspot. And
>> generally the connection is noticiably more stable in this use case :D
>>
>> Anyway I'd like to try it on my home connection which is run off an atom
>> device in a radio blackspot from hell. Which results in stuff having to
>> be reconnected very often, even with huge external antenna attached. So
>> this is like a dream come true in frustration saving but it takes
>> 12hours to build a kernel. And cross compilation is labour intensive
>> when you don't have the toolchain setup first. So am waiting for this to
>> hit a stable release before building it on that machine to save my sanity.
> Thanks for the nice feedback.
>
> This was submitted far too late for it to be considered 3.3 material.
> Not much to do about that. Most of the developement happened after
> 3.3-rc1 anyway. So I'm afraid you'll have to wait a couple months more
> for the 3.4 release.
>
> I understand that wasn't the message you wanted, but it does give us all
> a chance to test it thoroughly on different types of hardware. And maybe
> even prepare some userspace tools :-)
>
> Which brings me to a couple of questions I have for you: What radio
> hardware do you use (lsusb -v), and which userspace tools?
>
> But we should maybe continue any userspace tool discussion here instead,
> where it's a bit more on topic:
> http://lists.freedesktop.org/mailman/listinfo/libqmi-devel
>
>
> Bjørn
> --
> To unsubscribe from this list: send the line "unsubscribe linux-usb" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 900 bytes --]
^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2012-03-14 15:20 UTC | newest]
Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-02-29 15:15 [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support Bjørn Mork
2012-02-29 15:15 ` [PATCH net-next v3 4/5] net: qmi_wwan: support devices having a shared QMI/wwan interface Bjørn Mork
[not found] ` <1330528507-16551-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
2012-02-29 15:15 ` [PATCH net-next/usb-next v3 5/5] net: qmi_wwan: add Gobi and Pantech UML290 device IDs Bjørn Mork
2012-03-06 12:03 ` [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support Bjørn Mork
2012-03-06 14:35 ` Greg KH
2012-03-06 15:41 ` Bjørn Mork
[not found] ` <87r4x5u478.fsf-lbf33ChDnrE/G1V5fR+Y7Q@public.gmane.org>
2012-03-08 18:53 ` Greg KH
2012-03-08 21:43 ` David Miller
2012-03-09 9:29 ` Bjørn Mork
[not found] ` <20120308.134338.1946356302291460775.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
2012-03-09 21:13 ` Greg KH
2012-03-09 11:35 ` [PATCH RESEND v3 0/2] qmi_wwan: subdriver support (parts 4/5 and 5/5 previously) Bjørn Mork
[not found] ` <1331292906-7467-1-git-send-email-bjorn-yOkvZcmFvRU@public.gmane.org>
2012-03-09 11:35 ` [PATCH RESEND v3 1/2] net: qmi_wwan: support devices having a shared QMI/wwan interface Bjørn Mork
2012-03-09 11:35 ` [PATCH RESEND v3 2/2] net: qmi_wwan: add Gobi and Pantech UML290 device IDs Bjørn Mork
[not found] ` <4F608D56.9070704@phoenixhaven.net>
2012-03-14 12:51 ` [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support Bjørn Mork
2012-03-14 15:20 ` Nin Lil'izi
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).