We allow clients to receive asynchronous updates of location
information, e.g. if "location signaling" is explicitly enabled (with
the setup() method).
But if so, we should also allow clients to easily process those
asynchronous updates in the libmm-glib library, instead of requiring
them to run explicit DBus queries to refresh the location information.
These new signaled location APIs allow clients to do so; they can
enable location signaling, and then just wait for the updates to
arrive.
Rework the build_locations() method so that it doesn't take ownership
of the input dictionary. This allows us reusing this method with
dictionaries for which ownership cannot be transferred.
If we return a reference to the internal array in
ensure_internal_supported_storages() and then we free the array
unconditionally in the caller, the next time we call it, the array
would be valid, but it would be fully empty.
Currently, we are not increasing the reference counter of the QrtrNode
when creating a PortQmi for a QRTR port, and we are clearing the object
when disposing the port.
The signal definition is:
<signal name="StateChanged">
<arg name="old" type="i" />
<arg name="new" type="i" />
<arg name="reason" type="u" />
</signal>
So the first two arguments need to be adjusted.
Without this change, the test was failing for me:
(/build/source/tools/tests/.libs/lt-test-stub:77030): GLib-GObject-CRITICAL **: 15:05:35.276: ../gobject/gsignal.c:3167: value for 'gint' parameter 0 for signal "state-changed" is of type 'guint'
==4263== 747 (72 direct, 675 indirect) bytes in 3 blocks are definitely lost in loss record 5,739 of 5,787
==4263== at 0x4842839: malloc (in /usr/libexec/valgrind/vgpreload_memcheck-amd64-linux.so)
==4263== by 0x50C6DE8: g_malloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==4263== by 0x50DDFF1: g_slice_alloc (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==4263== by 0x50B8EB9: g_list_prepend (in /usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6800.1)
==4263== by 0x27CE4C: mm_3gpp_parse_cgdcont_read_response (mm-modem-helpers.c:1845)
==4263== by 0x1E5485: profile_manager_cgdcont_query_ready (mm-broadband-modem.c:10200)
==4263== by 0x4ED54A1: g_simple_async_result_complete (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6800.1)
==4263== by 0x18605E: at_command_ready (mm-base-modem-at.c:538)
==4263== by 0x4ED54A1: g_simple_async_result_complete (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6800.1)
==4263== by 0x25ADFA: serial_command_ready (mm-port-serial-at.c:393)
==4263== by 0x4ED54A1: g_simple_async_result_complete (in /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.6800.1)
==4263== by 0x254752: command_context_complete_and_free (mm-port-serial.c:141)
These lists were used in the corresponding TTY_BLACKLIST and
TTY_MANUAL_SCAN_ONLY filter rules, in the LEGACY and PARANOID filter
types, which are no longer supported.
The DEFAULT_ALLOWED filter rule made sense only in the LEGACY filter
type, and therefore it is also now removed, leaving the
DEFAULT_FORBIDDEN fallback rule exclusively. In other words, there is
now no way to ask ModemManager to implicitly allow TTY ports; the only
way to do that is by explicit making the TTY ports fall in one filter
rule that would allow them.
wwan qcdm port is not a serial port, calling config_fd on it
will always fail, i.e.:
ModemManager[124587]: <debug> [1619584182.125262] [wwan0p1QCDM/probe] probing QCDM...
ModemManager[124587]: <debug> [1619584182.125398] [wwan0p1QCDM/qcdm] opening serial port...
ModemManager[124587]: <debug> [1619584182.151759] [wwan0p1QCDM/qcdm] failed to configure serial device
ModemManager[124587]: <warn> [1619584182.151836] [wwan0p1QCDM/qcdm] failed to open serial device
ModemManager[124587]: <warn> [1619584182.170152] [plugin-manager] task 1,wwan0p1QCDM: error when checking support with plugin 'generic': (wwan/wwan0p1QCDM) Failed to open QCDM port: Failed to open QCDM port: -2
FIREHOSE ports are used for firmware updates which are done
independently from ModemManager, so we should ignore those ports.
A similar change was originally made by Loic Poulain here:
32b0eb79cd
This message is too specific, and there are a lot of cases where it
wouldn't apply.
E.g. when a MBIM module is stuck in low power mode due to some other
reason (like hardware rfkill), this message would pop up to the users
and completely confuse them.
Having a switch() for the MBIM services when processing indications
forces us to update it on every new MBIM service added to libmbim,
because we build with -Wswitch-enum by default.
This warning type is extremely useful, and we should not stop using
it, so let's simplify a bit the indication handling code and skip
using a switch().
There are right now only 4 different service indications expected, so
it shouldn't be a big deal.
After fwupd upgrade with mbim-qdu method, MM sometimes generate plugin failed with the regenerated MHI driver.
This patch increases the mbim_device_open_full timeout from 30 seconds to 45 seconds to prevent such issue.
Signed-off-by: Jarvis Jiang <jarvis.w.jiang@gmail.com>
The original load_connection_status() method would return an
UNSUPPORTED error if connection monitoring wasn't required (which is
the default in most QMI modems).
The new reload_connection_status() method requires the check to always
be done unconditionally.
We take most of the original logic in the load_connection_status() for
the new reload_connection_status(), and we add the UNSUPPORTED error
logic exclusively in the new load_connection_status().
Some of the AT-based connection methods don't have any way to query
connection status, or we don't have a proper implementation for those
yet. Ignore the reload operation in all those.
