Handling QSS unsolicited in power state transitions

[Carlo Lobrano]

> 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 <aleksander at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20170801/d18913a3/attachment.html>