| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
This would be the application id that refers to the active SIM card.
|
|
Get PCO information after the call is established
by using get runtime settings request
Register for Extended IP configuration Indication
If PCO is changed we get the indication and refetch
the pco information from modem
Send the PCO info using 3gpp_update_pco_list
|
|
|
|
EM120/160 uses QCDM port for firmware updates. fwupd lists all known
ports from ModemManager and uses QCDM port to reboot the modem into
the firmware download mode.
|
|
For SDX55 and SDX65 can identify the corrrect plugin(cinterion), and the plugin is updated to support the wwan subsystem.
|
|
|
|
|
|
We setup all output variables with g_autofree and then use
g_steal_pointer() to return the needed ones.
|
|
We setup all output variables with g_autofree and then use
g_steal_pointer() to return the needed ones.
|
|
We setup all output variables with g_autoptr() and then use
g_steal_pointer() to return the needed ones.
|
|
We setup all output variables with g_autofree and then use
g_steal_pointer() to return the needed ones.
|
|
The behavior of GRegex changed in 2.73.2 once it was ported from pcre1
to pcre2. In some cases it was made more strict, which is fine, in
other cases it exposed some change in how it behaves on certain
matches that is not extremely clear whether it's ok or not.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2729
See https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/601
See https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/621
Either way, one thing that was assumed was that initializing all
GRegex/GMatchInfo variables to NULL and making sure they're NULL
before they're initialized by glib (especially the GMatchInfo) was a
good and safer approach.
So, whenever possible, g_autoptr() is used to cleanup the allocated
GMatchInfo/GRegex variables, and otherwise, g_clear_pointer() is used
to ensure that no free/unref is attempted unless the given variable is
not NULL, and also so that the variable is reseted to NULL after being
disposed.
|
|
Access technology and location properties are updated if modem is in
registered state.
Cache and update them when processing DSD system status indication.
|
|
Currently, supported band AT query #BND=? is failing with LM9x0 because
it expects BND 4G decimal format instead than hexadecimal.
Adding also LN920 and FN980 for completeness. They do not fail right now
because they have also "4g band extended" which format is always
hexadecimal.
|
|
Looks like pcre2 (used since glib 2.73.2) requires EOLs to match if
G_REGEX_NEWLINE_CRLF is explicitly used. The tests are updated
accordingly, because the modem responses will anyway have the EOLs
as well.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2729#note_1544130
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/601
|
|
Passed undetected when glib2 was using pcre1, it triggers an error now
with pcre2.
See https://gitlab.gnome.org/GNOME/glib/-/issues/2729#note_1542038
Reported and fix suggested by: Marco Trevisan (Treviño) <mail@3v1n0.net>
|
|
Modem could be in 'registered' state if CS is 'attached',
but packet service state might be 'detached'.
Check if packet service state needs to be updated in
update_registration_state(), even if registration state is same.
Fixes: https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/618
|
|
|
|
Fixes 3238ccdbb29e86acd2b3e5c0e45bee84f9da94b4
|
|
|
|
==10719== Invalid free() / delete / delete[] / realloc()
==10719== at 0x4897D88: free (vg_replace_malloc.c:872)
==10719== by 0x52F091B: g_free (gmem.c:220)
==10719== by 0x530C36B: g_slice_free1 (gslice.c:1185)
==10719== by 0x52D632B: g_error_free (gerror.c:872)
==10719== by 0x192DBF: UnknownInlinedFun (glib-autocleanups.h:54)
==10719== by 0x192DBF: UnknownInlinedFun (glib-autocleanups.h:54)
==10719== by 0x192DBF: sync_ready (mm-base-modem.c:671)
==10719== by 0x50A82CB: g_task_return_now (gtask.c:1232)
==10719== by 0x50A854B: UnknownInlinedFun (gtask.c:1301)
==10719== by 0x50A854B: g_task_return (gtask.c:1258)
==10719== by 0x50AAA4F: g_task_return_new_error (gtask.c:1944)
==10719== by 0x1F44E3: iface_modem_sync_ready (mm-broadband-modem.c:12205)
==10719== by 0x50A82CB: g_task_return_now (gtask.c:1232)
==10719== by 0x50A854B: UnknownInlinedFun (gtask.c:1301)
==10719== by 0x50A854B: g_task_return (gtask.c:1258)
==10719== by 0x1AB86B: interface_syncing_step.lto_priv.0 (mm-iface-modem.c:4644)
==10719== Address 0x910bf30 is 0 bytes inside a block of size 16 free'd
==10719== at 0x4897D88: free (vg_replace_malloc.c:872)
==10719== by 0x52F091B: g_free (gmem.c:220)
==10719== by 0x530C36B: g_slice_free1 (gslice.c:1185)
==10719== by 0x52D632B: g_error_free (gerror.c:872)
==10719== by 0x17565F: UnknownInlinedFun (glib-autocleanups.h:54)
==10719== by 0x17565F: UnknownInlinedFun (glib-autocleanups.h:54)
==10719== by 0x17565F: base_modem_sync_ready (mm-base-manager.c:737)
==10719== by 0x50A82CB: g_task_return_now (gtask.c:1232)
==10719== by 0x50A854B: UnknownInlinedFun (gtask.c:1301)
==10719== by 0x50A854B: g_task_return (gtask.c:1258)
==10719== by 0x192DAB: sync_ready (mm-base-modem.c:674)
==10719== by 0x50A82CB: g_task_return_now (gtask.c:1232)
==10719== by 0x50A854B: UnknownInlinedFun (gtask.c:1301)
==10719== by 0x50A854B: g_task_return (gtask.c:1258)
==10719== by 0x50AAA4F: g_task_return_new_error (gtask.c:1944)
==10719== by 0x1F44E3: iface_modem_sync_ready (mm-broadband-modem.c:12205)
==10719== Block was alloc'd at
==10719== at 0x48952CC: malloc (vg_replace_malloc.c:381)
==10719== by 0x52F3EF3: g_malloc (gmem.c:127)
==10719== by 0x530CD27: g_slice_alloc (gslice.c:1074)
==10719== by 0x530D2B7: g_slice_alloc0 (gslice.c:1100)
==10719== by 0x52D5E7B: g_error_allocate (gerror.c:710)
==10719== by 0x52D690F: UnknownInlinedFun (gerror.c:724)
==10719== by 0x52D690F: g_error_new_valist (gerror.c:766)
==10719== by 0x50AAA43: g_task_return_new_error (gtask.c:1941)
==10719== by 0x1F44E3: iface_modem_sync_ready (mm-broadband-modem.c:12205)
==10719== by 0x50A82CB: g_task_return_now (gtask.c:1232)
==10719== by 0x50A854B: UnknownInlinedFun (gtask.c:1301)
==10719== by 0x50A854B: g_task_return (gtask.c:1258)
==10719== by 0x1AB86B: interface_syncing_step.lto_priv.0 (mm-iface-modem.c:4644)
==10719== by 0x1AB9A3: UnknownInlinedFun (mm-iface-modem.c:4543)
==10719== by 0x1AB9A3: interface_syncing_step.lto_priv.0 (mm-iface-modem.c:4639)
|
|
|
|
|
|
Found during code review.
|
|
|
|
Modem reports 2G+3G+4G+5G current modes, while 2G is not supported.
Consider device capabilities in deciding current modes.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Multiplexing currently does not work correctly for BAM-DMUX because
ModemManager reuses the same WDS client for all data points. A second
bearer can be created but it effectively disables the first one.
Fix this similar to the existing checks for the mux-id by including the
endpoint type and number in the QMI client flags.
|
|
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.
|
|
mm_broadband_modem_qmi_peek_port_qmi() already looks up a QMI port
exactly the same way it is implemented in the BAM-DMUX variant of
peek_port_qmi_for_data(), so we can just reuse it to simplify the code.
No functional change.
|
|
"Bind Data Port" does not work correctly on newer platforms with
BAM-DMUX (e.g. MSM8909). It returns "device unsupported" even for
valid SIO port numbers.
As an alternative, it seems to be possible to use the newer "Bind *Mux*
Data Port" instead. This works even when QMAP multiplexing is disabled
(using WDA "Set Data Format"). In this case the mux-id seems to be
entirely ignored and can be a dummy value such as MUX_ID_UNBOUND.
Implement this by checking for the error code of "Bind Data Port"
and fallback to "Bind Mux Data Port" instead.
The important part in this case is that the endpoint type and interface
number are set correctly. At the moment this works only for the "wwan0"
interface because the endpoint information is currently maintained
globally as part of the QMI control port instead of being handled
separately per data/net port. Further refactoring is needed to enable
multiplexing on these platforms.
|
|
At the moment the endpoint type and number for the QMI WDA calls are
chosen based on the subsystem of the QMI control port. This does not
work correctly for some configurations:
- SUBSYS_QRTR currently implies ENDPOINT_TYPE_EMBEDDED, but this is
only valid for QRTR+IPA configurations. For QRTR+BAM-DMUX the
correct type is ENDPOINT_TYPE_BAM_DMUX.
- SUBSYS_WWAN currently implies ENDPOINT_TYPE_PCIE, but there is
already a comment that mentions that this selection works only for
MHI/PCIe modems. SUBSYS_WWAN is also used by RPMSG+BAM-DMUX
configurations in which case the correct type is also
ENDPOINT_TYPE_BAM_DMUX.
Looking closer at these cases suggests that the endpoint type actually
refers to the data/net port and not the control port. It is more
reliable choose it based on the network driver and not the subsystem
of the control port.
Address this partially by choosing the endpoint type based on the
net_driver. Choosing the endpoint interface number correctly requires
more refactoring since most of the logic is currently handled globally
for a QMI control port, while it's actually specific to the chosen
data/net port in some cases (e.g. multiple BAM-DMUX network interfaces).
|
|
mm-dispatcher-fcc-unlock.c:100:27: warning: unused variable 'error' [-Wunused-variable]
g_autoptr(GError) error = NULL;
^
|
|
mm-broadband-modem-mbim.c:8525:30: warning: unused variable 'message' [-Wunused-variable]
g_autoptr(MbimMessage) message = NULL;
^
mm-broadband-modem-mbim.c:8582:29: warning: unused variable 'message' [-Wunused-variable]
g_autoptr(MbimMessage) message = NULL;
^
|
|
mm-broadband-modem.c:10703:23: warning: unused variable 'cmd' [-Wunused-variable]
g_autofree gchar *cmd = NULL;
^
|
|
Since 1.18 the user can request a different APN type during the
connection attempt, which translates into a different context type in
the actual MBIM Connect Set request. Therefore, the context type of a
given connection is no longer always INTERNET.
Matching by the session id to report disconnections should be more
than enough, which also helps to cover the case where the modem
doesn't report the original context type used during the
attempt (e.g. reporting NONE unconditionally).
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/614
|
|
|
|
|
