Age | Commit message (Collapse) | Author |
|
Expose a new list of 'IgnoredPorts' via D-Bus and therefore remove the use of `MM_MODEM_PORT_TYPE_IGNORED`
Signed-off-by: Lukas Voegl <lvoegl@tdt.de>
|
|
|
|
|
|
Instead of having the modem object listen notifications in the
MbimDevice, the MMPortMbim will act as an intermediate emitter for the
same.
The primary benefit is that the lifecycle of the port object is
tightly coupled to the life of the modem object, so there is no chance
that the port object outlives the modem object.
And the port object will ensure its own device notification handler is
correctly cleared up on its dispose, so there should be no chance of
firing up a signal in the device for a listener that is already
freed.
|
|
Letting the MMBroadbandModemMbim listen for the notifications of the
MbimDevice 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 MbimDevice outlives the MMBroadbandModemMbim and
the MMPortMbim, and when the "device-removed" signal is triggered, the
program crashes.
The MMPortMbim will now emit its own 'removed' signals when the
underlying MbimDevice emits "device-removed', ensuring that the signal
handler is properly cleared up during the MMPortMbim disposal.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/518
|
|
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.
|
|
|
|
The ModemManager codebase has been ported to support Basic Connect v3
messages as defined in MBIMEx v3.0, so at this point we can now switch
to use it by default whenever possible.
|
|
The ModemManager codebase has been ported to support Basic Connect v2
messages as defined in MBIMEx v2.0, so at this point we can now switch
to use it by default whenever possible.
|
|
The port open operation may be happening very early after the device
has booted, so let's give the module some more time to reply the very
first MBIM query we do. The original 10s seems to be a bit tight in
some cases.
See https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/405#note_1006746
|
|
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>
|
|
These are really wrappers around the MbimDevice methods, only making
sure the MMPortMbim is open before they're used.
|
|
|
|
We have assumed until now that all MBIM ports are based on the
cdc_mbim driver, exposed in the 'usbmisc' subsystem by the cdc-wdm
driver.
This may no longer be true, so allow creating MBIM ports with
an explicit subsystem instead of defaulting always to USBMISC.
|
|
Back in Linux < 3.6 days, the cdc-wdm ports exposed by the QMI driver
were flagged as owned by the 'usb' subsystem. That changed in 3.6 when
the subsystem was renamed to 'usbmisc':
https://mail.gnome.org/archives/networkmanager-list/2012-June/msg00125.html
So, rename the port subsystem type enumn to 'usbmisc'.
|
|
|
|
The qmi_device_close() synchronous operation is deprecated.
|
|
If we blindly try to use QMI over MBIM on devices that don't support
it, the logic works ok but it's very slow, given that the QMI device
open operation has several internal retries, and all those end up
timing out.
Avoid that lost time by checking the list of services supported by the
MBIM modem, and if the QMI over MBIM service is not listed, we'll
avoid trying to open the QMI device right away.
|
|
|
|
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
|
|
|
|
Fixes: c0cc694c67d9e71f200fb23e20473cc9b31d9ec0
|
|
We do want to receive QMI indications, as they will be needed for
different features (e.g. LOC based GNSS support).
|
|
|
|
Most Qualcomm-based MBIM devices also support QMI over MBIM. We will
try to check in runtime whether the MBIM device supports QMI over
MBIM, and if so, setup a QmiDevice within the MMPortMbim.
|
|
|
|
|
|
A MBIM device typically delays its response to an 'Open' command when it
has not completed the initialization process. This patch increases the
timeout of the MBIM device open operation from 10s to 30s to handle
situations where the device takes much longer to initialize.
|
|
|