<div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Hi Aleksander, Tim,<br></div><div class="gmail_extra"><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif"><div class="gmail-m_-1112195928841340225gmail-yj6qo gmail-m_-1112195928841340225gmail-ajU"><div id="gmail-m_-1112195928841340225gmail-:15z" class="gmail-m_-1112195928841340225gmail-ajR">I just reproduced the issue on my hardware, so I can develop a patch for this<br></div></div></div></div></blockquote><div style="font-family:arial,helvetica,sans-serif" class="gmail_default"><br><br>after some analysis, I think that the fix for this issue should count two steps<br><br>1. When +CSIM=1 is sent, the QSS handler should ignore QSS unsolicited -> I brefly solved this with a "<b>is_csim_locked</b>" boolean in MMBroadbandModemTelit priv, set by <b>csim_lock_ready</b> and read by the handler.<br><br>2. As well as +CSIM=1 causes a #QSS=0, even +CSIM=0 causes a #QSS=1, but this time we need to wait for this unsolicited to come before accepting any other call to the SIM. Considering that the very next call is +CSRM, we need to stop soon after unlocking SIM interface.<br><br>I think I can do this in <b>csim_unlock_ready</b>, waiting 'till the QSS handler receives #QSS=1 (and up to some maximum amount of time, like 3-5 seconds, just to be sure), but since this will stop the entire process I preferred to share this idea with you before working on it.<br><br>what do you think?​</div></div></div></div>