On Thu, May 25, 2017 at 3:41 PM, Carlo Lobrano <c.lobr...@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 _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
