Update SIM related data according to an event

[Carlo Lobrano]

Hi Aleksander,

thank you for this reply, lot of information and clear.

Carlo

On 23 March 2016 at 10:06, Aleksander Morgado <aleksander at aleksander.es>
wrote:

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