Currently, when SIM hot swap fails in either mm-iface or plugin, the
ModemManager still opens ports context and prints a message saying that
SIM hot swap is supported and that it's waiting for SIM insertion,
instead of clearly saying that SIM hot swap is not working.
This patch:
1. introduces a new property MM_IFACE_MODEM_SIM_HOT_SWAP_CONFIGURED
which is FALSE by default and set to TRUE only when
setup_sim_hot_swap_finish() succeded.
2. subordinates the completion of SIM hot swap setup (in
mm-broadband-modem) and the related messages to the the value of
MM_IFACE_MODEM_SIM_HOT_SWAP_CONFIGURED
Finally, this patch replaces the MBIM's sim_hot_swap_on private property
with the new property MM_IFACE_MODEM_SIM_HOT_SWAP_CONFIGURED, since they have the
same meaning.
Plugins have two ways to update signal quality and access technology
values: via unsolicited messages or via polling periodically.
Instead of keeping separate contexts for polling signal quality and
access technology values, we setup a common timeout to trigger
both. This allows us to simplify in which case the explicit update is
required, whenever one is needed to be explicitly updated, the other
one should also be.
The logic now also allows plugins to return an UNSUPPORTED error in
either load_signal_quality() and/or load_access_technologies() to tell
the interface logic that the polling of the specific item shouldn't be
performed (e.g. if the updates are expected via unsolicited messages).
If both signal quality and access technology polling is flagged as
disabled, we totally disable the polling logic internally.
The new SignalCheckContext is bound to the lifetime of the object so
that we can keep the value of the supported flags until the object is
destroyed.
BaseModem
added reprobe property.
MMDevice
added logic to recreate the modem if it is set invalid and "to reprobe"
MMBroadbandModem
* added initialization step for SIM hot swap:
1. keep dedicated ports open to listen to modem's unsolicited
2. dedicated error management in case of initialization failure due to SIM missing
* added function to be called in order to act upon SIM insertion/removal:
1. close dedicated ports
2. set the modem to be reprobed
3. disable modem
* added SIM HOT SWAP boolean property
MMIfaceModem
* added initialization step for SIM hot swap, if supported by the plugin
* dedicated error management in case of initialization failure due to SIM missing
There are systems in which the modem power source can be controlled externally,
e.g. to switch it on or off. In these cases, it is sometimes advisable to be
able to tell the modem to cleanly shut off completely before the power is cut.
So, allow transitioning to the OFF power state if the modem supports it, even if
afterwards the modem could be completely unreachable.
And also make it a list of masks, specifying which are the specific combinations
supported, not just one mask with all.
E.g.:
-------------------------
Hardware | manufacturer: 'Sierra Wireless, Incorporated'
| model: 'MC7710'
| revision: 'SWI9200X_03.05.19.04ap r5475 carmd-en-10527 2012/09/17 17:57:14'
| supported: 'gsm-umts
| gsm-umts, lte'
| current: 'gsm-umts, lte'
| equipment id: '358178040668164'
We now have a single 'CurrentModes' property which contains both values in a
tuple with signature "(uu)".
Also, rename 'SetAllowedModes()' to 'SetCurrentModes()', and update the list of
arguments expected to have a single "(uu)" tuple.
Instead of a custom modem_init() step in the 'Modem' interface, just add a
sequence of port initialization commands in each port.
While enabling for the first time a non-hotplugged modem, we will issue the
port initialization commands only after having run the enabling_modem_init()
step (i.e. after ATZ usually).
The logic to handle the lock information (current lock and unlock retry count)
wasn't handling all possible cases properly, e.g.:
* When PIN is incorrectly entered too many times, a SIM-PUK error may happen.
In this case we need to directly assume SIM-PUK is the current lock (some
modems, like Option HSO ones, would incorrectly reply SIM-PIN if CPIN? asked
just after the SIM-PUK error).
* After every operation acting in SIM locks, we need to update the current
unlock retry count.
This change tries to cover those cases, by:
* The logic to check current lock is extended to also load the unlock retry
count when needed.
* Whenever a SIM-PUK error happens in the SIM operations, we directly assume
that SIM-PUK is required, without re-asking CPIN?.
* The overall logic of lock checking is now handled by a state machine, which
is much easier to understand.
Both the ModemManager daemon and the mmcli will now include `libmm-glib.h' only.
We also handle two new special `_LIBMM_INSIDE_MM' and `LIBMM_INSIDE_MMCLI'
symbols, which if included before the `libmm-glib.h' library allow us to:
* Don't include the libmm-glib high level API in the ModemManager daemon, as
the object names would clash with those in the core.
* Define some of the methods of helper objects to be included only if compiling
ModemManager daemon or the mmcli.
The power-down command defined by the plugin will be run *only* after having
checked for current and modem capabilities, as plugins (e.g. Sierra) may have
different commands for that depending on whether they are 3GPP or 3GPP2.
We do not reuse the 'modem_power_down' callback from the disabling sequence, as
some plugins really behave pretty badly with this (e.g. Samsung CFUN=4 may take
up to 30s to complete). So, we let plugins use the power-down command when
disabling but avoid launching it during init.
Renamed `MMCommonSimpleProperties' to `MMSimpleStatus', and removed the
`MMSimpleStatusProperties' provided in libmm-glib. We'll just use the original
one from libmm-common always.
Renamed `MMCommonBearerProperties' to `MMBearerProperties', and removed the
`MMBearerProperties' provided in libmm-glib. We'll just use the original one
from libmm-common always.
Equivalent to `PinRetryCount' in the previous API. We don't have an additional
property for the retry count of the current lock, as it really is duplicating
information.
ModemManager will load:
1) The list of supported bands. Note that this doesn't mean that any possible
combination of bands is supported, as modems may support only specific
combinations, but at least gives a rough idea of what the modem is capable
of handling.
2) The list of CURRENT bands. There is no such "Allowed" bands, as we do with
modes, modems will have a specific set of bands being currently used, which
will be reported in the `Bands' property.
If the modem allows modifying the list of bands to use, this can be done with
the `SetBands()' method. If the modem doesn't support using a specific
combination of bands, this method will report an error.
