<div dir="ltr">Thanks Dan, that's what I thought. I understand the problem for shipping this with 1.6, so 1.6.2 for me is fine. </div> <div class="gmail_quote"><div dir="ltr">On Thu, 12 May 2016 at 18:17 Dan Williams <<a href="mailto:dcbw@redhat.com">dcbw@redhat.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, 2016-05-04 at 17:21 +0200, Carlo Lobrano wrote: > Hi, > > I observed a problem in getting the number of unlock retries of some > SIMs soon after the unlock (the SIM in not completely ready I assume) > and I saw that some plug-ins inserted a little delay in > modem_after_sim_unlock to cope with it, but that wouldn't have any > effect in my case. > > I could delay directly the AT command I use (+CPIN), but that would > be > done every time, not only when the SIM is just unlocked, so I was > wondering why in mm-iface-modem.c:update_lock_info_context_step > function the state machine processes load_unlock_retries before > modem_after_sim_unlock. Is there any known issue in executing > after_sim_unlock step before load_unlock_retries? I took a quick look at the code, and I don't think there'd be a problem with moving UPDATE_LOCK_INFO_CONTEXT_STEP_RETRIES after UPDATE_LOCK_INFO_CONTEXT_STEP_AFTER_UNLOCK. If the SIM is still locked, then AFTER_UNLOCK won't fire (eg, no effect), and if the modem is unlocked, then it should be ready by the time it's done. Given the impact I don't think we want to land this for 1.6, but right after and then potentially release as part of 1.6.2? Dan </blockquote></div>