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

[Aleksander Morgado]

Hey hey,

On 12/05/17 16:18, Carlo Lobrano wrote:
> ​> Maybe it wouldn't be a bad idea to keep track of which operations may
>> fail due to SIM being busy, and perform automatic retry later if we
>> get that specific error, something like that.
> Hey,
> 
> I made a little proof of concept of this improvement. So far, it's
> restricted to *loading unlock retries again once #QSS:3* is received, but I
> can't get to have the retries values updated at a higher level. This is
> likely due to *mm-iface-modem.c:load_unlock_retries_ready* callback not
> being called I guess, but I'm not really sure my approach is totally
> correct.
> 
> I do the following:
> 
> A. When mm_telit_parse_csim_response fails:
>     1. The *GSimpleAsyncResult* instance is saved
>     2. load_unlock_retries is marked to be called again later
> B. When QSS: 3 arrives:
>     1. a newly *LoadUnlockRetriesContext* is created using the saved
> *GSimpleAsyncResult* (the idea is to re-use the original callback
> reference, but not really sure it's correct).
>     2. *load_unlock_retries_step* is called again with the above mentioned
> LoadUnlockRetriesContext instance
> 
> Step 2 is done in a GSourceFunc called by the mainloop, using g_add_idle.

Hum... not sure this approach is the correct one. If you store the
GSimpleAsyncResult and not complete it the whole logic in the
MMIfaceModem will get stuck until it is completed afterwards. The logic
in MMIfaceModem goes step by step, if one step takes 5 minutes to
complete, the next steps won't go on until that happens.

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.

For the specific case of loading unlock retries... does it make sense
for us to report e.g. that the modem is "locked" but without being able
to report the unlock retries left after some time later? From a user
point of view, I'm sure that an application that receives notification
that the modem is locked would expect right away to know the amount of
unlock retries left, if we report that several seconds later the
information will likely not be used at all.

So I'm not sure whether this makes sense; waiting for "QSS: 3"
guarantees that we'll be able to read unlock retries; but maybe it's
just cleaner to perform several retries trying to load them as that may
be quicker than waiting for "QSS: 3"... it really is very unfortunate
that this notification takes so long to be emitted :/

-- 
Aleksander
https://aleksander.es