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

Carlo Lobrano c.lobrano at gmail.com
Thu May 25 13:17:18 UTC 2017


Hi,

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


On 16 May 2017 at 12:33, Carlo Lobrano <c.lobrano at gmail.com> wrote:

>
> On 16 May 2017 at 10:53, Aleksander Morgado <aleksander at aleksander.es>
> wrote:
>
>> But g_simple_async_result_complete() can only be called once; as soon
>> as you call it the async call would be completed, not sure what you do
>> with the copy afterwards. Maybe I'm not understanding it properly?
>>
>
> ​No, you got it right, I was looking for a way to re-use the object for
> the pointer to the callback and some other data that at the point where I
> could re-call the load_unlock_step were not available anymore. That said, I
> kind of knew I was doing something wrong​
>
> ​​
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/modemmanager-devel/attachments/20170525/c70d6e51/attachment.html>


More information about the ModemManager-devel mailing list