> Aren't the sim hot swap unsolicited messages received always, regardless of whether the modem is enabled or disabled?
disabling_stopped function releases both ports contexts, so we don't receive unsolicited on SIM swap ports. > The only issue is when getting #QSS=0 after a +CFUN=4, right? Because we would be getting a SIM removal event that isn't really such thing, it was just the SIM card being powered off as well. Is there maybe a command to get into low-power mode that shuts down RF but leaves SIM card powered? This is correct, but we don't have commands that disable RF and leaves SIM card powered. > A wild idea, but would it be possible to wrap around the +CFUN calls between #QSS indication disabled and enabled? > E.g. > Disable #QSS indications (not just ignore them in MM, but explicitly tell the modem to not send them) > +CFUN=4 > Enable #QSS indications right away > (maybe the #QSS won't arrive here as it was disabled during CFUN?) > > Would that make sense? Or will the #QSS be sent anyway, even if it was disabled during the +CFUN being run? That's actually a good idea to test. I've thought about disabling on CFUN=4 and re-enabling on CFUN=1, but not around the same command. On 1 August 2017 at 10:32, Aleksander Morgado <aleksan...@aleksander.es> wrote: > > On 01/08/17 10:04, Carlo Lobrano wrote: > > last week I was working to handle a behavior that most of the Telit modem > > have, that is, they emit *#QSS* unsolicited in consequence of *+CFUN* > > commands. Most of the times, the modems are already in *+CFUN=1* at the > > start so we did not notice it in a normal power up, but if we put the > modem > > in power low state, the *+CFUN=4* triggers a *#QSS=0* that the > ModemManager > > considers as a SIM swap. Note that this is receved as soon as the modem > is > > enabled again, because currently we release SIM swap ports while > disabling > > the modem, and, if we set power state on, ***together with the #QSS=1 due > > to +CFUN=1*** causing a crash. > > > > Aren't the sim hot swap unsolicited messages received always, regardless > of whether the modem is enabled or disabled? > > > Generally speaking this behavior isn't wrong per se (a part from the > crash, > > that can be fixed), because the SIM is actually turned off, but in this > > configuration we cannot re-enable the modem, while sending a *+CFUN=1* > the > > modem would be usable again. > > > > So, I made a couple of patches, (1) avoid releasing SIM swap ports on > modem > > disable, so we can still receive SIM notifications at the right moment, > and > > (2) ignore QSS unsolicited when changing *+CFUN* state and only for a > short > > amount of time. The problem is that there isn't a specific timeout within > > which this unsolicited must arrive and according to my tests it is quite > > variable (about between 3 and 10 seconds). > > > > The only issue is when getting #QSS=0 after a +CFUN=4, right? Because we > would be getting a SIM removal event that isn't really such thing, it was > just the SIM card being powered off as well. Is there maybe a command to > get into low-power mode that shuts down RF but leaves SIM card powered? > > > One solution is then to ignore *#QSS* for like 10 seconds, while the > other > > one is to keep ignoring them in the whole time between *+CFUN=4* and* > > +CFUN=1*. This last solution is more consistent, but it won't let us get > > SIM removal/insertion when the modem is in power-state-low. > > A wild idea, but would it be possible to wrap around the +CFUN calls > between #QSS indication disabled and enabled? > E.g. > Disable #QSS indications (not just ignore them in MM, but explicitly > tell the modem to not send them) > +CFUN=4 > Enable #QSS indications right away > (maybe the #QSS won't arrive here as it was disabled during CFUN?) > > Would that make sense? Or will the #QSS be sent anyway, even if it was > disabled during the +CFUN being run? > > -- > Aleksander > https://aleksander.es >
_______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel