[PATCH] telit: enable 'SIM ready' notifications with #QSS=2

[Aleksander Morgado]

On Thu, May 25, 2017 at 3:41 PM, Carlo Lobrano <c.lobrano at gmail.com> wrote:
> What I was thinking regarding this issue was to define a common error
>> id, like "MM_CORE_ERROR_RETRY_LATER". If the logic (e.g. MMIfaceModem
>> logic) receives such an error, it would re-schedule the execution of
>> that step later on, in X seconds, but would still continue with the
>> remaining steps in the logic it has. But this is really very specific to
>> what we're loading, as not all steps may be retried later.
>
> working on this again. I implemented the "retry in N seconds" logic inside
> mm-iface-modem.c taking "UPDATE_LOCK_INFO_CONTEXT_STEP_LOCK" as example, but
> now I'm considering whether (A) "UPDATE_LOCK_INFO_CONTEXT_STEP_AFTER_UNLOCK"
> should stop the whole "update_lock_info_context_step" process as
> "UPDATE_LOCK_INFO_CONTEXT_STEP_LOCK" does, or (B) I can let the process
> going on and update the unlock retries in the background.
>
> The differences I can see are that (A) with some SIMs the
> "update_lock_info_context_step" would take ~30 seconds to complete (it
> basically waits till QSS 3 arrives), while (B) some requests to the SIM
> might be blocked (because
> of CSIM lock).
>
> I've tried both, but I didn't see any other issues with this two solutions.
> What do you think?
>
>
>
> Moreover, I didn't really see any problem with CSIM lock, while waiting that
> much for having the modem available is a problem

One problem I see is that if we retry unlock retries in the
background, there may be additional steps apart from the unlock
retries that may require access to the SIM. An example here is reading
SMS messages from the SM storage. So what happens with that? Do we
also re-schedule in the background if reading SMS storage tells us SIM
busy?

>From my point of view I'd suggest to do either of these two approaches:
  * If we have a way of the modem telling us the SIM is fully ready, use it.
  * If we don't have that, or if the previous way isn't reliably
enough (or takes too long), then identify which are the steps that may
require retries due to SIM being busy, and handle that retry mechanism
in each step automatically.

In your case with the Telit modem and QSS:3; if we decide that it's
not worth waiting for QSS:3 because it takes too long and for our
purposes we can use it much earlier, then we could do the per-step
retries on SIM busy errors.

The idea of updating in the background and letting the remaining logic
to flow is a bit anarchic, as the user of the API cannot know when the
property values are done populated. Right now we can say that if the
modem says state "disabled" all the initialization steps (from all
interfaces) have been completed; and if we say "enabled" all the
enabling steps (from all interfaces) have been completed.

I know the initialization and enabling logic would go much faster if
we just retry and populate properties in the background, but do we
want that?

-- 
Aleksander
https://aleksander.es