<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div class="im"><br>
</div>Still, isn't it possible to avoid the _is_connect_pending() and<br>
_is_disconnect_pending() calls? Whenever a NDISSTAT message arrives,the<br>
modem object can report the new connection status to the bearer, and<br>
then the bearer decide internally whether to ignore the reported status<br>
(e.g. if a connect or disconnect was pending). Check e.g.<br>
mm_broadband_bearer_hso_report_connection_status() in the option/hso<br>
plugin. I think that would simplify the logic as it would only be in one<br>
place (the bearer) as opposed to in two places (modem and bearer). At<br>
the end, the idea of ignoring NDISSTAT unsolicited messages during a<br>
connection/disconnection sequence is applicable to the actual<br>
connection/disconnection logic, which is implemented in the bearer.<br>
<div class=""><div class="h5"><br></div></div></blockquote><div><br></div><div>Sorry, I didn't clarify the reason behind. On MU736, we observe premature ^NDISSTAT notifications before a network-initiated disconnection actually completes. As a workaround, we need to (in a follow-up patch) defer the invocation of <span style="color:rgb(0,0,0)">mm_bearer_report_disconnection() by a few seconds upon receiving a ^NDISSTAT message. That prevents any premature reconnection, which may drive the modem into a bad state.</span></div>

<div><span style="color:rgb(0,0,0)"><br></span></div><div><span style="color:rgb(0,0,0)">To handle both the client-initiated and network-initiated disconnection, we still need to check whether ^</span>NDISSTAT is received when a bearer is being connected/disconnected.</div>

</div></div></div>