On Tue, 2012-09-18 at 19:45 +0200, Marius Kotsbak wrote: > 2012/9/18 Aleksander Morgado <[email protected]> > Hey Dan and Marius, > > > > >> Power Up = enabled > >> Power Down = disabled > >> > >> So we already have those states in ModemManager via the > Enable() method > >> and the modem states. It's just that not all devices > actually implement > >> the low-power mode when disabling, partially because we're > not always > >> sure of the side-effects. > >> > > > > The problem here isn't that we don't have a safe power-down > command; the > > problem is that even if we have it, we don't use it just > after plugging > > in the modem: > > initialized -> locked -> disabled > > > > But for that 'disabled' state we didn't run the power-down > command even > > if we have it, so the radio interface may be powered on > there. That's > > the thing to fix by running the disabling sequence just > after > > initialization. If there is no default power down command, > then we would > > run the disabling sequence but without any power down > command, so no big > > deal. > > > > The attached patch runs just a new power-down step during the > modem > initialization, to ensure it starts in low power mode. Adding > a new step > to run power-down instead of running the whole disabling > sequence seemed > a better option, as the disabling sequence really assumes we > were > previously enabled. Note that this patch just re-uses the > power-down > implementation given in each plugin, which we previously used > only > during the disabling sequence. > > Given that it's quite a big change, can you guys try it with > some of the > modems that we know have given issues before with these > things? Thinking > on Sierra modems specifically here. I've got a Wavecom modem > which also > had issues with CFUN (e.g. rebooting on CFUN=1 if it was > already in > CFUN=1), but won't be able to test it until Friday. > > Tested my ZTE MF820D and seems to work nice. Would this be possible to > backport to MM_06?
It could be, patches accepted unless we get to it first :) > Btw, is this expected?: > > model: '+CGMM: "MF820D"' A bug, the handler code here probably needs to strip out the CGMM if found. Most devices don't actually prefix the CGMM response with "+CGMM" so the code wasn't built to handle that, either in 05/06 or git master I guess. Dan _______________________________________________ networkmanager-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/networkmanager-list
