Tony Lindgren <tony@xxxxxxxxxxx> writes:
> This gets qmicli working with the MDM6600 modem.
>
> Cc: Bjørn Mork <bjorn@xxxxxxx>
> Reviewed-by: Sebastian Reichel <sre@xxxxxxxxxx>
> Tested-by: Sebastian Reichel <sre@xxxxxxxxxx>
> Signed-off-by: Tony Lindgren <tony@xxxxxxxxxxx>
> ---
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
