Tony Lindgren <[email protected]> writes: > This gets qmicli working with the MDM6600 modem. > > Cc: Bjørn Mork <[email protected]> > Reviewed-by: Sebastian Reichel <[email protected]> > Tested-by: Sebastian Reichel <[email protected]> > Signed-off-by: Tony Lindgren <[email protected]> > --- > 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? 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. Bjørn
