<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hi Aleksander,</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">thank you for this reply, lot of information and clear.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Carlo</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 March 2016 at 10:06, Aleksander Morgado <span dir="ltr"><<a href="mailto:aleksander@aleksander.es" target="_blank">aleksander@aleksander.es</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hey!<br>
<span class=""><br>
On Tue, Mar 22, 2016 at 3:25 PM, Carlo Lobrano <<a href="mailto:c.lobrano@gmail.com">c.lobrano@gmail.com</a>> wrote:<br>
> I had some time now to look at the changes for SIM hot insertion feature<br>
> (QSS unsolicited in Telit modems), lot of doubts actually.<br>
><br>
> My idea is the following:<br>
><br>
> 1. in modem iface initialization, ask the modem whether it supports or not<br>
> SIM hot insertion (TBD: sync method? property?).<br>
<br>
</span>How will you know if it supports SIM hot insertion? Is there any Telit<br>
specific command to do so? Or is it that all Telit modems support it?<br>
If the former, then an async method to query doing initialization; if<br>
the latter, then a property that can be set to TRUE when the modem<br>
object is created from the plugin code.<br>
<span class=""><br>
> 2. according to point 1, if initialization fails for<br>
> MM_MOBILE_EQUIPMENT_ERROR_SIM_NOT_INSERTED, allow the modem enable command<br>
> (I am not sure about this actually, see my note below).<br>
<br>
</span>Hum... no. Don't think this should be the case. Enable() should only<br>
be allowed if the modem is Disabled, which means it isn't Failed,<br>
which means it has SIM.<br>
<span class=""><br>
> 3. In telit plugin, register an handler for QSS unsolicited (3gpp iface)<br>
>     a. when sim is removed<br>
>         - disable modem (mm_modem_disable) keeping the QSS handler (and the<br>
> port open)<br>
>         - set modem in locked state (mm_iface_modem_update_state)<br>
>     b. when sim is inserted<br>
>         - start re-probe (mm_base_modem_set_valid(..., false))<br>
><br>
<br>
</span>This should go in the generic logic, not in the 3GPP logic, I would<br>
say. E.g. the "unlock_required" stuff is not 3GPP only. What I would<br>
do, is:<br>
<br>
 a1) If the modem supports SIM hot plugging and we boot without a SIM,<br>
we end up going to the same Failed state as before, but in this case<br>
we don't just close all ports. We would need some additional extra<br>
logic to be run in Failed state, like opening the port and keeping it<br>
open with the QSS handler set. I would definitely not touch any other<br>
logic.<br>
 a2) If the modem already had a SIM and modem gets enabled; and then<br>
the SIM is removed, we would go first to disable to cleanup everything<br>
and then right away to Failed state (no locked), but with the same<br>
additional logic discussed before to monitor QSS. Or, if you prefer,<br>
you could also try to just set_valid(...,false) as that would reprobe<br>
the modem, and we would end up in case a1) again.<br>
 b) When modem is in Failed state and SIM is inserted, we directly<br>
call set_valid(...,false) to reprobe from scratch, so that it starts<br>
the probing with the SIM available.<br>
<span class=""><br>
><br>
> There are still some open points, here are the most important IMO<br>
><br>
> A. The modem really needs to be enabled to get the the unsolicited?<br>
<br>
</span>No. The modem can be in Failed state, BUT, it will need additional<br>
logic to keep the serial port open listening for QSS.<br>
<span class=""><br>
> B. How to keep the port open.<br>
><br>
<br>
</span>mm_serial_port_open() has an "open count" logic. If you add additional<br>
logic in Failed state, you could keep an "open reference" (meaning you<br>
called open once explicitly).<br>
<span class=""><br>
<br>
> Point A<br>
> =======<br>
><br>
> I added a QSS handler in the plugin along with the other unsolicited in<br>
> `modem_3gpp_setup/enable_unsolicited_events` functions, but this way I can<br>
> register an handler only when modem is enabled, which is not something I<br>
> would allow when SIM is not inserted. I also tried to move the handler<br>
> registration logic inside a new modem-iface's function (namely, not in 3gpp<br>
> iface), but did't work.<br>
> Am I missing something, or enabling the modem is really needed to listen to<br>
> modem's unsolicited?<br>
<br>
</span>Enabling modem explicitly opens the port and keeps it open (see<br>
open_ports_enabling()), which is what you need, but you need to add it<br>
additionally in the Failed state.<br>
<span class=""><br>
><br>
> Point B<br>
> =======<br>
><br>
> I thought to solve this point adding a parameter "keep_open" to<br>
> MMPortSerialPrivate along with a new function to set it to TRUE, in order to<br>
> keep the port open when open_count==1, but it does not seems to be effective<br>
> (the main issue now is a crash, that I am still debugging, when SIM is<br>
> removed and then re-inserted, like if the port status is invalid,<br>
> "partially" close). Do you think is a viable solution?<br>
<br>
</span>No, don't touch the MMPortSerial logic. The object already has the<br>
logic of "open count"; e.g. in open_ports_enabling() we explicitly<br>
open the primary and secondary ports by calling mm_serial_port_open(),<br>
and if those succeed we keep track that we had opened the ports in<br>
ctx->primary_open and ctx->secondary_open (so that we only try to<br>
close them if we had opened them before, i.e. if we are holding the<br>
"open reference"). This info is kept in the PortsContext struct which<br>
is stored in self->priv->enabled_ports_ctx. Different implementations<br>
may have different PortsContext (e.g. QMI has the state of which QMI<br>
clients were allocated), but all have the same purpose: context of<br>
what is the state of the ports when the modem is enabled. What you<br>
should do is to have a new "failed_ports_ctx" PortsContext, or<br>
similar, which would be the state of the ports while in Failed state.<br>
So, when e.g. the modem goes into Failed state during initialization<br>
because it didn't find a SIM card, you would start a new "Failing"<br>
logic, similar to the "Enabling" logic, but with just 2 steps:<br>
preparing a PortsContext with the open ports info, and setting up the<br>
unsolicited messages handlers for QSS. All of this, except for the<br>
actual QSS handler, would be in the generic code; the QSS handler<br>
implementation in the Telit plugin.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Aleksander<br>
<a href="https://aleksander.es" rel="noreferrer" target="_blank">https://aleksander.es</a><br>
</font></span></blockquote></div><br></div>