[PATCH] telit: enable 'SIM ready' notifications with #QSS=2
Carlo Lobrano
c.lobrano at gmail.com
Thu May 25 13:41:00 UTC 2017
On May 25, 2017 3:17 PM, "Carlo Lobrano" <c.lobrano at gmail.com> wrote:
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?
Moreover, I didn't really see any problem with CSIM lock, while waiting
that much for having the modem available is a problem
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/4c605aaa/attachment.html>
More information about the ModemManager-devel
mailing list