> 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 <aleksan...@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 >
_______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
