| Age | Commit message (Collapse) | Author |
|---|
|
The process doing the unlock required checks may need a lot of retries
e.g. to decide whether a SIM card is available or not. If we do a
quick SIM eject, so the unlock required check starts looping, and then
insert the SIM again, we expect the loop to be cancelled right away,
so that the new modem object can be reprobed without any interference
from the old modem object.
We now take the modem-wide cancellable and bind it to the GTask in
mm_iface_modem_update_lock_info(), and we pass it down to every
sub-step of the async logic in the operation. We also plug the
cancellable to the delayed retries in the interface logic, to allow
aborting the checks right away
|
|
QMI_VOICE_USER_ACTION_NOT_REQUIRED.
This fixes a bug where network-initiated USSD-Notify messages were not
processed (and forwarded to higher-level applications) at all, while
they should have been processed (and forwareded to higher-level
applications). Previously, when there was a USSD conversation between
the user and the network, the last message from the network (which, by
definition, is not a message with
user_action==QMI_VOICE_USER_ACTION_REQUIRED) would be silently
dropped.
The cause is a mismatch between the modem sending
user_action==QMI_VOICE_USER_ACTION_UNKNOWN while old ModemManager
expecting user_action==QMI_VOICE_USER_ACTION_NOT_REQUIRED.
|
|
Signed-off-by: Lukas Voegl <lvoegl@tdt.de>
|
|
Certain QMI or MBIM devices may not be able to support multiplexing at
all, or they may support a limited amount of links.
The new ID_MM_MAX_MULTIPLEXED_LINKS udev tag allows specifying the
maximum number of supported multiplexed links; e.g. 0 to report none
supported or 1 to report that one single multiplexed link is
supported.
|
|
When the host is resuming from system suspend, QMI indications
sent by the modem at resume time can be lost. The exact reason why it
happens is still unknown. Until this is fixed, ModemManager currently
workarounds that in QMI mode by listening and reacting to AT URCs too,
which are being received reliably. In order to achieve that,
messaging_setup_unsolicited_events chains the parent's implementation
with its own, effectively setting up handlers for both AT and QMI
channels.
This worked fine on modems such as EG25 which enable SMS indications
by default. However, some modems, such as BM818, don't have these
indications enabled on boot and don't report incoming messages via AT
unless requested via AT+CNMI.
To make SMS handling on resume reliable on such modems, make sure
that MMBroadbandModemQmi also enables/disables unsolicited events
in the same way it already sets up handlers for them.
Signed-off-by: Sebastian Krzyszkowiak <dos@dosowisko.net>
|
|
We now support modem-reported packet service state, instead of
guessing it in the 3GPP interface logic.
The DSD system status reporting a valid access technology is an
indication that the packet service is ready. Instead of holding back
the registration status until the DSD system status reports a valid
value, we will now report the modem as registered, and bind the DSD
system status exclusively to the packet service status.
In the simple connection attempt we're already waiting first for being
registered, and then for being attached in PS.
|
|
The personalization feature enum used in "card status" is different to
the one used in other UIM operations like "depersonalization".
libqmi dependency updated to 1.33.6 to ensure we can use the new types.
|
|
|
|
|
|
reached
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/646
|
|
|
|
operations"
This reverts commit dad3e8274723805e3957f166ba158a37cf6a96ec.
Disabling profile change indications just before doing our profile
updates and re-enabling them just after is not enough. The modem may
still emit the profile change indication right after, so all this
logic is unnecessary.
|
|
Just ignoring the received indications is not enough, because they
could arrive after the operation response has been processed.
We now explicitly disable the indications by reconfiguring the modem
before and after every profile update operation triggered by our own
logic.
|
|
info indication
|
|
|
|
This commit modifies the QMI DMS Operating Mode indication registration logic.
During the power sequence chance, if a QMI_PROTOCOL_ERROR_MISSING_ARGUMENT error
was returned in "DMS Set Event Report" operation for Operating Mode Reporting failed,
the whole sequence was aborted, leading the modem to be disabled.
<debug> [modem0] Power indication registration request is sent
...
<debug> [modem0] couldn't update power state: Couldn't register for power indications: QMI protocol error (17): 'MissingArgument'
<warn> [modem0] couldn't enable interface: 'Couldn't register for power indications: QMI protocol error (17): 'MissingArgument''
<debug> [modem0] running implicit disable after failed enable...
This commit modifies the logic to properly detect the failure and
continue the sequence without the indications.
Fixes #683
Signed-off-by: Louis-Alexis Eyraud <louis-alexis.eyraud@unabiz.com>
|
|
The device may emit a "WDS Profile Changed" indication triggered from
our own "WDS Modify Profile", "WDS Create Profile" or "WDS Delete
Profile" operations, so ensure those are fully ignored so that we
don't emit the "Updated" signal in the ProfileManager interface.
The logic keeps track of the amount of concurrent operations so that
the signal is ignored for as long as there is at least one operation
running.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/687
|
|
Letting the MMBroadbandModemQmi listen for the notifications of the
QmiDevice was not a good idea, especially since no explicit reference
to the device object was hold in the modem object. This leads to race
conditions in which the QmiDevice outlives the MMBroadbandModemQmi and
the MMPortQmi, and when the "device-removed" signal is triggered, the
program crashes.
The MMPortQmi will now emit its own 'removed' signals when the
underlying QmiDevice emits "device-removed', ensuring that the signal
handler is properly cleared up during the MMPortQmi disposal.
|
|
client missing
Using mm_shared_qmi_ensure_client() ensures that the client must exist
or otherwise the operation would fail. Instead, try to peek the
clients independently with mm_shared_qmi_peek_client() and only fail
if both exist.
The state machine logic already treats the clients as optional.
|
|
Update profile manager and notify clients if there is a change in modem
profiles list.
|
|
When processing the NAS Signal Info message, don't assume that a
previously processed TLV creates the MMSignal object for a given
access technology.
|
|
|
|
value needs to be divided by 10 as for LTE
|
|
|
|
|
|
|
|
We're bumping the current "INFO" level messages to the new "MSG"
level, also making the new level the default.
The old "INFO" level will be used to setup an intermediate level of
logging which is not as verbose as "DEBUG" but still provides some
capabilities to analyze the behavior of a modem.
|
|
message
If "enable refresh" is set, QMI modem expects an acknowledgement upon receiving a PDC refresh indication,
otherwise the modem resets assuming clients are facing an issue in refreshing their cache.
Register for PDC refresh indication without setting "enable refresh" TLV.
We would still receive the refresh indication to notify that the list of profiles stored has changed and
would not have to acknowledge the modem.
|
|
|
|
Same as we do in the MBIM protocol implementation.
|
|
The SAR enable operation may be selecting an explicit SAR level by
itself, so make sure the protocol implementation reports back to the
interface the default level that was used while enabling SAR.
No level change is reported in the interface if the SAR is being
disabled.
|
|
Otherwise the SAR support check will fail.
|
|
Implement the sar interface for QMI modems.
|
|
When processing QMI and MBIM messages to report domain registration
updates, we should do that altogether so that we don't report bogus
transitions to idle if the registration state switches from one domain
to another.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/629
|
|
Access technology and location properties are updated if modem is in
registered state.
Cache and update them when processing DSD system status indication.
|
|
At the moment the endpoint type/number is chosen based on the QMI
control port. The assumption is that multiplexing is implemented using
an additional protocol layer (e.g. QMAP) or that each network interface
has its own QMI control port.
This is not necessarily the case for BAM-DMUX. To use the built-in
multiplexing the WDS client must be bound to the correct data port.
This works already for older firmware versions using "Bind Data Port"
(SIO port numbers), but not for newer ones using "Bind Mux Data Port"
(endpoint type/interface numbers).
Make it work for newer firmware versions as well by choosing the
endpoint type/number based on the data port similar to the existing
implementation for SIO port numbers.
Note: The correct endpoint interface number is currently only used for
the steps in mm-bearer-qmi. Ideally more refactoring should be done in
mm-port-qmi to call WDA Set Data Format for each of the endpoints.
In practice it usually works fine without because the data format is
set correctly by default.
|
|
Now that peek_port_qmi_for_data_mhi() is a separate function it becomes
obvious that it looks different from all the others: There is no check
that a QMI port was actually found.
Add it similar to the one used for qmi_wwan.
|
|
peek_port_qmi_for_data() is currently quite confusing to read because it
mostly covers qmi_wwan while the mhi_net case returns early. Split this
up into separate functions per driver to make it less confusing, similar
to the variant in mm-broadband-modem-qmi-qcom-soc.
No functional change.
|
|
We provide a consolidated method to update the PS/EPS/5GS registration
states, based on the actual state reported via NAS and the availabiity
or not of the DSD data RAT.
On this consolidated method, we now force the IDLE state for every
case where it would have been HOME/ROAMING if the data RAT reported
via the DSD service is unknown. This includes not only transitions
into the HOME/ROAMING state, but also transitions to unknown data RAT.
|
|
'SetPacketServiceState()'
|
|
for PS domain
"registered" state should not wholly depend on the PS/EPS/5GS domain
state reported by NAS.
It should listen to DSD system status for availabilty of data network
at modem before moving to 'registered' state".
|
|
|
|
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.
|
|
or "NAS serving system"
For NR5G NSA, both LTE and NR5G should be set in access technology.
Use NAS "system info" or "serving system", instead of NAS "signal info"
or "signal strength", for deciding access technology based on current
registration state.
|
|
The rights each contributor has are the ones stated by the GPL/LGPL,
not more and not less.
|
|
QmiMessageDmsGetStoredImageInfoInput type
|
|
setup/cleanup/enable/disable
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 uses the PDC Refresh indication to notify clients that
there is a new list of profiles.
|
|
We were returning success on this operation upon an UNSUPPORTED error,
and we should keep on doing the same after all the indication support
changes.
|
|
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.
|
