Update SIM related data according to an event

Thu Apr 7 13:42:38 UTC 2016

Hi all,

sorry for the long -email, but I got stuck again in another problem: the
re-probe does not start when the ModemManager is in "SIM missing failed
state" and mm_base_modem_set_valid(..., false) is called.

The current, modified, initialization code has got the following new steps:

1. mm-iface-modem.c:interface_initialization_step has got a new step (sim
hot swap) just before INITIALIZATION_STEP_UNLOCK_REQUIRED(1), where the
modem code is called to

    - enable QSS unsolicited (that signals when the SIM has been
removed/inserted)
    - register a handler to catch the unsolicited.

2. mm-broadband-modem.c:initialize_step has got a new step (again sim hot
swap), just after INITIALIZE_STEP_IFACE_FIRMWARE(2) where it

    - checks whether the modem supports sim hot swap (with a property)
    - creates a new instance of PortsContext and save a reference of it in
ctx->self->priv->sim_hot_swap_ports

Now, when a modem's initialized and SIM is missing, I have: modem disabled
and in failed state, QSS enabled, an handler set and the ports open. When
the SIM is inserted again the handler

1. updates the state to MODEM_STATE_UNKNOWN
2. releases the PortContext kept open to receinve the unsolicited
3. calls mm_base_modem_set_valid(..., FALSE)

but the re-probe does not start as I expected and I can't figure out why.
Is there any precondition for having the reprobe starting as expected?

NOTES
  (1) this step is here because the INITIALIZATION_STEP_UNLOCK_REQUIRED is
the first one that recognizes that the SIM is missing and if so it makes
initialization jumps to INITIALIZATION_STEP_LAST.
  (2) This step is here because when iface-modem initialization fails, we
jump directly to INITIALIZE_STEP_IFACE_FIRMWARE.

Thank you in advance,
Carlo

On Thu, 24 Mar 2016 at 16:50 Carlo Lobrano <c.lobrano at gmail.com> wrote:

> 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/20160407/d4905fa3/attachment.html>