Once upon a time it was a good idea to have separate steps for CS and PS related
actions, so that plugins could override specific steps with a great detail. That
idea turned out to be not very useful, as the only case which requires custom
CS/PS registration actions is the QMI-enabled modem, and that one has commands
to act on both registration actions at the same time. So, we now consolidate
all steps, so that the implementation of the interface needs to provide all the
logic to setup/enable/disable/cleanup/check registrations in each mode.
Also, we consolidate how the unsolicited registration messages are handled, so
that it's equivalent to other unsolicited messages:
* 'Setup' will configure ports to process the unsolicited messages.
* 'Enable' will tell the modem to send unsolicited messages.
* 'Disable' will tell the modem not to send unsolicited messages.
* 'Cleanup will configure ports to ignore the unsolicited messages.
The previous logic would first request to check if indicators were supported,
and only then allow to setup/enable/cleanup/disable unsolicited events. This
behaviour is very specific to the generic 3GPP case, and therefore it shouldn't
be handled in the even more generic 3GPP interface. The logic is still kept,
but handled within the MMBroadbandModem object.
If a port support task was deferred until suggested, do not assume that the
suggested plugin actually supports the port, instead re-launch support check.
This covers the cases where a net port appears in a modem which only supports
AT ports (e.g. Nokia case).
Turns out we can check supported bands by asking the modem what
the enabled state is for the bands it says it supports, and then
setting the enabled state to what it currently is. For bands the
modem actually doesn't support, it'll return an error. Use that
to build up the modem's actual supported band list.
In the connection and disconnection sequences, we make sure that the Bearer
object is valid by keeping a reference in the Dial3gppContext and
Disconnect3gppContext (actually, another one kept by the GSimpleAsyncResult as
well). But we are considering here the case where the context is completed and
freed by an unsolicited message handler before we get the reply to the AT
command, so to properly ensure that the bearer object is still valid when we try
to check if the context is in the priv struct, we need to keep an extra ref
around.
In the connection sequence, we make sure that the Bearer object is valid by
keeping a reference in the Dial3gppContext (actually, another one kept by the
GSimpleAsyncResult as well). But we are considering here the case where the
connection context is completed and freed by an unsolicited message handler
before we get the reply to the AT command, so to properly ensure that the bearer
object is still valid when we try to check if the context is in the priv struct,
we need to keep an extra ref around.
In the connection sequence, we keep the context in the private info of the
Bearer object, so that we can complete and free it when we receive OWANCALL
unsolicited messages. Now, the reply of the OWANCALL itself may get processed
as an unsolicited message, so effectively we're processing and finishing the
connection/disconnection context *before* we process the reply of the AT
command.
This patch ensures that we do not try to re-use the connection context after it
has been processed by the unsolicited messages handler.
Dan Williams
Aleksander Morgado