Johan Hovold <johan@xxxxxxxxxx> writes:
> Dan and Björn,
>
> On Thu, Dec 10, 2015 at 04:42:52PM +0100, yegorslists@xxxxxxxxxxxxxx wrote:
>> From: Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx>
>>
>> Signed-off-by: Yegor Yefremov <yegorslists@xxxxxxxxxxxxxx>
>> ---
>> drivers/usb/serial/option.c | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/drivers/usb/serial/option.c b/drivers/usb/serial/option.c
>> index f228060..e0950bf 100644
>> --- a/drivers/usb/serial/option.c
>> +++ b/drivers/usb/serial/option.c
>> @@ -1113,6 +1113,7 @@ static const struct usb_device_id option_ids[] = {
>> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x6613)}, /* Onda H600/ZTE MF330 */
>> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x0023)}, /* ONYX 3G device */
>> { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9000)}, /* SIMCom SIM5218 */
>> + { USB_DEVICE(QUALCOMM_VENDOR_ID, 0x9003)}, /* Quectel UC20 */
>
> Does this one belong in option or qcserial? I see that
>
> {DEVICE_G1K(0x05c6, 0x9001)}, /* Generic Gobi Modem device */
> {DEVICE_G1K(0x05c6, 0x9002)}, /* Generic Gobi Modem device */
>
> are already handled by the latter (while 0x9000 isn't).
I don't have strong opionions about this, but it most certainly need to
avoid probing the QMI function so the above patch cannot be correct.
I see that this ID was part of a batch addition I did a while ago based
on Windows drivers (and no testting whatsoever!). See
0470667caa82 ("net: qmi_wwan: add new Qualcomm devices")
I guess this should have gone into some serial driver too, but it
appears it didn't.
Based on the recent Quectel EC20 experiences, I wouldn't be surprised if
this device reuse a Qualcomm device ID with a different layout. Or
maybe we just were wrng in the first place... difficult to know without
any real tester/device.
Bjørn
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
