We use capability switching logic exclusively for configuring GSM/UMTS+CDMA/EVDO devices
(regardless of whether it has LTE/5GNR or not) to add or remove the GSM/UMTS and CDMA/EVDO
capabilities.
Based on the same logic, we will allow 4 combinations for GSM/UMTS+CDMA/EVDO+LTE+5GNR device:
"GSM/UMTS+CDMA/EVDO+LTE+5GNR", "GSM/UMTS+LTE+5GNR", "CDMA/EVDO+LTE+5GNR" and "LTE+5GNR"
Similarly, we will allow 4 combinations for GSM/UMTS+CDMA/EVDO+LTE device:
"GSM/UMTS+CDMA/EVDO+LTE", "GSM/UMTS+LTE", "CDMA/EVDO+LTE" and "LTE"
And, we will allow 3 combinations for GSM/UMTS+CDMA/EVDO device:
"GSM/UMTS+CDMA/EVDO", "GSM/UMTS" and "CDMA/EVDO"
Also, supported combination modes should be based on current capabilities and not entirely
upon supported radio interfaces.
1) If current capability has "gsm-umts" or "cdma-evdo" or both, do not
support 4G only, 5G only, or 4G+5G combination modes
2) If current capability neither has "gsm-umts" nor "cdma-evdo", only support
combination modes involving 4G and 5G.
Keep LTE or 5GNR always in current capabilities if supported by device.
Since capability switching logic is exclusively used for configuring
GSM/UMTS+CDMA/EVDO devices, decide if to have GSM/UMTS or CDMA/EVDO or both
or none when loading current capabilities.
On MBIM modems the type of PIN cannot be specified in MBIM_CID_PIN query
command and the modem responds only remaining attempts for the currently
active lock.
If PIN1 is unlocked and user tries to disable (or enable) it, MM won't
get an update of remaining attempts in response to PIN Query. This value
is returned only after the Set command and MM need to store it in
all (pin/puk)_set_(enter/enable/change)_ready functions.
Previous solution was to call the mm_iface_modem_update_unlock_retries
directly from these functions but it caused the notification to be send
too early and invalid number was displayed to user sometimes.
Instead of this MM will store numbers of remaining attempts and send
them in a single notification from modem_load_unlock_retries.
When using udev, we rely on the kernel to timely report port additions
in the same device.
When not using udev, e.g. when using hotplug scripts in openwrt, we
use mmcli --report-kernel-event operations to report the port
additions, which may end up requiring much more time to process,
especially during bootup as we would be reporting a lot of port
addition events one after the other.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/493
The finish() method with the GTask result propagation must be in the
same context as the GTask creation itself, not elsewhere.
Code is reordered so that the async methods can be read from bottom to
top, with the finish() method that includes the GTask result
propagation at the very top.
This new method allows querying the modem for information about the
current serving cell(s) as well as any other neighboring cell that may
be found.
The information for the cells is given in an array of dictionaries,
where each element of the dictionary is a new dictionary itself.
Each cell type has a different set of properties that may be given in
the dictionary, and some of those properties in each type are also
applicable under certain conditions (e.g. only applicable to the cell
if it's a 'serving' cell instead of 'neighboring').
The API documentation explains in detail what is expected in each
case.
We must keep a valid QmiClient reference for as long as the operation
runs, so that we can use it in all the request send operations we do,
and also so that we can remove the indication id upon completing the
operation.
The timeout id and indication id, which are also part of a single
power operation are also included in the operation context, because
they don't have any other meaning out of it.
The operation context is stored as task data.
As in the case of the timeouts, we should not pass a full reference as
data to the signal handler as we don't know how many times we'll
receive the signal or if we'll ever receive it.
We already make sure that the signal handler is disconnected when the
operation ends, so we can be sure the self pointer is valid while the
signal handler is connected.
The timeout may not be called if we remove it earlier (e.g. if the
indication is received) and therefore we must not pass a full new
reference, otherwise it may get leaked.
There is no problem with the validity of the self pointer in timeout
callbacks because we're removing the timeout as part of the operation
teardown logic.
If Mode online is triggered just after Mode LPM and Mode LPM
processing is not complete in modem, modem will not process the next
request and the device will be stuck in an unwanted modem power
state. Thus, wait for a mode change indication from the modem before
declaring that a power on/off has been successful.
Fibocom's documentation states that we must double-check the connection
is established when setting up an ECM connection. The possible replies -
according to the documentation - are:
+GTRNDIS: <state>,<cid>,<ip>,<prim. dns>,<sec. dns>
OK
or
+GTRNDIS: 0
We just care about the state value which is 1 if everything worked.
Quectel EG25-G QMI modem firmware revisions are not matched with carrier configs.
Different VoLTE profiles might be selected by the user causing
the carrier config revision to change.
Since fwupd uses this string for firmware updates, it gets confused and
thinks the user has an update available.
Prakash Pabba
Michal Mazur
Ivan Mikhanchuk
Nagi Marupaka
Iñigo Martínez
Aleksander Morgado
Florence Chan
Daniele
Sven Schwermer
Dylan Van Assche