[PATCH c2] huawei: handle disconnection via ^NDISSTAT unsolicited message

[Aleksander Morgado]

On 18/09/13 09:05, Ben Chan wrote:
> 
>     Still, isn't it possible to avoid the _is_connect_pending() and
>     _is_disconnect_pending() calls? Whenever a NDISSTAT message arrives,the
>     modem object can report the new connection status to the bearer, and
>     then the bearer decide internally whether to ignore the reported status
>     (e.g. if a connect or disconnect was pending). Check e.g.
>     mm_broadband_bearer_hso_report_connection_status() in the option/hso
>     plugin. I think that would simplify the logic as it would only be in one
>     place (the bearer) as opposed to in two places (modem and bearer). At
>     the end, the idea of ignoring NDISSTAT unsolicited messages during a
>     connection/disconnection sequence is applicable to the actual
>     connection/disconnection logic, which is implemented in the bearer.
> 
> 
> 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 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.
> 
> To handle both the client-initiated and network-initiated disconnection,
> we still need to check whether ^NDISSTAT is received when a bearer is
> being connected/disconnected.

And can't the modem report the disconnection status right away, and only
let the bearer afterwards decide whether it wants to disconnect right
away or defer the disconnection a bit? That would still keep the logic
within the bearer; and the modem object is just the receiver of the
unsolicited message which forwards the info to the bearer, which is the
one applying the logic.

If we get a NDISSTAT saying we're disconnected by the network and we
cannot act right away, maybe we can NDISTATQRY? ourselves for some time
to see when we really got disconnected? Or are the responses of these
NDISSTATQRY? queries also unreliable? Or maybe we could set the bearer
in 'disconnecting' state until we make sure that the bearer is fully
disconnected after some seconds?

-- 
Aleksander