This patch fixes the following compiler warning:
xmm/mm-modem-helpers-xmm.c:388:38: error: implicitly declaring library function 'strlen' with type 'unsigned long (const char *)' [-Werror,-Wimplicit-function-declaration]
g_regex_match_full (r, response, strlen (response), 0, 0, &match_info, &inner_error);
^
This patch fixes the following compiler warning:
mm-shared-qmi.c:447:9: error: implicitly declaring library function 'memset' with type 'void *(void *, int, unsigned long)' [-Werror,-Wimplicit-function-declaration]
memset (buf, 0, sizeof (buf));
^
Implement a new interface to keep the code shared between the QMI and
non-QMI modem implementations.
While doing that, also fix the parent interface pointer handling, so
that it isn't a static pointer applicable to all modems, and make it a
per-modem specific pointer. Without this fix, ModemManager would crash
if e.g. running with both a QMI and non-QMI Cinterion modem at the
same time.
The new shared Cinterion logic will be in charge of managing all GPS
sources not already managed by the parent interface. E.g. if the
parent implementation already supports QMI-based GPS location (using
the LOC service for example) prefer that to the custom AT-based
logic.
Most of all the other APIs we have are expecting binary data (e.g.
UCS-2 encoded strings) in ASCII hex format, because they were going
to be used in text AT commands. For binary protocols allowing binary
data, we need use a more generic API that provides an explicit data
size.
Configuring reports every 5s may lead to GPGGA traces reported like this:
$GPGGA,211645.00,,,,,0,,,,,,,,*4D
$GPGGA,211646.00,4030.003988,N,00330.761876,W,1,07,1.0,691.6,M,53.0,M,,*74
$GPGGA,211650.00,,,,,0,,,,,,,,*49
$GPGGA,211651.00,4030.005405,N,00330.763540,W,1,07,1.0,688.9,M,53.0,M,,*71
$GPGGA,211655.00,,,,,0,,,,,,,,*4C
$GPGGA,211656.00,4030.008074,N,00330.765338,W,1,07,0.9,679.9,M,53.0,M,,*70
$GPGGA,211700.00,,,,,0,,,,,,,,*4D
$GPGGA,211701.00,4030.009258,N,00330.765510,W,1,07,1.0,678.3,M,53.0,M,,*71
$GPGGA,211705.00,,,,,0,,,,,,,,*48
Which is totally undesirable, as the GPS location would be flapping
between set and unset.
Use the default of 1s explicitly, which behaves properly.
For non-Qualcomm MBIM devices, report a generic "Unsupported" error if
we try to do an operation that would otherwise be only available with
QMI-over-MBIM.
The gpsOneXTRA assistance data provides a convenient way to inject
predicted orbit information into the module, without requiring to have
an Internet connection in the module itself.
Sometimes SUPL-server based A-GPS is not possible, e.g. if the module
doesn't have Internet connectivity. In such cases, the modem may
support injecting additional "assistance data" that may be downloaded
from the Internet using external means (e.g. WiFi), in order to keep
having a quick time to first fix.
We now support using this location assistance data, with the following
new API elements:
* A new mask of supported assistance data types is provided in the
SupportedAssistanceData property.
* A new list of URLs from where the aassistance data may be
downloaded is also provided in a new AssistanceDataServers
property.
* A new InjectAssistanceData() method is provided, to perform the
data injection in the module once it's been downloaded to the host
system.
This new interface will include implementations that are shared
between the MMBroadbandModemQmi and the MMBroadbandModemMbim.
For now, it just provides a way to implement the common client
allocation methods.
Most Qualcomm-based MBIM devices also support QMI over MBIM. We will
try to check in runtime whether the MBIM device supports QMI over
MBIM, and if so, setup a QmiDevice within the MMPortMbim.