Dell Snapdragon X62 before FCC Unlock reports no radio interfaces
from QMI and no device capabilities from MBIM. Instead of asserting
in mm_filter_supported_modes() when called from
mm_supported_modes_from_qmi_supported_modes_context() gracefully
handle the lack of supported modes.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
The script was combining all commit messages into one due to the quoting
of "${COMMIT}", rather than leaving unquoted and picking each individual
commit from the space separated string.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
MBIM modems report RSSI and sometimes don't report more detailed RSRP
and SNR info their MBIMex v2 signal-state replies. RSSI gets reported
for every other access technology, and while it's not as good a signal
indicator as the others, we might as well show something.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Consistently interpret the modem's reported custom data class when
loading current mode, supported mode, supported capabilities,
setting current mode, and current access technology.
Normalize the data class to include any custom data class immediately
after reading it from any MBIM message. De-normalize it when sending
back to the modem when setting current modes so the modem receives
MBIM_DATA_CLASS_CUSTOM for the custom mode.
Fixes: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/937
Signed-off-by: Dan Williams <dan@ioncontrol.co>
This enables the usage with busybox and strict environments.
This is related to #483 and the previous commit 91ed72aa, 02baf283.
Signed-off-by: Jongmin Kim <jmkim@debian.org>
`CSCB` has the form
```
CSCB: [0|1],"<channel-list>","<data-coding-scheme>"
```
If the first parameter is `0` this specifies the accepted types if `1`
it specifies rejected.
So far seen in the wild were CSCB strings with accepted types only and a
coding scheme of "" so this is what we handle for the moment.
Signed-off-by: Guido Günther <agx@sigxcpu.org>
For modems that need more time to respond to AT port probes (like some Telit devices,
and Cinterion-based Telit MV31/MV32) allow a custom number of AT probe tries on a
per-port basis for generic probing, or plugins that opt into this functionality.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
If the old IMSI was unavailable because the SIM was locked, but now
is available because the SIM was unlocked, don't treat the SIM
properties change as a hotswap that may trigger dropping and re-probing
the modem.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
The libmm-glib library, as well as the ModemManager headers installed
as part of the D-Bus service API, have always been LGPLv2+ licensed,
because we want users of the service to rely on them in their own
programs, even if they are proprietary.
Some files had an incorrect GPLv2+ header instead of the LGPLv2+ and
that was confusing. All public headers in the MM API have the correct
license text now.
Signed-off-by: Aleksander Morgado <aleksandermj@chromium.org>
If multiple plugins are selected for probing a modem with AT probes,
earlier plugins may only request some probes but not all. When
those probes complete successfully, subsequent plugins won't re-do
the probes that were already completed, but jump to ones that
haven't yet been done.
For example, plugin A may request only AT probes but plugin B
may request AT, AT_PRODUCT, and AT_VENDOR. Plugin B will start
with AT_PRODUCT probes because plugin A already completed the AT
probe.
The code in probe_step() only opened the serial port for the
AT probe, I guess assuming that all AT-type probes would be
done in sequence. But in the above scenario they are not.
Instead, make sure the port is opened for all AT style probes
that have not yet been executed.
Fixes: 7937a89a37 port-probe: rework and consolidate port probe flow for AT/QCDM/QMI/MBIM
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Dan Williams
Guido Günther
Jongmin Kim
Aleksander Morgado