Re: [MM master] Re: [MM06] [PATCH] sierra: use +CFUN=4 for powering down
- From: Aleksander Morgado <aleksander lanedo com>
- To: Marius Kotsbak <marius kotsbak gmail com>
- Cc: "networkmanager-list gnome org" <networkmanager-list gnome org>
- Subject: Re: [MM master] Re: [MM06] [PATCH] sierra: use +CFUN=4 for powering down
- Date: Mon, 10 Sep 2012 11:56:43 +0200
>>>>>> 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
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]