Re: [MM qmi-support] "Set Operating Mode" on shutdown and more..

[Aleksander Morgado <aleksander lanedo com>]

Hey!

You're truly trying *a lot* of untested code :-)

> 
> I am playing a bit with the qmi-support branch, which seems to be
> getting close to operational.  Nice work!
> 
> But I have a few issues I don't like, as usual :-)
> 

Don't worry, I think I already owe you a couple of beers for all this
testing!


> 
> I don't think ModemManager should mess too much with the operating mode.
> At most it could enable "online" mode if not already there, and possibly
> reset back to the initial mode on exit.  But to do this it needs to save
> the initial mode and understand the allowed transitions.  I really think
> it's best not to touch this at all for now...
> 
> In any case, if the quest is to save power, then at least use
> "low-power" and not "offline".  I can switch back and forth between
> these modes:
> 
> 
> bjorn@nemi:/usr/local/src/git/modemmanager$ qmicli -d /dev/cdc-wdm1 --dms-set-operating-mode=low-power
> [/dev/cdc-wdm1] Operating mode set successfully
> bjorn@nemi:/usr/local/src/git/modemmanager$ qmicli -d /dev/cdc-wdm1 --dms-get-operating-mode
> [/dev/cdc-wdm1] Operating mode retrieved:
>         Mode: 'low-power'
>         HW restricted: 'no'
> bjorn@nemi:/usr/local/src/git/modemmanager$ qmicli -d /dev/cdc-wdm1 --dms-set-operating-mode=online
> [/dev/cdc-wdm1] Operating mode set successfully
> bjorn@nemi:/usr/local/src/git/modemmanager$ qmicli -d /dev/cdc-wdm1 --dms-get-operating-mode
> [/dev/cdc-wdm1] Operating mode retrieved:
>         Mode: 'online'
>         HW restricted: 'no'
> 


Using the low power mode should be safe I guess, just pushed a fix for
this. Thanks for the tip.


> 
> 
> 2) I seem to lose all but one data port on multi-port devices:
> 
> ModemManager[5836]: <debug> [1343739886.255573] [mm-plugin-manager.c:299] plugin_supports_port_ready(): (Gobi): (tty/ttyUSB1) found best plugin for port
> ModemManager[5836]: <info>  [1343739886.255610] [mm-device.c:427] mm_device_create_modem(): Creating modem with plugin 'Gobi' and '7' ports
> ModemManager[5836]: <debug> [1343739886.255644] [gobi/mm-plugin-gobi.c:44] create_modem(): QMI-powered Gobi modem found...
> ModemManager[5836]: <debug> [1343739886.256795] [mm-base-modem.c:247] mm_base_modem_grab_port(): (cdc-wdm0) type 'qmi' claimed by /sys/devices/pci0000:00/0000:00:1d.7/usb8/8-4
> ModemManager[5836]: <debug> [1343739886.256859] [mm-base-modem.c:247] mm_base_modem_grab_port(): (cdc-wdm1) type 'qmi' claimed by /sys/devices/pci0000:00/0000:00:1d.7/usb8/8-4
> ModemManager[5836]: <debug> [1343739886.256908] [mm-base-modem.c:247] mm_base_modem_grab_port(): (wwan0) type 'net' claimed by /sys/devices/pci0000:00/0000:00:1d.7/usb8/8-4
> ModemManager[5836]: <debug> [1343739886.256961] [mm-base-modem.c:247] mm_base_modem_grab_port(): (wwan1) type 'net' claimed by /sys/devices/pci0000:00/0000:00:1d.7/usb8/8-4
> ModemManager[5836]: <debug> [1343739886.257076] [mm-base-modem.c:247] mm_base_modem_grab_port(): (ttyUSB2) type 'at' claimed by /sys/devices/pci0000:00/0000:00:1d.7/usb8/8-4
> ModemManager[5836]: <warn>  [1343739886.257145] [mm-plugin.c:664] mm_plugin_create_modem(): Could not grab port (tty/ttyUSB1): 'Cannot add port 'tty/ttyUSB1', unhandled serial type'
> ModemManager[5836]: <debug> [1343739886.257206] [mm-base-modem.c:247] mm_base_modem_grab_port(): (ttyUSB0) type 'qcdm' claimed by /sys/devices/pci0000:00/0000:00:1d.7/usb8/8-4
> ModemManager[5836]: <debug> [1343739886.257235] [mm-base-modem.c:626] log_port(): (/sys/devices/pci0000:00/0000:00:1d.7/usb8/8-4) tty/ttyUSB2 primary
> ModemManager[5836]: <debug> [1343739886.257258] [mm-base-modem.c:626] log_port(): (/sys/devices/pci0000:00/0000:00:1d.7/usb8/8-4) net/wwan0 data
> ModemManager[5836]: <debug> [1343739886.257279] [mm-base-modem.c:626] log_port(): (/sys/devices/pci0000:00/0000:00:1d.7/usb8/8-4) tty/ttyUSB0 qcdm
> ModemManager[5836]: <debug> [1343739886.257300] [mm-base-modem.c:626] log_port(): (/sys/devices/pci0000:00/0000:00:1d.7/usb8/8-4) usbmisc/cdc-wdm0 qmi
> ModemManager[5836]: <info>  [1343739886.257350] [mm-iface-modem.c:979] mm_iface_modem_update_state(): Modem: state changed (unknown -> initializing)
> ModemManager[5836]: <info>  [1343739886.257635] [mm-manager.c:149] find_device_support_ready(): Modem for device at '/sys/devices/pci0000:00/0000:00:1d.7/usb8/8-4' successfully created
> ModemManager[5836]: [/dev/cdc-wdm0] Checking version info (10 retries)...
> 
> 
> Don't know how the abstraction should be here, but it would be nice to
> be able to use both wwan0 and wwan1 (and possibly also do PPP on
> ttyUSB2).  Note that these cannot be seen as separate modems.  They
> share the SIM interface and all QMI services except WDS.
> 


The new API allows users to create more than one bearer; when it's done
we'll allow to do all that. I must say, I didn't really cover yet the
case of multiple QMI ports in the same device, that's why you're only
seeing one there. Another thing for my TODO list.


> Do also note that the above setup is working by pure luck.  The code
> really should try to match the wwanX and cdc-wdmY devices by USB
> interface and not by USB device.  If we ignore the unfortunate 3.4 and
> 3.5 kernels, then a matching wwanX and cdc-wdmY set will always share
> the same parent USB interface on QMI devices.
> 
> Having the same parent USB device is *not* sufficient.  You cannot
> control wwan0 using cdc-wdm1 in the above example.
> 


Oh, interesting. So, each cdc-wdm *always* has a specific wwan port
paired, then, right? I'll give a look at the logic of multiple QMI/wwan
ports one of these days.


Do you (does anyonoe) know any individual/company who would be willing
to sponsor some of these newer QMI-powered modems for developers?


> 
> 3) I still wonder how to handle the usb => usbmisc transition.  For now
> I've just been searching and replacing, but that is of course not
> supportable.  And it isn't really a one-to-one replacement either.
> There are places where "usb" actually refer to the subsystem and not the
> class.
> 
> Should "usbmisc" be added as an additional device class, keeping "usb",
> or should there be some kernel version checking code there?
> 

Can you give me your diff to look at where you did the changes? I guess
we should try to support both cases, regardless of the kernel version,
if somehow possible.

Cheers!

-- 
Aleksander