>>>>>> See patch attached. >>>>>> >>>>>> sierra: use +CFUN=4 for powering down >>>>>> >>>>>> plugins/mm-modem-sierra-gsm.c | 32 >>>>>> ++++++++++++++++++++++++++++++++ >>>>>> 1 file changed, 32 insertions(+) >>>>> This also needs to be intregrated in the master branch version. >>>>> Attached >>>>> is my attempt to do it, but it seems not to work. I see no effect of >>>>> disabling the modem with "mmcli -m X -d". >>>> See review below. >>>> >>>>> Also, it seems like the power down is not done before the modem enters >>>>> disabled state at startup of MM or after modem is inserted, so I >>>>> filed a >>>>> bug about that: >>>>> >>>>> https://bugzilla.gnome.org/show_bug.cgi?id=683681 >>>>> >>>> Yes, that's a known issue, see TODO in the source tree. > > The text there is slightly incorrect. It does not help if the modem is > in low power mode when started (some might also be configured to be), > because at least in the Sierra plugin, it is waked up to CFUN=1 in the > init anyway. This could be avoided by accepting CFUN mode 4 and 7 as > well. But then it must be changed to mode 1 when connecting. > > I am not sure if all the init steps are possible in low power mode. >
CFUN=1 is sent when *enabling* the modem, not during init. All the init steps should really be possible while in CFUN=4 low power mode as that should only kill the radio power. Also, for Sierra modems there's the problem that CFUN=1 may actually reboot the modem, so the problem with powering down the radio with CFUN=4 in Sierra is that this may require a reboot/reprobing of the modem afterwards :-/ IIRC Wavecom (which also suffers from the same issue) had a CFUN=1,0 to try to go into full functionality mode without rebooting, not sure if Sierra has something similar. >>>> >>>> Dan, what do you think of this, should we run the whole disabling >>>> sequence, including the power-down command, just after the modem gets >>>> initialized? I would do it, but now sure if that would have any >>>> unexpected complication. >>>> >>>> The only problem I could think of is when you want to connect your >>>> modem >>>> as soon as it appears in DBus, running the Simple.Connect() command. In >>>> this case you don't really want to go to the low-power mode as you're >>>> going to connect it right away. >>> When would this happen? This power down/disabling should only happen if >>> the mobile broadband is disabled (the default now, although it could be >>> discussed if it should be if there are any auto connections available). >>> If mobile broadband is enabled and a new modem appears, it should move >>> directly from init to start connection. >>> >> MM doesn't know anything about "broadband disabled"; that's a NM setting >> and NM is the one required to honour it. Just assume MM doesn't work >> only with NM. > > Ah, so then MM api could be extended to either expose the power up/down > functions or the init gets a parameter saying if the modem should be > enabled after init. MM interface already has Enable() and Disable() methods. We could expose a more fine-grained interface to control radio power up/down, but not sure if it would help much here. Wouldn't make much sense to have a modem "disabled" with "radio on" (which btw is what we currently have...). > >> But I do agree that we need to handle this properly. We do need to run >> the whole disabling sequence at the end of the initialization sequence, >> either if we're in LOCKED or DISABLED state. The problem doesn't only >> come with power consumption (e.g. the modem has radio powered on, even >> if we say it's disabled); also, the modem will be registered in the >> network and may receive SMS, which we wouldn't process as all the >> feature-specific interfaces are not enabled yet. I'll look at how to do >> this and suggest a fix for this. > > Japp, beside that the computer might be positioned and it should be > turned off to use it in an airplane. > That's a very good reason to make sure we have radio off (when possible). -- Aleksander _______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list