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)) {
| ^
Since this plugin uses a bitmask to represent bands, we have
to be wary of shifting outside the precision of the bitmask
storage type. In this case, it was possible to generate 1 << 31
in a signed integer type as an intermediate step of B3G_FLAG,
which is undefined behavior (and usually results in INT_MIN,
breaking comparisons with the value).
Bug was reported to the chromium tracker at crbug.com/1019301
Original patch updated by Aleksander Morgado to leave
MM_MODEM_BAND_TELIT_3G_LAST as MM_MODEM_BAND_UTRAN_19, as that is the
highest 3G band supported by the current implementation. Worth noting
that this was not a real bug as the maximum flag we would have been
setting was (1 << 19) anyway.
It was observed that sporadically it may take more than 5 seconds for modem to
respond to AT#REBOOT. Increase the timeout on AT command to not report
unnecessary errors to the user.
And added support for several new things, including:
* Setting "any" band now attempts to set all supported bands.
* Added new 2G band value '5' (egsm+dcs+pcs+g850).
* Setup support for two different 3G band combinations, a default one
plus an alternate one applicable to the LM940/960 models only. The
alternate combination is selected via udev tags.
During the refactor, the following Telit-specific helpers were also
removed and exchanged with more generic counterparts.
* mm_telit_bands_contains() -> mm_common_bands_garray_lookup()
* mm_telit_get_band_flags_from_string() -> mm_parse_uint_list()
Aleksander Morgado
Daniele Palmas
David Khouya
Krzysztof Drobinski
Eric Caruso
Krzysztof Drobinski