[PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support

[PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support

[Bjørn Mork]

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

[PATCH net-next v3 4/5] net: qmi_wwan: support devices having a shared QMI/wwan interface

[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@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

[PATCH net-next/usb-next v3 5/5] net: qmi_wwan: add Gobi and Pantech UML290 device IDs

[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-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

Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support

[Bjørn Mork]

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

Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support

[Greg KH]

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

Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support

[Bjørn Mork]

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

Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support

[Greg KH]

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

Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support

[David Miller]

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

Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support

[Bjørn Mork]

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

Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support

[Greg KH]

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

[PATCH RESEND v3 0/2] qmi_wwan: subdriver support (parts 4/5 and 5/5 previously)

[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

[PATCH RESEND v3 1/2] net: qmi_wwan: support devices having a shared QMI/wwan interface

[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

[PATCH RESEND v3 2/2] net: qmi_wwan: add Gobi and Pantech UML290 device IDs

[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

Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support

[Bjørn Mork]

"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

Re: [PATCH net-next/usb-next v3 0/5] cdc-wdm/qmi_wwan: subdriver support

[Nin Lil'izi]

[-- 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 --]