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.
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.
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.
The generic MBIM modem implementation does not have location
capabilities support, so the relevant function pointers in the
interface are NULL.
Fixes: 306566ad7e
The generic MMBroadbandModemFibocom object uses the shared Fibocom
settings to load the update settings. This logic does not use the
Private info right now, but there is no reason why it wouldn't do it
in the future. Also, for consistency, it makes sense to ensure the
shared interface setup is the same in all implementations, we should
not have only some allowing to initialize the Private info.
Compilation errors due to generated files is observed when
compiling in multi threaded environment, as the generated files
getting generated after they have been referred.
Fix: Added dependency in meson so that it will ensure that the
header is generated.
Ref fail log:
../mobile-broadband/ModemManager/src/plugins/huawei/mm-modem-helpers-huawei.c:29:10:
fatal error: mm-huawei-enums-types.h: No such file or directory
29 | #include "mm-huawei-enums-types.h"
| ^~~~~~~~~~~~~~~~~~~~~~~~~
compilation terminated.
Signed-off-by: Kamesh Relangi <quic_krelangi@quicinc.com>
Rework the AT string quote operation to build the output with the
GString helper, instead of manually calculating how many bytes we'll
need in the output. It just makes it clearer.
Requiring an explicit set of drivers should only be done when we have
different plugins supporting different types of devices of the same
manufacturer based on the drivers in use (e.g. as in the Sierra case).
When the plugin includes a list of required drivers, the plugin filter
will only assume the plugin can be used if at least one of the
available ports is exposed with one of the drivers in the list.
Because of this, if we start probing some ports before all the
expected ports are reported, we may end up not selecting a given
plugin just because the driver match should have been done in a
not-yet-notified port.
E.g. on system boot:
* ttyACM0 is notified.
* min probing time elapses so ttyACM0 probing starts
* Fibocom plugin is not selected for ttyACM0 as no matched
driver ("cdc_acm") is given in the the list of drivers of the
plugin.
* cdc-wdm0 and wwan0 drivers are notified.
* MM creates generic MBIM modem with the Fibocom plugin, but without
XMM features support, because the ttyACM0 port probing was not done
by the Fibocom plugin.
And if we reset the modem after that:
* ttyACM0 is notified.
* cdc-wdm0 and wwan0 drivers are notified.
* min probing time elapses so probing starts for all ports
* Fibocom plugin is selected for all port probings as "cdc_mbim" is
listed in the list of drivers of the plugin.
* MM creates XMM-capable MBIM modem with the Fibocom plugin.