Currently, MBIM broadband Telit modem does not store firmware revision
into 'software_package_version', so it won't be possible to specialize
behavior based on modem model (using mm_telit_model_from_revision).
This change overloads load-revision in MBIM broadband Telit in order to
call parent's loading and store the returned 'caps_firmware_info' into
'software_package_version' via mm_shared_telit_store_revision.
The new QCDM probing mechanism does not probe and grab QCDM ports
if the plugin is not allowed, so QCDM ports currently ignored in
compositions can be safely marked as ID_MM_PORT_TYPE_QCDM.
In mm_telit_model_from_revision there is nothing that prevents to use
the input revision string if it is NULL, which currently happens if
the modem is pure MBIM (i.e. LE910-V2 pid:0x0032).
Fix the above error returning a default safe value and not using the
NULL variable.
We no longer have separate mm_base_modem_process_sim_event() and
mm_broadband_modem_sim_hot_swap_detected() methods. The only
difference between both of them was that one of them would attempt to
cleanup the ports context associated to the SIM hot swap event logic
as soon as a swap was detected, in order to avoid queueing up multiple
such events.
The previous logic wasn't working well, though, as there could be
mixed AT+QMI or AT+MBIM devices that would also require that same
cleanup and so we didn't always know which one should have been
called.
Now we have a single mm_iface_modem_process_sim_event() method, which
will trigger the reprobe and disabling, but which will also perform
the cleanup of the SIM ports swap setup as specified by the
implementation.
So, if a plugin explicitly initializes the serial ports context for
SIM hot swap handling, it should also explicitly clean it up.
Also, the initialization of the serial ports context for SIM hot swap
handling is no longer done automatically for all modems, it will be
done only for those modems using it; i.e. the modems that explicitly
report support SIM hot swap handling using AT URCs.
This property is used in the MMIfaceModem to flag whether the SIM hot
swap setup has been performed or not. The flag is now moved to the
iface-specific private context.
The property was also used in AT-based modems, so that implementations
supporting the SIM hot swap via AT URCs could flag the upper layers
whether the enabling of the feature was done correctly or not, and if
so, create and keep the AT ports context open. But this feature only
made sense in AT-based modems, i.e. an MBIM modem that detects SIM hot
swaps via MBIM indications exclusively should not require the AT ports
context open for anything. The check in the MMBroadbandModem object
has therefore been removed, and the logic will be updated so that it
only applies to AT-based modems.
In some cases the "base" software package string does not have the
currently expected format of \d{2}.\d{2}.\d{3}. Specifically the last
triplet of characters might not be digits. For example a valid version
string might be 25.20.-04, which the current regex is unable to parse.
This change replace the previous regex with one less restrictive,
checking only the first part of the version's format.
Currently the Telit modem implements modem_after_sim_unlock() with 1s
timeout, however the #QSS URC management (introduced later) waits for
QSS=1 URC in csim_unlock_periodic_check up to 3s, which makes this 1s
delay not necessary anymore.
see also:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/3
Some modems, like LE910C1-EUX, express the LTE part of #BND output in
HEX format, but currently the MM parser for such case is limited to
modems that have "ext_4g_bands". This commits use the new MMTelitModel
info to decide how to parse #BND command output.
Fixes#487
Telit revision string can be used to identify the specific model, which
in turn is useful to specialize the behavior of the plugin.
This change adds revision parsing to detect some telit modems. Initially
it adds the ones that have different behaviors in #BND output parsing
for example.
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);
^
Carlo Lobrano
Daniele Palmas
Aleksander Morgado
Carlo Lobrano
Iñigo Martínez
Amol Lad
David Khouya