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

[Carlo Lobrano]

> 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.

Ok, the approach might still be wrong (and even more wrong :D), but I only
save the GSimpleAsyncResult for later, I do not stop the call, which is
completed with the usual error messages.

> 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 :/

I see. I've seen a similar approach in port probing, but I thought that
retrying before #QSS:3 didn't have much sense.
I like the idea of the error code though, and yes you're right saying that
this information should arrive as soon as possible, however, consider that
this problem occurs only with a specific SIM vendor and only for PIN2 and
PUK2.
I'm gonna develop this idea further, since I really like to have something
generic and applicable also to other commands that return with SIM Busy
error.


On 15 May 2017 at 12:23, Aleksander Morgado <aleksander at aleksander.es>
wrote:

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