Update SIM related data according to an event

[Aleksander Morgado]

Hey!

On Tue, Mar 22, 2016 at 3:25 PM, Carlo Lobrano <c.lobrano at gmail.com> wrote:
> I had some time now to look at the changes for SIM hot insertion feature
> (QSS unsolicited in Telit modems), lot of doubts actually.
>
> My idea is the following:
>
> 1. in modem iface initialization, ask the modem whether it supports or not
> SIM hot insertion (TBD: sync method? property?).

How will you know if it supports SIM hot insertion? Is there any Telit
specific command to do so? Or is it that all Telit modems support it?
If the former, then an async method to query doing initialization; if
the latter, then a property that can be set to TRUE when the modem
object is created from the plugin code.

> 2. according to point 1, if initialization fails for
> MM_MOBILE_EQUIPMENT_ERROR_SIM_NOT_INSERTED, allow the modem enable command
> (I am not sure about this actually, see my note below).

Hum... no. Don't think this should be the case. Enable() should only
be allowed if the modem is Disabled, which means it isn't Failed,
which means it has SIM.

> 3. In telit plugin, register an handler for QSS unsolicited (3gpp iface)
>     a. when sim is removed
>         - disable modem (mm_modem_disable) keeping the QSS handler (and the
> port open)
>         - set modem in locked state (mm_iface_modem_update_state)
>     b. when sim is inserted
>         - start re-probe (mm_base_modem_set_valid(..., false))
>

This should go in the generic logic, not in the 3GPP logic, I would
say. E.g. the "unlock_required" stuff is not 3GPP only. What I would
do, is:

 a1) If the modem supports SIM hot plugging and we boot without a SIM,
we end up going to the same Failed state as before, but in this case
we don't just close all ports. We would need some additional extra
logic to be run in Failed state, like opening the port and keeping it
open with the QSS handler set. I would definitely not touch any other
logic.
 a2) If the modem already had a SIM and modem gets enabled; and then
the SIM is removed, we would go first to disable to cleanup everything
and then right away to Failed state (no locked), but with the same
additional logic discussed before to monitor QSS. Or, if you prefer,
you could also try to just set_valid(...,false) as that would reprobe
the modem, and we would end up in case a1) again.
 b) When modem is in Failed state and SIM is inserted, we directly
call set_valid(...,false) to reprobe from scratch, so that it starts
the probing with the SIM available.

>
> There are still some open points, here are the most important IMO
>
> A. The modem really needs to be enabled to get the the unsolicited?

No. The modem can be in Failed state, BUT, it will need additional
logic to keep the serial port open listening for QSS.

> B. How to keep the port open.
>

mm_serial_port_open() has an "open count" logic. If you add additional
logic in Failed state, you could keep an "open reference" (meaning you
called open once explicitly).


> Point A
> =======
>
> I added a QSS handler in the plugin along with the other unsolicited in
> `modem_3gpp_setup/enable_unsolicited_events` functions, but this way I can
> register an handler only when modem is enabled, which is not something I
> would allow when SIM is not inserted. I also tried to move the handler
> registration logic inside a new modem-iface's function (namely, not in 3gpp
> iface), but did't work.
> Am I missing something, or enabling the modem is really needed to listen to
> modem's unsolicited?

Enabling modem explicitly opens the port and keeps it open (see
open_ports_enabling()), which is what you need, but you need to add it
additionally in the Failed state.

>
> Point B
> =======
>
> I thought to solve this point adding a parameter "keep_open" to
> MMPortSerialPrivate along with a new function to set it to TRUE, in order to
> keep the port open when open_count==1, but it does not seems to be effective
> (the main issue now is a crash, that I am still debugging, when SIM is
> removed and then re-inserted, like if the port status is invalid,
> "partially" close). Do you think is a viable solution?

No, don't touch the MMPortSerial logic. The object already has the
logic of "open count"; e.g. in open_ports_enabling() we explicitly
open the primary and secondary ports by calling mm_serial_port_open(),
and if those succeed we keep track that we had opened the ports in
ctx->primary_open and ctx->secondary_open (so that we only try to
close them if we had opened them before, i.e. if we are holding the
"open reference"). This info is kept in the PortsContext struct which
is stored in self->priv->enabled_ports_ctx. Different implementations
may have different PortsContext (e.g. QMI has the state of which QMI
clients were allocated), but all have the same purpose: context of
what is the state of the ports when the modem is enabled. What you
should do is to have a new "failed_ports_ctx" PortsContext, or
similar, which would be the state of the ports while in Failed state.
So, when e.g. the modem goes into Failed state during initialization
because it didn't find a SIM card, you would start a new "Failing"
logic, similar to the "Enabling" logic, but with just 2 steps:
preparing a PortsContext with the open ports info, and setting up the
unsolicited messages handlers for QSS. All of this, except for the
actual QSS handler, would be in the generic code; the QSS handler
implementation in the Telit plugin.

-- 
Aleksander
https://aleksander.es