Re: [PATCH] net: qmi_wwan: Add USB IDs for MDM6600 modem on Motorola Droid 4

Tony Lindgren [off-list ref] writes:

* Bjørn Mork [off-list ref] [170319 09:33]:

quoted

Tony Lindgren [off-list ref] writes:

quoted

This gets qmicli working with the MDM6600 modem.

Cc: Bjørn Mork <bjorn@mork.no>
Reviewed-by: Sebastian Reichel <sre@kernel.org>
Tested-by: Sebastian Reichel <sre@kernel.org>
Signed-off-by: Tony Lindgren <tony@atomide.com>
---
 drivers/net/usb/qmi_wwan.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/usb/qmi_wwan.c b/drivers/net/usb/qmi_wwan.c
--- a/drivers/net/usb/qmi_wwan.c
+++ b/drivers/net/usb/qmi_wwan.c

@@ -580,6 +580,10 @@ static const struct usb_device_id products[] = {
 		USB_VENDOR_AND_INTERFACE_INFO(HUAWEI_VENDOR_ID, USB_CLASS_VENDOR_SPEC, 0x01, 0x69),
 		.driver_info        = (unsigned long)&qmi_wwan_info,
 	},
+	{	/* Motorola Mapphone devices with MDM6600 */
+		USB_VENDOR_AND_INTERFACE_INFO(0x22b8, USB_CLASS_VENDOR_SPEC, 0xfb, 0xff),

This is a bit unusual, so I'd like to verify that it is correct.  Do you
happen to have a "lsusb -v" or /sys/kernel/debug/usb/devices dump for
this device?  Is this usage of vendor + class consistent with the
Windows driver *.inf data?  Are you sure that the ff/fb/ff class is only
used for QMI functions by this vendor ID? 

Well this is based on what the earlier Motorola mapphone v3.8 kernel has
for in drivers/net/usb/qcusbnet/qcusbnet.c driver:

+       { /* Motorola Xoom */
+       USB_DEVICE_AND_INTERFACE_INFO(0x22B8, 0x2A70, 0xff, 0xfb, 0xff),
+       .driver_info = (unsigned long)&xoom_qc_netinfo
+       },
+       { /* MDM9600 */
+       USB_DEVICE_AND_INTERFACE_INFO(0x22B8, 0x2E0A, 0xff, 0xfb, 0xff),
+       .driver_info = (unsigned long)&mdm9600_qc_netinfo
+       },

That helps a lot. Was not aware of this driver.

Where the "Motorola Xoom" id is also used for all mapphone devices
with MDM6600 variants.

Then xoom_qc_netinfo in the mapphone kernel has:

+static const struct driver_info xoom_qc_netinfo = {
+       .description   = "Xoom QCUSBNet Ethernet Device",
+       .flags         = FLAG_ETHER|FLAG_SEND_ZLP,
+       .bind          = xoom_qcnet_bind,
+       .unbind        = qcnet_unbind,
+       .data          = 0,
+       .manage_power  = qcnet_manage_power,
+};

And the v3.8 kernel also has drivers/usb/serial/mdm6600.c:

+static const struct usb_device_id mdm6600_id_table[] = {
+       { USB_DEVICE_AND_INTERFACE_INFO(0x22b8, 0x2a70, 0xff, 0xff, 0xff) },
+        /* MDM9600 */
+       { USB_DEVICE_AND_INTERFACE_INFO(0x22b8, 0x2e0a, 0xff, 0xff, 0xff) },
+       { USB_DEVICE_AND_INTERFACE_INFO(0x22b8, 0x900e, 0xff, 0xff, 0xff) },
+       { },
+};

Yes, looks like they consitently use ff/ff/ff for serial functions and
ff/fb/ff for QMI functions.  So adding a vendor rule seems appropriate.

And then in drivers/usb/serial/moto_flashqsc.c:

+static struct usb_device_id id_table[] = {
+       {USB_DEVICE_AND_INTERFACE_INFO(0x22b8, 0x2a63, 0x0a, 0, 0)},
+       {USB_DEVICE_AND_INTERFACE_INFO(0x22b8, 0x4281, 0x0a, 0, 0xfc)},
+       {USB_DEVICE_AND_INTERFACE_INFO(0x22b8, 0x2db4, 0x0a, 0, 0xfc)},
+       {USB_DEVICE(0x22b8, 0x4260)},
+       {USB_DEVICE(0x22b8, 0x426D)},
+       {},
+};

This on the other hand, is something I hope I don't have to review :)
The 0x0a class (CDC Data) is always part of a multi-interface function,
and you would normally match on the control interface.

Where the 0x4260 and 0x426d seem to be for the flash mode of the
Wrigley3GLTE modem.

See also lsusb -v output below. No idea if there's a Windows driver
.inf file for this. Most likely whatever Windows driver is just using the
generic Android USB driver(s). I know the USB on droid 4 can be multiplexed
to have MDM6600 directly accessed, but I think that's only used for
debugging the modem as that mode needs to be selected in the bootloader
temporarily using volume keys.

With the configuration in my patch, modprobe of qmi_wwan produces four
wwan interfaces if that matters.

And I assume they all work?

quoted

The reason I ask is that I'd hate to have reports of other Motorola
devices where ff/fb/ff was used for some other USB function.  Yes, that
would be stupid.  But still... Experience shows that we cannot rule out
stupid when we consider USB descriptors.

Yes thanks for checking. If you prefer to set it up in some other
way, or need more info, please let me know.

No, it all looks very sane to me, given your explanation. Just wanted to
be absolutely sure. Thanks a lot.


Acked-by: Bjørn Mork <bjorn@mork.no>



Bjørn