> 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 <d...@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.lobr...@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 > > > <aleksan...@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 >
_______________________________________________ networkmanager-list mailing list networkmanager-list@gnome.org https://mail.gnome.org/mailman/listinfo/networkmanager-list
