| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
We're hardcoding the supported bands for each u-blox model, so there
really is no point in having unit tests for them.
|
|
|
|
|
|
When we're changing modes or bands, we only need to keep track of the
initial power state when CFUN=4/CFUN=1 based logic is used. When using
COPS, we do not need to track initial power state or recover it after
the operation.
|
|
|
|
We're not going to use CFUN/COPS just for bands, but also for modes,
so use more generic names.
|
|
If both UBANDSEL and UACT are unsupported, we were not initializing
the command variable.
|
|
If both UACT and UBANDSEL are unsupported, the async operation was
never completed.
|
|
Make mm_ublox_get_support_config() return FALSE only when GError is
set. And also, prepare a preload_support_config() method to be run
before using any information from the support configuration (i.e.
don't do it in load_supported_bands(), do it in load_current_bands()
or in set_current_bands().
|
|
The implemented register_in_network() was totally unused.
|
|
acquire_power_operation (MMBroadbandModemUblox *self,
^~~~~~~~~~~~~~~~~~~~~~~
ublox/mm-broadband-modem-ublox.c:74:1: error: no previous prototype for ‘acquire_power_operation’ [-Werror=missing-prototypes]
|
|
ublox/mm-modem-helpers-ublox.c:1291:14: error: unused variable ‘found’ [-Werror=unused-variable]
gboolean found;
^~~~~
|
|
ublox/mm-modem-helpers-ublox.c:1298:5: error: ISO C90 forbids mixed declarations and code [-Werror=declaration-after-statement]
guint i, j, k;
^~~~~
|
|
If mm_ublox_get_supported_bands() and mm_ublox_get_support_config()
both failed, we would be completing the GTask twice. Fix it by
chaining both steps so that the second one is not run if the first one
is already failed.
|
|
|
|
The u-blox plugin was originally written to support the TOBY-L4 only.
This caused issues with mmcli reporting the correct supported and
current bands because the logic was based only for the TOBY-L4 and
the AT commands used in the implementaion are only supported by
a couple of modems.
There is now a hard-coded modem list that contains the supported bands
and the supported modes. A hard-coded list was chosen over a logic
based list because ublox modems only report the frequency of the bands
they support in the current mode they are in. For further justification,
the reported frequency could relate to multiple bands that are not all
supported by the modem, and not all the supported bands are always caught
depending on the mode the modem is in (e.g. 2G, 3G, 4G). The only
realiable way to retrieve the correct supported bands is to have the list
hard-coded. Based off of the modem, the code chooses whether it is
appropriate to issue +UACT or +UBANDSEL to retrieve the current bands list.
Additionally, the appropriate AT command of +CFUN=4 or +COPS=2 is chosen
to detach from the network when the mmcli --set-current-bands command is
issued. The new setup also adds a header file that contains the modem list.
This should make adding support for future additional modems easier as long
as future modems stick to the same AT command interface that is currently
supported by the plugin.
|
|
|
|
|
|
No need to process the detailed dictionary if no explicit method is
reported as supported. Avoids unnecessary warnings:
$ mmcli -m 1 --firmware-status
** (mmcli:6887): WARNING **: 15:52:54.664: Invalid initial update settings: Missing required 'device-ids' setting
error: firmware status unsupported
|
|
|
|
|
|
We're running g_async_initable_new_async() ourselves in
mm_manager_new(), so our finish() method should call
g_async_initable_new_finish() explicitly.
There's no change in the logic here, as the generated
mm_gdbus_object_manager_client_new_finish() was already doing this
implicitly.
|
|
The G_OBJECT() casts accept NULL safely.
|
|
The MMManager object keeps an internal proxy object for the Manager
interface, and we must make sure we cleanup this object any time the MM
daemon is restarted. Otherwise, the MMManager may end up trying to use
a stale proxy associated to a previous run of the daemon, and e.g. not
showing properly the runtime version info.
E.g., in this sequence with the example python tester, the runtime
version of the daemon was valid only for the first time the daemon
runs, and if the daemon is restarted, mm_manager_get_version()
would keep returning NULL.
$ ./modem-watcher-python
[ModemWatcher] ModemManager service not available in bus
[ModemWatcher] ModemManager 1.9.990 service is available in bus
[ModemWatcher] Dell Inc. (DW5821e Snapdragon X20 LTE) modem managed by ModemManager [None]: /org/freedesktop/ModemManager1/Modem/0
[ModemWatcher] ModemManager service not available in bus
[ModemWatcher] ModemManager None service is available in bus
[ModemWatcher] Dell Inc. (DW5821e Snapdragon X20 LTE) modem managed by ModemManager [None]: /org/freedesktop/ModemManager1/Modem/0
[ModemWatcher] ModemManager service not available in bus
[ModemWatcher] ModemManager None service is available in bus
[ModemWatcher] Dell Inc. (DW5821e Snapdragon X20 LTE) modem managed by ModemManager [None]: /org/freedesktop/ModemManager1/Modem/0
|
|
|
|
When the MBIM port open involved transparently trying to open a QMI
device as well, we were clearing the progress flag before the full
operation had finished, and so the port could have been closed by
the time we really finish the open operation, leading to a crash:
ModemManager[28824]: <info> [1547386038.726136] (usbmisc/cdc-wdm3): released by device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <info> [1547386038.728084] (tty/ttyUSB0): released by device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <info> [1547386038.728738] (tty/ttyUSB1): released by device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <info> [1547386038.730769] (tty/ttyUSB2): released by device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <info> [1547386038.731256] (tty/ttyUSB3): released by device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <debug> [1547386038.731301] Removing empty device '/sys/devices/pci0000:00/0000:00:1c.4/0000:02:00.0/usb3/3-2/3-2.3'
ModemManager[28824]: <debug> [1547386038.731445] (ttyUSB0) forced to close port
ModemManager[28824]: <debug> [1547386038.731547] (ttyUSB1) forced to close port
ModemManager[28824]: <debug> [1547386038.731638] (ttyUSB2) forced to close port
ModemManager[28824]: <debug> [1547386038.731715] (ttyUSB3) forced to close port
ModemManager[28824]: <debug> [1547386039.580136] [cdc-wdm3] error: couldn't open QmiDevice: MBIM error: Transaction timed out
ModemManager[28824]: <info> [1547386039.580190] [cdc-wdm3] MBIM device is not QMI capable
**
ERROR:mm-broadband-modem-mbim.c:2119:track_mbim_device_removed: assertion failed: (device)
Thread 1 "ModemManager" received signal SIGABRT, Aborted.
0x00007ffff7390d7f in raise () from /usr/lib/libc.so.6
(gdb) bt
#0 0x00007ffff7390d7f in raise () at /usr/lib/libc.so.6
#1 0x00007ffff737b672 in abort () at /usr/lib/libc.so.6
#2 0x00007ffff7559042 in () at /usr/lib/libglib-2.0.so.0
#3 0x00007ffff75865dc in g_assertion_message_expr () at /usr/lib/libglib-2.0.so.0
#4 0x00005555556407f9 in track_mbim_device_removed (self=0x5555557a2830, mbim=0x5555557ea190) at mm-broadband-modem-mbim.c:2119
#5 0x000055555564093e in mbim_port_open_ready (mbim=0x5555557ea190, res=0x55555573fcf0, task=0x5555557d29d0) at mm-broadband-modem-mbim.c:2161
#6 0x00007ffff77742f4 in () at /usr/lib/libgio-2.0.so.0
#7 0x00007ffff7776cd7 in () at /usr/lib/libgio-2.0.so.0
#8 0x000055555565fcd5 in qmi_device_open_ready (dev=0x55555578f250, res=0x55555573fb50, task=0x55555573fcf0) at mm-port-mbim.c:191
#9 0x00007ffff77742f4 in () at /usr/lib/libgio-2.0.so.0
#10 0x00007ffff7776cd7 in () at /usr/lib/libgio-2.0.so.0
#11 0x00007ffff7c03fe6 in open_version_info_ready (client_ctl=0x7fffe8010c20, res=0x555555739e80, task=0x55555573fb50) at qmi-device.c:2050
#12 0x00007ffff77742f4 in () at /usr/lib/libgio-2.0.so.0
#13 0x00007ffff7776cd7 in () at /usr/lib/libgio-2.0.so.0
#14 0x00007ffff7c2034f in get_version_info_ready (device=0x55555578f250, res=0x5555557ea2a0, task=0x555555739e80) at qmi-ctl.c:3746
#15 0x00007ffff778ebcf in g_simple_async_result_complete () at /usr/lib/libgio-2.0.so.0
#16 0x00007ffff778ec5a in () at /usr/lib/libgio-2.0.so.0
#17 0x00007ffff75a98d1 in g_main_context_dispatch () at /usr/lib/libglib-2.0.so.0
#18 0x00007ffff75ab5e9 in () at /usr/lib/libglib-2.0.so.0
#19 0x00007ffff75ac5c2 in g_main_loop_run () at /usr/lib/libglib-2.0.so.0
#20 0x0000555555599eb0 in main (argc=2, argv=0x7fffffffe4c8) at main.c:181
|
|
The update method is a bitmask, so check for the flag.
|
|
It's a bitmask, so we report a list of strings.
|
|
|
|
|
|
|
|
|
|
|
|
Modem device inhibition is really a manager action for which we
provide the full modem device 'uid'.
This new operation allows to perform device inhibition using the modem
object as reference, which is more handy than first looking at the
device 'uid' and then running the manager action.
$ sudo mmcli -m 0 --inhibit
successfully inhibited device with uid '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-12/1-12.2'
type Ctrl+C to abort this program and remove the inhibition
^C cancelling the operation...
successfully uninhibited device with uid '/sys/devices/pci0000:00/0000:00:14.0/usb1/1-12/1-12.2'
|
|
This new method allows users of the ModemManager API to take full
control of a given device.
Unlike other operations in the API, the inhibition is maintained as
long as the caller exists in the bus, or until the same caller
uninhibits the device.
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/98
|
|
|
|
Devices may require/support more than one update method, so instead of
reporting the method as a single enum value, use a set of flags
instead.
|
|
|
|
|
|
|
|
|
|
Since the Firmware interface now contains more actions and properties
apart from List() and Select(), these two actions are now optional.
Not all modems implementing the Firmware interface must implement
these two methods.
|
|
We'll check for AT+QFASTBOOT support during runtime.
|
|
The DW5821e uses the AT^FASTBOOT command to reset the module in
fastboot mode, ready to download new firmware.
Note: we cannot use AT^FASTBOOT=? to query for support, as that
command also triggers the reset :/
|
|
We no longer "check for support" of this interface, it will always be
available for all modem objects.
The only implementation that used this interface was the QMI one, and
only for a very small subset of devices (those supporting the "QMI DMS
List Stored Images" operation). The logic was changed so that the list
of stored images wasn't preloaded during the support check; it will
now instead be preloaded during the first call to List().
|
|
|
|
|
|
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/issues/99
|
