Re: nmcli radio off connected to ModemManager power state low

[Carlo Lobrano <c lobrano gmail com>]

> I'm not entirely sure what you mean with "power off" and "shut down the

> radio", but here are the definitions I'm using:

> power off: the entire modem is powered off not just the radio.  The

> device does not communicate with the host because it is unpowered.

> 

> radio off: the radio is powered down and no network communication is

> possible, but the modem can still communicate with the host.

clear, the same as mine.

So, saying that my targets are ModemManager Telit plugin's modem_power_down and modem_power_off functions, we have:

* modem_power_off (which is not implemented) == power off.

  Ideally, CFUN=0 would be the candidate, but it would make the modem unrecoverable, so CFUN=4 would be my choice, which is OK, if I understood correcly.

* modem_power_down is currently implemented with CFUN=4 so == radio off.

  However, considering that it is activated with "mmcli -m <ID> --set-power-low", it looks to me as a function that puts the modem in a "power saving state", for which Telit's CFUN=5 would be more appropriate.

  The problem is that if I change modem_power_down to CFUN=5, when I use "nmcli radio off" ModemManager will send CFUN=5, which is not a "radio off" state.

  So, the question is, "mmcli -i <ID> --state-power-low" is to be considered like "go to power save" or "radio off"?

> The ModemManager API specification would not allow CFUN=5 for the

> "disabled" state, since it defines the disabled state as not allowing

> network communication.  So I would still use CFUN=4 for "disabled"

> state.

But, if I got it right, I can't override mm_modem_disable for a plugin, right? When I disable the modem (mmcli -m ID --disable) no AT+CFUN command is sent to the modem.

> But couldn't the modem instead be set to CFUN=5 whenever it is

> enabled?  The Telit docs seem to say it's a fully functional state,

> just that the modem can do some power saving.  Which sounds like a win

> without a downside.

I guess that moving in and out from a power saving state would cost some time (and maybe overhead?) respect CFUN=1 which should be more responsive. Moreover, I would expect to get into a power saving state issuing --set-power-low more that with --set-power-on.

Carlo

On 14 March 2016 at 16:01, Dan Williams <dcbw redhat com> wrote:

On Mon, 2016-03-14 at 09:40 -0500, Dan Williams wrote:
> On Sun, 2016-03-13 at 18:23 +0100, c lobrano gmail com wrote:
> >
> > I'm sorry, I think I explained myself wrong.
> >
> > CFUN=4 is ok for radio off, I wanted to say that some plugins might
> > not 
> > use CFUN=4 for "power low".
> > In Telit modem, as example, I might use CFUN=5 "mobile full 
> > functionality with power saving enabled" and CFUN=4 for power off,
> > but 
> > doing so "nmcli radio off" won't shut down the radio (without
> > rfkill).
> I'm not entirely sure what you mean with "power off" and "shut down
> the
> radio", but here are the definitions I'm using:
>
> power off: the entire modem is powered off not just the radio.  The
> device does not communicate with the host because it is unpowered.
>
> radio off: the radio is powered down and no network communication is
> possible, but the modem can still communicate with the host.
>
> The ModemManager API specification would not allow CFUN=5 for the
> "disabled" state, since it defines the disabled state as not allowing
> network communication.  So I would still use CFUN=4 for "disabled"
> state.  But couldn't the modem instead be set to CFUN=5 whenever it
> is
> enabled?  The Telit docs seem to say it's a fully functional state,
> just that the modem can do some power saving.  Which sounds like a
> win
> without a downside.

Reading further, if CFUN=5 gets used then the telit plugin would need
some special handling of DTR and CTS it seems.  So it won't be trivial,
but probably worthwhile anyway.  We'd probably need some MMPortSerialAt
support to handle the DTR drop and then wait-for-CTS on DTR on, but
that's OK.

Dan

> Dan
>
> >
> > Carlo
> >
> > On dom, mar 13, 2016 at 5:47 , Aleksander Morgado 
> > <aleksander aleksander es> wrote:
> > >
> > >
> > > On Sun, Mar 13, 2016 at 1:56 PM, Carlo Lobrano <c lobrano gmail c
> > > om
> > > >
> > > >  
> > > wrote:
> > > >
> > > >
> > > > >
> > > > >
> > > > >  The problem is that if the modem is totally powered off with
> > > > > a 
> > > > > CFUN=0,
> > > > >
> > > >  then how do we power it back on? CFUN=4, where the modem is
> > > > still
> > > >
> > > >  alive but with radio off is already more than enough in most
> > > > cases.
> > > > >
> > > > >
> > > > >  Why do you need the modem to be totally off?
> > > >  In power low I could expect that the modem goes in some kind
> > > > of 
> > > > power saving
> > > >  configuration but still connected to the network, it really
> > > > depends 
> > > > on the
> > > >  modem capabilities, and when rfkill is not available, the
> > > > modem
> > > > is 
> > > > only set
> > > >  in power low, which may not be the same as radio off.
> > > >
> > > >  I totally understand the problem though, modems that use
> > > > CFUN=0
> > > > to 
> > > > power off
> > > >  are not listening to any command to put them ON again.
> > > >
> > > >  I will look better to rfkill, but I still see a possible 
> > > > misunderstanding
> > > >  between power low intended as radio off and power low intended
> > > > as 
> > > > power
> > > >  saving.
> > > Is there any case in which CFUN=4 doesn't mean radio off? Maybe
> > > we 
> > > got it wrong.
> > >
> > > --
> > > Aleksander
> > > https://aleksander.es

> _______________________________________________
> networkmanager-list mailing list
> networkmanager-list gnome org
> https://mail.gnome.org/mailman/listinfo/networkmanager-list