The whole codebase is updated to assume the MMBaseModem AT operations
require an object implementing the MMIfacePortAt interface, instead of
a MMPortSerialAt object.
In the places where we know the port is a MMPortSerialAt, e.g. when we
query explicitly for the primary or secondary serial AT port, we will
use an explicit MM_IFACE_PORT_AT() cast when calling the AT command
method.
In the places where we get_best_at_port() we're going to assume that
we don't know the port type. This method will be updated in a follow
up commit to support the MMIfacePortAt interface as well.
No functional changes should happen.
The purpose of this change is to align coding style with the rest of
the project and also simplify the implementation of the different AT
command handling methods, e.g. to avoid needing so many internal
helper methods.
The new modem_initialize() method is run for both real devices (after
the modem setup phase) and also for virtual devices in unit
tests (where no modem setup phase exists).
There are cases where the user wants to configure some actions
to be run on a modem before ModemManager takes over full control.
The new "modem setup" dispatcher scripts allow running operations
in the modem after the port probing has happened and we know which
ports are usable in the device.
The scripts may e.g. change device configuration, enable modem
logging infrastructure, or any other process that would otherwise
conflict with MM's own modem management operations.
This uses the proprietary `^NDISSTATQRY` instead of the default
`+CGDCONT` command, as the latter might return diffrent results
(i.e. reporting v6 support, that can't be used via NDIS).
Also add a fallback to `+CGDCONT?` for older modems that don't
support ^NDISSTATQRY.
Refactor the loading/setting of supported/current modes/bands,
mostly to enable LTE support via ^SYSCFGEX.
This unfortunately requires many changes at once, as these methods
use the same AT commands and their fallbacks.
When sending or storing an SMS, the per-part operation is itself split
into two steps: first we send the AT command specifying the index, and
then we send the actual PDU data with a raw command. We must ensure
that the raw command is sent exactly in the same port as the AT
command.
Since commit 63dd4ad2 it is possible that the GPS interface is in use at
the time of modem reinitialization so it should not be stopped in such
case.
Otherwise "mmcli --location-status" will still say that GPS is enabled but
no GPS traces are going to be coming.
This avoids the "port in device added after device probing has already
finished" warning, and also the creation of modem objects for single
port devices.
Currently, the operator description update is only triggered once in the
entire update process. But this can lead to a operator description
updated at the wrong time. And is therefore possibly wrong.
The deprecated API call 'qmi_client_nas_get_serving_system' always triggers
an update of the operator description in there subfunction of the callback.
This is missing for the API call 'qmi_client_nas_get_system_info'. To solve
this, an update is now also triggered in the subfunction callback if there
is new system info available.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
When using a modem with the qmi plugin, the operator description is only
set once for the current modem object. This is the operator description
of the mobile network to which the modem has first established a connection.
The operator description will no longer be updated even though on a
reconnection with a different mobile network.
Normally this is not a problem, as the SIM card usually dials into the
home network and stays there. But if an IoT SIM card is used, then this
is a problem because the operator description is no longer updated.
To fix this, the 'current_operator_description' is always loaded on
'modem_3gpp_load_operator_name' regardless of whether an operator
description has ever been set.
Signed-off-by: Florian Eckert <fe@dev.tdt.de>
The modem location interface loads modem location capabilities only during
the very first initialization of this interface.
On each later reinitialization it skips loading these capabilities from
modem, however it still goes through the whole interface initialization
state machine.
This state machine uses its own "ctx->capabilities" field for temporary
capabilities storage, which is set to MM_MODEM_LOCATION_SOURCE_NONE at the
start of the initialization process.
However, if we aren't actually loading modem location capabilities because
we're only reinitializing the interface we still need to set this
"ctx->capabilities" field to the existing (previously loaded) modem
location capabilities.
Otherwise the next interface initialization step (validation) will
permanently disable the whole location interface.
Aleksander Morgado
Lukas Voegl
Aleksander Morgado
Nero
Oliver Kästner
Maciej S. Szmigiero
Florian Eckert
Dan Williams