Verizon UML295

[Markus Gothe]

I guess I was out watching the ice-hockey game both yesterday and today instead (“my” team did make it to the quarter final today).
So I’ll will make this during the week as well as a patch for MBIM’s source mac.

I figured out that in bridged mode one will never be able to use the .rx_fixup in qmi_wwan.c since MAC-adresses can start with 0x40, 0x00, 0x60 and even if we try working around this we need to have to the endpoints MAC-address as destination when doing the rewrite; not like we do today and use the device’s mac-adress in ‘fix_dest’.

Also we must figure out the source adress or assume it is the default one. :-/

My suggestion is to implement a parameter that can be changed on-the-fly by procfs to turn off/on the rx_fixup in qmi_wwan.c
What do you guys think (I know you don’t bridge these things as much as me and my customers)?

//M

On 09 Mar 2015, at 11:01 , Markus Gothe <nietzsche at lysator.liu.se> wrote:

> I'll fix it tonight with a patch for usbmodeswitch as well.
> 
> //M
> Den 9 mar 2015 10:23 skrev Bjørn Mork <bjorn at mork.no>:
>> 
>> Markus Gothe <nietzsche at lysator.liu.se> writes: 
>> 
>>> Getting hold of a device with the latest fw and using the code from Dave and reimplemented it as an usual-dev-callback I managed to switch it to QMI-mode (and it use ‘rawip’ by default). 
>>> The trick is that the device will appear first as 0x1a9 0x606f and then wait 2-3 secs for the switch and then eject itself and come back as 0x1a9 0x6064 in www-mode if *not* switched to QMI-mode. 
>>> 
>>> Thanks for your help on resolving this. Especially Dave for providing the modeswitch-code. 
>>> Here is a simple patch as a token of appreciation. 
>>> Index: linux/drivers/usb/storage/initializers.c 
>>> =================================================================== 
>>> --- linux/drivers/usb/storage/initializers.c (revision 13611) 
>>> +++ linux/drivers/usb/storage/initializers.c (working copy) 
>>> @@ -141,6 +141,21 @@ 
>>>   return 0; 
>>>   } 
>>>   
>>> +/* This places the Pantech UML295 devices in QMI mode */ 
>>> +int usb_stor_uml295_init(struct us_data *us) 
>>> +{linux/ 
>>> + int result; 
>>> + unsigned char data = 0x00; 
>>> + 
>>> + result = usb_stor_control_msg(us, us->send_ctrl_pipe, 
>>> +       0x70, 
>>> +       0x40, 
>>> +       0x4 /* 4 = QMI, 2 = RNDIS */, 0x0, (char*)&data, sizeof(data), 1000); 
>>> + printk(KERN_INFO "Pantech UML295 mode set result is %d\n", result); 
>> 
>> Ah, nice! 
>> 
>> But the current policy is to do stuff like this in userspace instead of 
>> adding new devices to unusual_devs.h.  I hope it is possible to achieve 
>> the same result using e.g. usb_modeswitch? Yes, I know you work in 
>> embedded systems, but I guess you do run some hotplug script or udev 
>> equivalent there too? 
>> 
>> One obvious advantage having this in userspace, is that the the user 
>> gains control over the QMI vs RNDIS selection.  You can easily adapt the 
>> usb_modeswitch config for your preference. 
>> 
>> 
>> 
>> 
>> 
>> 
>>> --- linux/drivers/net/usb/qmi_wwan.c (revision 13613) 
>>> +++ linux/drivers/net/usb/qmi_wwan.c (working copy) 
>>> @@ -22,6 +22,10 @@ 
>>>   USB_VENDOR_AND_INTERFACE_INFO(0x106c, USB_CLASS_VENDOR_SPEC, 0xf1, 0xff), 
>>>   .driver_info        = (unsigned long)&qmi_wwan_info, 
>>>   }, 
>>> + { /* Pantech UML295 and more */ 
>>> + USB_VENDOR_AND_INTERFACE_INFO(0x10a9, USB_CLASS_VENDOR_SPEC, 0xf0, 0x00), 
>>> + .driver_info        = (unsigned long)&qmi_wwan_info, 
>>> + }, 
>>>   { /* Novatel USB551L and MC551 */ 
>>>   USB_DEVICE_AND_INTERFACE_INFO(0x1410, 0xb001, 
>>>                                 USB_CLASS_COMM, 
>> 
>> Could you please submit this part as a separate patch with a proper 
>> Signed-off-by?  Thanks 
>> 
>> BTW, any idea why they have a new vendor ID for these devices?  The 
>> class codes seem to match the UML290 entries. 
>> 
>> 
>> Bjørn 
> _______________________________________________
> libqmi-devel mailing list
> libqmi-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libqmi-devel

//Markus - The panama-hat hacker

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.freedesktop.org/archives/libqmi-devel/attachments/20150311/1218c408/attachment.sig>