Huawei plugin sometimes fails to load operator code

[Aleksander Morgado]

On 08/16/2013 09:00 AM, Ben Chan wrote:
> I noticed that the Huawei plugin sometimes fails to load the operator
> code. The issue is that the plugin doesn't register any handler for
> the ^RFSWITCH unsolicited message. When an unhandled ^RFSWITCH
> unsolicited message gets mixed with a +COPS response containing the
> operator code, e.g. <CR><LF>^RFSWITCH: 1,1<CR><LF><CR><LF>+COPS:
> 0,2,"310410",2<CR><LF>, the mm_3gpp_parse_cops_test_response() fails
> to extract the operator code.
> 
> It's kinda tricky to register a handler to ignore ^RFSWITCH
> unsolicited messages as the solicited and unsolicited messages only
> differ by an extra "OK".
>     solicited: <CR><LF>^RFSWITCH: 1,1<CR><LF><CR><LF>OK<CR><LF>
>     unsolicited: <CR><LF>^RFSWITCH: 1,1<CR><LF>
> 
> As AT^CURC=2 is not supported on the MU736, I can't specify an
> unsolicited indication mask to filter out ^RFSWITCH.
> mm_3gpp_parse_cops_test_response() could be changed to handle this
> situation better, but something else may fail.  I wonder if there is a
> better way to resolve this issue.
> 
> AT command is such a messy business :-/

Tricky indeed, yes. The only thing I can think of is to do the following:

 * Configure unsolicited result handler for ^RFSWITCH when the modem is
enabled and remove it when it is disabled.

 * When ^RFSWITCH? is executed in load_power_state(), store the
GAsyncResult in self->priv; and use a NULL user_data. In
huawei_rfswitch_check_ready() we would load the GAsyncResult from
self->priv, if any. Given that ^RFSWITCH? may be called before the modem
is fully enabled, we may actually be receiving the result in
mm_base_modem_at_command_finish() instead of via unsolicited messages;
we do need to consider both cases.

 * When a ^RFSWITCH? message is received (either a real unsolicited one
or one due to a ^RFSWITCH? query), if there is a stored GAsyncResult for
a load_power_state() operation in self->priv, set the result in it,
complete it and unref it; and finally clear the stored GAsyncResult
pointer, so that huawei_rfswitch_check_ready() can afterwards detect
that it was already finished.

 * In the unlikely case that load_power_state() is run and there is
already a GAsyncResult stored; just finish the previous GAsyncResult
with a CANCELLED error. Don't think this will ever happen anyway, just
in case.

What do you think?

-- 
Aleksander