| Age | Commit message (Collapse) | Author |
|---|
|
|
|
When comparing bearer properties provided by the user versus loaded
from the modem, we shouldn't be very strict, e.g.:
* Password or other fields may not be readable from the device.
* Some fields may not apply at all (e.g. RM protocol for EPS bearers)
* NULL strings could be assumed equal to empty strings.
* If no explicit IP type specified, an IPv4 default may be assumed.
* If no explicit allowed auth specified, 'none' default may be
assumed.
These loose comparisons are applied when managing the initial EPS
bearer settings and status, and we keep the strict comparison only
during the connection attempt lookup of a bearer with certain
settings, as those bearer objects are all created in the same place
with the same rules.
|
|
|
|
|
|
|
|
For generic WDS operations not tied to any connection attempt.
|
|
|
|
|
|
The parse_vendor_pco_info() method was returning NULL without error if
the pco info string was empty.
Under this situation, the code would have tried to add a NULL MMPco
into the pco_list list, which is not desired.
Avoid this, by making sure a NULL return always sets an error.
|
|
|
|
|
|
|
|
SAR service will be introduced in the stable libmbim 1.26.0, but it's
been flagged in the dev 1.25.1 version already.
|
|
This property (initially set to FALSE) controls whether QMI over MBIM
should never be considered. This property is set to TRUE for XMM-based
MBIM devices as they don't support QMI.
This fixes a probing delay of 15s on a Fibocom L850-GL device
(2cb7:0007) found in the Lenovo T14 Gen 1.
The establishing of a QMI connection was refused multiple time with
MBIM error OperationNotAllowed. Only the timeout of 15s for this
connection resumed the probing.
The properties in the MMBroadbandModemMbim are only installed when
WITH_QMI and QMI_MBIM_QMUX_SUPPORTED are set. Actually, this should only
disable the PROP_QMI_UNSUPPORTED but as this is the only property this
avoids the "unused variable 'self'" warnings/errors when trying to
compile set_property and get_property without QMI support. This can be
changed once other properties are needed.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/284
|
|
We had all the logic in place... but we were never actually enabling
the signal strength indications because the `enable` flag in the
context was never set.
The bug was introduced back in May 2018, and released with 1.10.0.
Fixes baefe53ab9c0ea0612d2bf7da64b6f6cf9753bcd
|
|
|
|
Do not fail to detect an error response with a call or text incoming. This happens during port probing when there's no URC parsers installed in the serial port. This probably will not happen when the serial port was managed by the modem object.w
|
|
|
|
Do not fail to detect a valid response with a call or text incoming.
This happens also during port probing when there's no URC parsers
installed in the serial port. This probably will not happen when the
serial port was managed by the modem object.
|
|
If e.g. a bearer with IPv6 configuration has DNS servers but exports
its link-local address, MM will avoid giving it the "static" method
type, and instead fall back to the "dhcp" type. However, it may
still have DNS information. Therefore, the comment that "method" is
the only property on configuration with type DHCP is misleading.
|
|
|
|
Enabling/Disabling/Changing/Sending the PIN1 lock is usually limited to
3 retries. If these attempts are exhausted, the modem is puk_locked.
We reprobe the modem to get rid of any unwanted interfaces and move
to a locked state.
|
|
If the lock status cannot be read during a puk unblock attempt, reprobe
the modem. It is likely that the SIM was permanently blocked if the lock
status cannot be read.
|
|
|
|
We need to quote arguments with [] so that lists are not expanded as
different arguments.
Fixes 65560dd8854f01eec1b28587c37d544bfff360d3
|
|
When there are multiple ports with the same purpose (e.g. multiple net
data ports, or multiple QMI control ports), sort them by name by
default.
The port order does not make any difference for ports that have
flagged with a specific purpose (e.g. AT primary).
The sorting is done both in the internal lists and when looking up
ports with find_ports().
|
|
It will not be automatically enabled by the implicit
--enable-all-plugins; instead, it must be explicitly enabled with
--enable-plugin-qcom-soc.
This plugin only makes sense under very specific SoC builds, so there
is no point in always building it by default. It should be explicitly
requested only in those SoC builds that are really going to make use
of it (e.g. postmarketOS).
|
|
|
|
This plugin implements support for old Qualcomm SoCs like the MSM8916
or the MSM8974, where:
* control ports are available via RPMSG channels exported as devices
e.g. with rpmsgexport:
https://github.com/andersson/rpmsgexport
* network ports are exposed by the bam-dmux kernel driver:
https://github.com/msm8916-mainline/linux/commits/bam-dmux
Adding support for newer Qualcomm SoCs (e.g. QRTR+IPA) could be done
in a similar way on this very same plugin.
This plugin is the first and only one that implements support for a
modem device that is "built in" the system, as opposed to external
modems that may be available via USB or PCI.
The ID_MM_PHYSDEV_UID based udev tags provided by the plugin provide
the logic to bind all the SoC ports together in the same modem object,
and therefore ID_MM_PHYSDEV_UID should not be used by users to
override the ones set by the plugin.
All "rpmsg[0-9]*" ports that are considered part of the modem are
flagged as candidate, ignoring the parent "rpmsg_ctrl[0-9]*" ports on
purpose. This setup therefore assumes that the channels have been
exported already as devices (e.g. using rpmsgexport).
libqmi 1.27.2 is required to support the "WDS Bind Data Port" message.
|
|
Most older Qualcomm SoCs (e.g. MSM8916, MSM8974, ...) communicate with
the integrated modem via shared memory (SMD channels). This is similar
to QRTR on newer SoCs, but without the "network" layer. In fact, the
older SoCs also have QRTR, but the modem QMI services are not exposed
there.
The mainline Linux kernel exposes SMD channels via the "remote processor
messaging bus" (rpmsg). Through special IOCTL calls it is possible to
create a char device for a rpmsg/SMD channel. We can then use these to
send QMI/AT messages to the modem, much like the ordinary serial char
devices when using a Qualcomm modem through USB.
This commit introduces support for the new 'rpmsg' subsystem, which
allows exporting QMI-capable and AT-capable ports.
By default NO rpmsg port is flagged as candidate, it is assumed that
the plugin adding support for the rpmsg subsystem will add specific
rules to do so (e.g. so that non-modem ports are explicitly not
flagged as candidate).
All rpmsg ports will be probed for AT or QMI capabilities, unless
explicit port type hints (e.g. ID_MM_PORT_TYPE_QMI or
ID_MM_PORT_TYPE_AT_PRIMARY) are set.
These changes are highly based on the initial integration work done by
Stephan Gerhold <stephan@gerhold.net> in postmarketOS, see:
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/363
|
|
In addition to loading port and device properties, we now also allow
loading sysfs properties that are assumed to be static (i.e. their
values won't change since loaded the first time).
|
|
Allow plugins to specify a QmiSioPort value to bind to. This is used
e.g. in the RPMSG+BAM-DMUX setup in order to allow any RPMSG port to
control all the available net ports.
|
|
|
|
Fixes an issue where (5+8n)-character long SMS messages received on a
CDMA network would be dropped with a "cannot read user data" error,
while other length SMS messages would be delivered fine.
Fix thanks to Peter Hunt
|
|
There is no point in creating a new kernel device object just to
process a remove event; instead, do any matching with existing
kernel device objects by subsystem and name, which is what the generic
backend already did anyway.
This avoids unnecessary lookup of information in sysfs during removal
events, because the port is anyway already gone when we try to look
those up.
|
|
Skip building the firmware version information with carrier config
information if the plugin already knows that the firmware upgrade
method doesn't implement carrier-specific upgrade paths.
|
|
Instead of assuming that all modules supporting firmware upgrade are
USB based.
|
|
Change-Id: I662061384cf48abd0975e15a91b090aa6b33ac34
|
|
Even if udev support is really built and available.
This is extremely useful to test the udev-less setup without fully
recompiling the whole daemon.
E.g.: the daemon can be run like this:
$ sudo /usr/sbin/ModemManager --debug --test-no-udev
And then, the kernel events may be reported using mmcli like this:
$ sudo mmcli --report-kernel-event-auto-scan
|
|
Instead of the custom simple implementation which only supported the
'*' modifier in the pattern. This allows us to support e.g. attribute
value matches like e.g. 'DATA[0-9]*_CNTL'.
|
|
Until now we did not support ATTRS{} matches against attributes we
don't support in the core codebase. Implement now a simple lookup
mechanism which traverses the tree of sysfs path from the port sysfs
path to the physical device sysfs path, looking up the attribute
requested.
This is not completely equivalent to what udev does, because the udev
rules matching ATTRS would usually also include an additional previous
matching e.g. SUBSYSTEMS and such, so that the ATTRS is looked up
exactly in the device that also matches the additional previous
rules. In our case, we just simplify the logic and return the first
one found.
|
|
We were applying the DRIVERS check looking only at the single port
driver. Instead, we now lookup and cache all drivers found in the
device tree, and apply the loose DRIVERS check properly looking at all
of them.
We were applying the SUBSYSTEMS and SUBSYSTEM check looking at the
sysfs path and just hoping the subsystem we're looking for is included
in the path itself. Instead, we now lookup and cache all susystems
found in the device tree, and apply the loose SUBSYSTEMS check
properly looking at all of them.
E.g. we can now match SUBSYSTEMS="mhi_q" in the following device tree,
without needing it to be found in the sysfs path:
looking at device '/devices/pci0000:00/0000:00:1b.0/0000:01:00.0/1001_00.01.00_MBIM/mhi_uci_q/mhi_MBIM':
SUBSYSTEM=="mhi_uci_q"
looking at parent device '/devices/pci0000:00/0000:00:1b.0/0000:01:00.0/1001_00.01.00_MBIM':
SUBSYSTEMS=="mhi_q"
looking at parent device '/devices/pci0000:00/0000:00:1b.0/0000:01:00.0':
SUBSYSTEMS=="pci"
|
|
The vendor and product IDs stored for the MMKernelDevice object in the
PCI subsystem are mapped to the "vendor" and "device" attributes.
|
|
The generic backend implementation was really based on detecting USB
devices, not so much devices in other subsystems. This patch puts the
generic backend at the same level as the udev backend to support
non-USB modems.
|
|
USB, PCI, PCMCIA... all these different system buses expose modems in
different ways. Instead of having single methods to attempt to load
different things for all these device types, detect first which is the
system bus in use, and then perform a bus-specific operation to
preload the different things.
|
|
We can just subclass the methods to check whether a given property
exists and to get it as a string, and then implement in the generic
class the actual boolean/int/hex type getters common for all.
|
|
These kind of checks are only useful on public APIs really, there
should be no need to have them in internal code.
|
|
Each different plugin or protocol had a different connection attempt
value. E.g. QMI and MBIM both used 60s max for the connection attempt,
while the u-blox plugin had up to 180s for ECM based connection
setups.
This commit consolidates all plugins and protocols to use the same
timeout values for commands that may take long to respond, e.g. a
connection atempt under low signal quality conditions.
A value of 180s for the connection attempt steps and 120s for a
disconnection attempt step is considered. Note, though, that in some
cases (like a IPv4v6 setup attempt using QMI) we may have more than
one such long step, so this doesn't mean that a connection attempt
will always take less than 180s.
Users of the connection/disconnection APIs should be able to handle
the case where the attempt times out in their side (e.g. with a lower
DBus request timeout), and which would not mean the actual request
they did really failed. E.g. a connection attempt with a DBus timeout
of 30s may fail in the user with a timeout error, but the attempt
would still go on for as much as the plugin/protocol needs.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/270
|
|
Don't rely on the QMI or MBIM ports named cdc-wdm, use the device
subsystem instead.
|
|
Instead of assuming we require a fixed set of subsystems to monitor,
compile the full list based on what the plugins have requested
themselves.
|
