Currently, firmware revision string is obtained via AT+CGMR or AT+GMR
commands from the default mm-broadband-modem. For a class of Telit
modems however this command does not return the actual Telit Software
Package version, but the "Modem FW Version", which is only a component
of the whole firmware. For this class of modems, the correct string is
obtained with "AT#SWPKGV" command.
This change overrides load_revision* functions to add the ability to
parse "AT#SWPKGV" command for the modems that support it, and falls back
to the same logic that was implemented in mm-broadband-modem otherwise.
The `broadmobi`, `dlink`, `telit` and `tplink` plugins include the
`mm-port-enums-types.h` header. However, they do not use any symbol
defined there.
The `huawei` plugin as includes the `mm-port-enums-types.h` header
but it does not include the build targets as dependencies.
These issues have been fixed by removing the unnecessary includes
from `broadmobi`, `dlink`, `telit` and `tplink` plugins and by
including the enums build target in the `huawei` target.
Telit modems that require hexadecimal number when specifying 4G bands
also reply to #BND=? command with a 4th parameter <LTE_band_ext>
(e.g. LM940, LM960, LN920, FN980).
On the other hand, modems that require decimal number when specifying 4G
bands only return 3 parameters to the same command.
It is then possible replace the detection of ext_4g_bands via UDEV tags
with an inspection of BND=? reply.
Fix the following segmentation fault:
ModemManager[128007]: mm_port_peek_kernel_device: assertion 'MM_IS_PORT (self)' failed
Thread 1 "ModemManager" received signal SIGSEGV, Segmentation fault.
0x00005555556c6e3e in mm_kernel_device_get_global_property
(self=0x0, property=0x7ffff5947480 "ID_MM_TELIT_BND_ALTERNATE")
at kerneldevice/mm-kernel-device.c:309
Reported by Carlo Lobrano <c.lobrano@gmail.com>
There are modems out there, that reuse the same vid:pid for multiple
USB layouts, so there may be port type hints that are not really
applicable in all layouts.
E.g. the EM7565 in MBIM layout uses interface #0 for the MBIM port,
while in QMI layout it uses interface #0 for the QCDM port (which is
what the port type hint included in MM states). With these rules, if
we don't bind the port type hint to TTY ports only, we would be
wrongly flagging the MBIM port as possible QCDM port:
<debug> [plugin/sierra] probes required for port cdc-wdm0: 'mbim'
<debug> [cdc-wdm0/probe] no AT/QMI/MBIM probing in possible QCDM port
<debug> [cdc-wdm0/probe] port is not AT-capable
<debug> [cdc-wdm0/probe] port is not QMI-capable
<debug> [cdc-wdm0/probe] port is not MBIM-capable
<debug> [cdc-wdm0/probe] port probing finished: no more probings needed
Avoid this, by making sure all port type hints are added exclusively
to TTY ports. It's not a perfect solution, but it's enough for the
known cases.
We already have methods to query for interface specific attributes
like class/subclass/protocol, so add a new one for the interface
number, and make sure we use ATTRS{bInterfaceNumber} to load it
always, instead of assuming the ID_USB_INTERFACE_NUM property is set.
Back in Linux < 3.6 days, the cdc-wdm ports exposed by the QMI driver
were flagged as owned by the 'usb' subsystem. That changed in 3.6 when
the subsystem was renamed to 'usbmisc':
https://mail.gnome.org/archives/networkmanager-list/2012-June/msg00125.html
This patch removes all monitoring of the 'usb' subsystem completely,
which is anyway a valid subsystem but for which we shouldn't need any
special handling. Right now, with newer kernels, we were using that
monitoring exclusively to get notified of full USB device remove
events, which is really not required as we already process the port
removals one by one.
We simplify the logic everywhere that attempted to match either the
'usb' or 'usbmisc' subsystems, and we no longer require the explicit
checks for the port name being named 'cdc-wdm[0-9]*' in the code, as
that is already taken care of by the ID_MM_CANDIDATE udev tag rule.
Add a polling mechanism for port responsiveness, since some modem
families require some time before being usable after the serial
ports have been exposed by the kernel.
While at this change also the previous generic reference to ME910
in order to differentiate between ME910C1 (based on MDM9206) and
MEx10G1 (based on MDM9205).
Instead of using the FALSE return of the method to indicate either a
fatal error (if result_error was set) or the continuation request (if
result_error wasn't set), provide a enum that has explicit states for
all three possible values (failure, success or continue).
We can safely cast the data in a GArray to gpointer first, and then
to the pointer type we require.
telit/mm-modem-helpers-telit.c: In function 'mm_telit_build_bnd_request':
telit/mm-modem-helpers-telit.c:256:55: error: cast increases required alignment of target type [-Werror=cast-align]
bands_str = mm_common_build_bands_string ((const MMModemBand *)(bands_array->data), bands_array->len);
^
telit/mm-modem-helpers-telit.c:275:55: error: cast increases required alignment of target type [-Werror=cast-align]
bands_str = mm_common_build_bands_string ((const MMModemBand *)(bands_array->data), bands_array->len);
^
It has the same exact format as MMBaseModemAtCommand, but its contents
are assumed heap allocated.
The only real purpose of this type is to allow defining static
constant MMBaseModemAtCommand variables without warnings when using
-Wdiscarded-qualifiers.
telit/mm-broadband-modem-telit.c: In function ‘qss_setup_step’:
telit/mm-broadband-modem-telit.c:619:22: error: this statement may fall through [-Werror=implicit-fallthrough=]
619 | ctx->step++;
| ~~~~~~~~~^~
telit/mm-broadband-modem-telit.c:620:9: note: here
620 | case QSS_SETUP_STEP_QUERY:
| ^~~~
telit/mm-broadband-modem-telit.c:653:22: error: this statement may fall through [-Werror=implicit-fallthrough=]
653 | ctx->step++;
| ~~~~~~~~~^~
telit/mm-broadband-modem-telit.c:654:9: note: here
654 | case QSS_SETUP_STEP_LAST:
| ^~~~
telit/mm-broadband-modem-telit.c: In function ‘load_unlock_retries_step’:
telit/mm-broadband-modem-telit.c:906:22: error: this statement may fall through [-Werror=implicit-fallthrough=]
906 | ctx->step++;
| ~~~~~~~~~^~
telit/mm-broadband-modem-telit.c:907:9: note: here
907 | case LOAD_UNLOCK_RETRIES_STEP_LOCK:
| ^~~~
telit/mm-broadband-modem-telit.c: In function ‘gps_enabled_ready’:
telit/mm-broadband-modem-telit.c:191:30: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’ [-Werror=sign-compare]
191 | if (ctx->gps_enable_step < G_N_ELEMENTS (gps_enable)) {
| ^
telit/mm-broadband-modem-telit.c: In function ‘parent_enable_location_gathering_ready’:
telit/mm-broadband-modem-telit.c:254:43: error: comparison of integer expressions of different signedness: ‘gint’ {aka ‘int’} and ‘long unsigned int’ [-Werror=sign-compare]
254 | if (start_gps && ctx->gps_enable_step < G_N_ELEMENTS (gps_enable)) {
| ^
Carlo Lobrano
Daniele Palmas
Iñigo Martínez
Carlo Lobrano
Amol Lad
Aleksander Morgado
David Khouya