As soon as we get a match between the current interface being probed, and the
first expected interface to probe, clear the timeout. But this doesn't mean that
this interface being probed will be the correct one, so it may be the case that
we end up expecting a new first interface and probing another one.
With an example probably seen better...
Modem appears with interfaces 2, 3 and 4.
1. We first try to look for interface 0, which is not in the set:
1.1. Probing interfaces 2, 3 and 4 get deferred.
2. First-interface timeout happens because interface 0 doesn't appear, so we
switch to wait for interface 1:
2.1 Probing interfaces 2, 3 and 4 get deferred.
3. First-interface timeout happens because interface 1 doesn't appear, so we
switch to wait for interface 2:
3.1. We get a match on interface 2, which exists. We now remove the
first-interface timeout and start running the init sequence there.
3.2. Probing interfaces 3 and 4 get deferred.
4. Init sequence in interface 2 fails, because it is not an AT port, so we
switch to wait for interface 3:
3.1. We get a match on interface 3, which exists. We do *not* need to remove
now the first-interface timeout because this interface we are testing is
actually the second one which we tried.
So, just check whether the timeout exists or not, and if it exists remove it.
Yeah, this commit just fixes a warning at the end.
When running the pre-probing VID/PID filters, the ports were not filtered out if
the plugin had configured post-probing vendor/product string filters. But, these
post-probing filters are only applicable to AT ports.
From now on, this logic will not be applied to non-serial ports. In other words,
pre-probing VID/PID filters applied to non-serial ports will always result in
the port being filtered out or being allowed, regardless of any additional
vendor/product string post-probing filter configured by the plugin.
https://bugzilla.gnome.org/show_bug.cgi?id=710437
The logic to decide whether a property is valid in a given PDU type is kind of
fuzzy for 3GPP2 as it is currently implemented; so just print whatever we have
in the interface.
This patch removes an unnecessary G_SIMPLE_ASYNC_RESULT() cast of the
'result' field, which is already of type GSimpleAsyncResult, of
InternalLoadUnlockRequiredContext.
This patch removes unnecessary G_SIMPLE_ASYNC_RESULT() casts of the
'result' field, which is already of type GSimpleAsyncResult, of
InitializeContext, EnablingContext and DisablingContext.
If a client-initiated disconnection attempt is issued while a
network-initiated disconnection is still pending, the latter may
interfere with the former. Also, when the client-initiated disconnection
attempt fails but the bearer status is reported as 'disconnected', the
pending network-initiated disconnection is not cleared and may result
in an assertion when a connection attempt is issued.
This patch addresses the issue by clearing any pending network-initiated
disconnection before proceeding with a client-initiated disconnection.
Instead of using the NO_NETWORK error, which is only ever read
internally by ModemManager and not very useful when reading quality,
just report signal quality as zero. Before MM 1.0, the signal quality
could be explicitly requested by clients, so the NO_NETWORK error was of
some use, but now that the quality is updated automatically by MM and is
a property instead of a D-Bus method call, the error is pointless.
load_subscription_state is called only after a successful registration, so the
default behaviour should be to mark the SIM as provisioned.
This default behaviour is needed because it is not possible for plugins to
detect a successful registration state during the registration update itself.
So, this function is the first place where a plugin can detect a successful
registration update.
Aleksander Morgado
Yuri Chornoivan
Dan Williams
Ben Chan
Prathmesh Prabhu