The power up and down operations are already synchronized at
interface level, so there is already a guarantee that they won't
happen at the same time.
For the reset and power off operations, it is assumed that the modem
will either reset or power off, so there should be no need to sync
those operations with others, as the modem object will eventually go
away altogether in both cases.
If a request to lock the operation with the override type arrives, all
pending operations will be immediately cancelled, and no new lock
requests will be allowed.
Follow up changes will introduce support to run exclusive enable and
disable operations, effectively ensuring that only one enabling or
disabling task is processed at any given time, so the support for
completing parallel operations with the same result is no longer
needed.
That logic was anyway flawed, as it did not consider complex cases
like a disable request received between two enable requests, the order
of incoming requests was not maintained.
The main reason for adding the parallel enable/disable operation logic
was for the case where 2 separate users tried to enable the modem at
the same time. In that case, we did not want to run 2 separate
enabling operations from scratch, and completing one would complete
the second one as well. With the new operation lock logic, the same
result is achieved, as the 2nd enabling operation would find the modem
already enabled, if the 1st one succeeded.
This removal is done before introducing the new exclusive operation
support in the enable/disable path in order to make it easier and more
consistent with other operations that will also be included in the
synchronization.
There are certain operations that cannot be run in parallel, e.g. one
should not disable and bring the modem to low power mode while there
are also incoming requests to enable the modem. This type of errors
will typically happen when multiple DBus clients are trying to use the
same modem at the same time for different purposes.
We do not have any way to have DBus clients take exclusive ownership
of a given modem object, so the best we can do for now is trying to
synchronize operations that cannot be run together, preserving the
order in which they arrived, and running them one by one.
The modem state property update was happening at disabling task context
free time, after the actual task completion has happened.
Avoid wrong assumptions on the modem state value in operations
scheduled after the task completion, in the same way as done in the
enabling sequence.
The modem state property update was happening at enabling task context
free time, after the actual task completion has happened. Due to this,
scheduling a new enable request right after finishing one would end up
with the logic asserting, as the new enable operation would be
scheduled while the modem was still reporting "enabling" state.
ModemManager[7673]: <inf> [1722359278.131123] [modem0] processing user request to enable modem...
**
ERROR:../src/mm-broadband-modem.c:12487:enable: code should not be reached
Bail out! ERROR:../src/mm-broadband-modem.c:12487:enable: code should not be reached
Aborted
Currently the SIM operator name and code are read using the "Home
Provider" query operation which may perform network communication
to get name provided by operator. This may take long to complete
or even timeout. Solution is to read name and id from SIM card.
Sometimes Qualcomm modem is not detected because modem is up
after initial probing is completed.
Increase in wait time for probing to ensure that modem is up.
If the system and modem are independently powered, a system restart may
leave one of the modem's AT ports in PPP mode. On restart this may cause
AT probing to fail. The modem may terminate PPP after receiving bogus
HDLC frames from QCDM probing (since PPP also uses HDLC framing), and
return "NO CARRIER". We can use this to restart AT probing now that
PPP is down and auto-detect the expected additional AT ports.
Feb 08 20:22:53 ModemManager[385]: <debug> [1675887773.887574] [ttyUSB2/at] <-- '\8\158\239~'
Feb 08 20:22:54 ModemManager[385]: <debug> [1675887774.215054] [ttyUSB2/at] <-- '\8\214\137~'
Feb 08 20:22:54 ModemManager[385]: <debug> [1675887774.851349] [ttyUSB2/at] <-- '\8\250\177~'
Feb 08 20:22:55 ModemManager[385]: <debug> [1675887775.576776] [ttyUSB2/at] <-- '\8\168u~'
Feb 08 20:22:55 ModemManager[385]: <debug> [1675887775.612694] [ttyUSB2/at] <-- '\8w\25~'
Feb 08 20:22:55 ModemManager[385]: <debug> [1675887775.862886] [ttyUSB2/at] <-- '\8!&~'
Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.614747] [ttyUSB2/at] <-- '\8%\254~'
Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.686207] [ttyUSB2/probe] port is not AT-capable
Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.686447] [ttyUSB2/probe] probing QCDM...
Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.725483] [ttyUSB2/qcdm] --> 7e 00 78 f0 7e
Feb 08 20:22:56 ModemManager[385]: <debug> [1675887776.880941] [ttyUSB2/qcdm] <-- 0d 0a 4e 4f 20 43 41 52 52 49 45 52 0d 0a
Signed-off-by: Dan Williams <dan@ioncontrol.co>
Open the AT port from the regular port probe flow rather than doing
that one-off at the beginning of probing. That lets us re-open the AT
port later if needed, based on QCDM/QMI/MBIM probing results.
Signed-off-by: Dan Williams <dan@ioncontrol.co>
The L850 seems to report 0xFFFFFFFF as MbimContextIpType value, which
is not a correct value.
Instead of printing "(none)" (the default used by glib when trying to
print a NULL pointer as a string), make it so that we end up printing
the actual numeric value in hex.
<dbg> [modem0] 'home' settings found at configuration index 0
<dbg> [modem0] 'non-partner' settings found at configuration index 1
<dbg> [modem0] 'partner' settings not found
<dbg> [modem0] updates in the home LTE attach configuration settings:
<dbg> [modem0] ip type: 'unknown (0xffffffff)' -> ''ipv4v6'
<dbg> [modem0] updates in the partner LTE attach configuration settings:
<dbg> [modem0] none (skipped)
<dbg> [modem0] updates in the non-partner LTE attach configuration settings:
<dbg> [modem0] none
Instead of updating the attach settings associated with the home
network, update all three to the same values, so that network attach
while roaming uses the same settings as in home.
This is a major change in behavior; if there is ever a need to roll
back to the old behavior because a given device doesn't support this,
we can provided device-specific behaviors using the
load_set_initial_eps_bearer_settings_mask() virtual method.
L850 modems running a firmware version less than 18500.5001.0.7 and
using AT&T SIM cards with MCCMNC 310280 do not support specifying
"partner" settings in the MBIM operation to set the LTE attach
configuration.
The ModemManager API provides a single method to update the attach
settings used in LTE registration, but in the MBIM protocol there are
three different distinct configurations associated with that
operation.
Until now we have exclusively updated the "home" settings, leaving the
"partner" and "non-partner" settings untouched (i.e. we loaded the
existing settings for these sections, and used the same ones when
providing our update operation).
Unfortunately, this logic does not fit all needs. Some modems will
require all 3 elements to be unconditionally updated, and some other
modems may need to fully skip one of the configuration sections.
The rework done in this commit does not change the behavior, but
provides the ability for subclasses to modify how the operation is
done, via a set of flags that is provided on each update attempt (as
sometimes the behavior is operator-specific).
We look for the home settings, but also allow to optionally lookup for
the partner and non-partner settings, logging in each case if we find
anomalies (e.g. if not found or if found duplicated entries).
This helps identify which base sms the message belongs to.
Previous
[modem0/sms-list] found existing multipart SMS object with reference
'126': adding new part
New
[modem0/sms0] found existing multipart SMS object with reference
'126': adding new part
Signed-off-by: Kyle Evans <kvans32@gmail.com>
Messages from different senders can have the same reference.
Stale messages from the same sender can also conflict.
Consider the number of the sender and also the max parts
when assigning parts to a base sms.
Ref 3gpp specification section 9.2.3.24.1
Fixes#757
Signed-off-by: Kyle Evans <kvans32@gmail.com>
The device always reports empty TX/RX values so there is no point in
periodically asking.
The logic to poll for stats is kept in place only if the device
requires the IP packet filters removal hack.
Aleksander Morgado
Akula Susmitha
Aleksander Morgado
Michal Mazur
Dan Williams
Kamesh Relangi
Lukas Voegl
Kyle Evans
mank.wang
Vanillan Wang
Daniele Palmas