| Age | Commit message (Collapse) | Author |
|---|
|
|
|
GCC 13 got unhappy about using an int in place of an enum:
../src/mm-port-qmi.c:241:1: warning: conflicting types for ‘mm_port_qmi_release_client’ due to enum/integer mismatch; have ‘void(MMPortQmi *, QmiService, MMPortQmiFlag)’ {aka ‘void(struct _MMPortQmi *, QmiService, MMPortQmiFlag)’} [-Wenum-int-mismatch]
241 | mm_port_qmi_release_client (MMPortQmi *self,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
In file included from ../src/mm-port-qmi.c:26:
../src/mm-port-qmi.h:113:10: note: previous declaration of ‘mm_port_qmi_release_client’ with type ‘void(MMPortQmi *, QmiService, guint)’ {aka ‘void(struct _MMPortQmi *, QmiService, unsigned int)’}
113 | void mm_port_qmi_release_client (MMPortQmi *self,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
|
|
Letting the MMBroadbandModemQmi listen for the notifications of the
QmiDevice 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 QmiDevice outlives the MMBroadbandModemQmi and
the MMPortQmi, and when the "device-removed" signal is triggered, the
program crashes.
The MMPortQmi will now emit its own 'removed' signals when the
underlying QmiDevice emits "device-removed', ensuring that the signal
handler is properly cleared up during the MMPortQmi disposal.
|
|
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.
|
|
|
|
The user may request to disable QRTR support using `--without-qrtr`
even if libqmi has QRTR support.
|
|
Will be set by base modem when organizing ports, similar to
net driver name. Required for fetching the TX and RX endpoint IDs
through sysfs from linux 5.14 onwards.
|
|
In addition to differentiating between IPv4 and IPv6 clients, we also
need to explicitly allocate different clients in different bearer
objects when in multiplexing.
|
|
|
|
|
|
Extend mm-port-qmi to accept a QRTR node to work with modems using the
QRTR protocol.
|
|
The QmiDeviceExpectedDataFormat is specific to modules exposed by the
qmi_wwan driver, it has nothing to do with other drivers we may find
in the system like bam-dmux or ipa, which don't allow changing the
expected data format.
The port setup logic is now updated to use a new flags bitmask that
specifies which kernel data modes are supported or currently
available.
|
|
The MMPortQmi may need to know very early what kind of net ports are
going to be used later on during connection, e.g. to decide what kind
of multiplexing capabilities are available and such.
So, once we have organized ports in the modem, we'll take the driver
of the first network port in the list of data ports, and pass it down
to all QMI ports setup in the modem object.
|
|
For the qmi_wwan driver, we have imposed a limitation of max 4 links
when using the add_mux/del_mux interface, because we're forced to
precreate links before multiplexing may be enabled.
When using rmnet over qmi_wwan, or rmnet over other drivers, we don't
have any limitation other than the one imposed by the WDA protocol
itself. The amount of links that may be created in this case is
1 + (QMI_DEVICE_MUX_ID_MAX - QMI_DEVICE_MUX_ID_MIN).
This information is loaded in the MMPortQmi, used to create the
MMBearerList in the QMI modem, and finally populated in the
'MaxActiveMultiplexedBearers' property of the modem interface.
|
|
The logic to setup/cleanup net links is based on the QmiDevice net
link addition/removal operations.
When the qmi_wwan add_mux/del_mux based logic is in use, we default to
precreate 4 net links and we limit the amount of bearers that may be
connected to that maximum, because it is not guaranteed that the
qmi_wwan driver is able to create new links once the master interface
is up; and the master interface needs to be up for a proper data
connection.
For all other drivers, or when qmi_wwan uses qmap-pass-through, we
allow adding/deleting new links at any moment, without needing to rely
on the precreated ones.
|
|
We now allow requesting for multiplex support in the set data format
operation of the MMPortQmi.
If multiplexing is supported, we'll configure both the modem (link
layer protocol and data aggregation protocol) and the kernel expected
data format (if qmi_wwan in use).
The logic adds additional preferences over the different choices we
may find in the logic:
* In newer modems, by default QMAPv5 is preferred over QMAP as data
aggregation protocol.
* If using qmi_wwan, by default rmnet (qmap-pass-through) is
preferred over add_mux/del_mux (raw-ip) kernel expected data
format.
These preferences are only considered if the specific support is found
in the setup.
Whenever we change the multiplexing support, an internal port reset
operation will be run, in order to bring the state of the setup to a
clean known one.
|
|
The port reset operation will attempt to setup the QMI and associated
NET ports to the same state as they has when the modem was originally
detected: no mux links, net interface down and (for the qmi_wwan based
devices) expected kernel data format set to 802.3.
By default, the external calls to the port reset logic will require
the port to be closed (i.e. no internal QmiDevice), so a new temporary
QmiDevice will be created just for this operation. The new QmiDevice
doesn't even need to be open, as the reset operations just uses the
device to attempt to remove net links.
The internal call to the port reset logic uses an input QmiDevice
which may be the newly allocated one in the external call, or the
internal QmiDevice, if there is one.
|
|
The new logic is implemented as a separate async method with its own
state machine, which allows selecting different data format setups
with an strict preference.
Until now, we would not attempt to re-configure the link layer
protocol in the modem interface if we could instead change the
expected data format in the kernel. E.g. a MC7304 exposing one
interface in 802.3 format and another one in raw-ip format would be
used in either 802.3 or raw-ip, depending on the network interface
being connected.
This logic changes now, and we now by default always prefer raw-ip
over 802.3. E.g. the same MC7304 would now always be used in raw-ip
mode, regardless of whether the interface was by default in raw-ip or
not. Obviously, raw-ip will only be used if the kernel data format can
be changed. If the qmi_wwan driver in use is older than 4.5, the
default link layer protocol attempted would be 802.3, if the modem
supports it.
In addition to this change in logic, we also now avoid setting up the
WDA data format as soon as the port is opened; instead we defer that
logic until a connection request arrives, because once QMAP support is
integrated, we'll need to know whether the user requested the
multiplexing support or not. Therefore, during port open we just
query current state and during the connection attempt we reconfigure
either modem or kernel or both.
If WDA is unsupported, the logic falls back to CTL-based link layer
protocol configuration, as it use to.
The logic now also supports WDA Set/Get Data Format operations with
the newest modems that require the explicit endpoint info TLV. As soon
as the first failure is reported asking for the endpoint TLV, we'll
flag the port as requiring the endpoint info always.
|
|
The endpoint info of a given MMPortQmi is immutable (it's associated
to the specific kernel driver in use and to the specific physical
interface number of the device).
We'll load it as soon as the kernel device object is set in the port,
and we'll keep it in the private struct so that it can be used at any
time, e.g. by the WDA Get/Set Data Format operations on newest
devices, where the endpoint info TLV is mandatory.
|
|
We have assumed until now that all QMI ports are based on the
qmi_wwan driver, exposed in the 'usbmisc' subsystem by the cdc-wdm
driver.
This may no longer be true, so allow creating QMI ports with
an explicit subsystem instead of defaulting always to USBMISC.
|
|
|
|
|
|
To be in sync with the qmi_device_close_async() underlying method,
given that the synchronous one is deprecated.
|
|
This allows us to reprobe the modem and respawn the
qmi-proxy in case it dies on us. This gets us access
to the modem and unsolicited notifications again. Do
this by connecting to the device-removed signal on
QmiDevice.
---
Rebased on top of git master by
Aleksander Morgado <aleksander@aleksander.es>
|
|
When using raw-ip we'll default to request static IP setup for now, so that we
don't rely on the DHCP client supporting raw-ip interfaces.
|
|
|
