Certain QMI or MBIM devices may not be able to support multiplexing at
all, or they may support a limited amount of links.
The new ID_MM_MAX_MULTIPLEXED_LINKS udev tag allows specifying the
maximum number of supported multiplexed links; e.g. 0 to report none
supported or 1 to report that one single multiplexed link is
supported.
adding bandwidth information in mm-dbus interface
for the serving cell. In serving cell, the details
on whether the pcell/scell are from MCS or SCG is
also updated.
Co-author: Shilpa Shivakumar
This new method allows querying the modem for information about the
current serving cell(s) as well as any other neighboring cell that may
be found.
The information for the cells is given in an array of dictionaries,
where each element of the dictionary is a new dictionary itself.
Each cell type has a different set of properties that may be given in
the dictionary, and some of those properties in each type are also
applicable under certain conditions (e.g. only applicable to the cell
if it's a 'serving' cell instead of 'neighboring').
The API documentation explains in detail what is expected in each
case.
The 'allow-roaming' setting should be considered deprecated for 3GPP
devices that support the new 'roaming-allowance' setting, which is
much more detailed (as it allows to differentiate between partner and
non-partner networks) and may also be stored as part of a profile.
In 5G capable devices, which can support multiple types of access
types (either 3GPP or non-3GPP), the UE may request to use a 3GPP
access type exclusively, prefer a 3GPP access type, or just report no
preference.
When supported, this field may also be part of the settings that can
be stored as part of a profile.
A new set of property+method is added to be able to configure the 5G
specific registration settings, initially defining the support for the
MICO mode.
The property name starts with "Nr5g" instead of "5gNr" because of the
limitations imposed by the GObject type system on how properties with
numbers can be named.
We keep the 'WHITELIST-ONLY' filter type name still as an option in
--filter-policy=[POLICY], but deprecated and with the better
'ALLOWLIST-ONLY' replacement suggested from now on.
meson is a build system focused on speed an ease of use, which
helps speeding up the software development. This patch adds meson
support along autotools.
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.
Since ModemManager 1.0 we were publishing symbols to identify all the
possible DBus error name prefixes, but these were never documented,
they were explicitly ignored in gtk-doc.
Let's provide proper documentation for them and make them first-class
API symbols.
Update the list of mobile equipment error codes according to v17.1.0
of 3GPP TS 27.007 (March 2021).
A lot of the enum values that were prefixed with the 'GPRS_' keyword
have now been flagged as deprecated, and a new enum name given to the
corresponding value.
The deprecated symbol names are kept in the compat support to avoid
breaking API/ABI.
This new interface allows modems to expose the list of available
connection profiles stored in the device and edit or delete them; as
long as the underlying device/protocol allows it.
This new setting allows the user setting up the connection to specify
the purpose of the connection being brought up.
Until now, we would always assume that connections are exclusively
brought up for connecting to the Internet, also limited by the
inability to connect to multiple different APNs at the same time.
But that may really not be true as there may be additional services
that may be accessed through other APNs, like MMS services or even
private networks for companies that have their own APNs on a given
operator (e.g. not that uncommon with banks and connected cars).
The new APN type setting will not change the way the bearer is
connected, but will allow the connection manager to decide what kind
of networking setup the specific connection needs.
This new setting can be provided by the user itself, or implicitly
read from the device if the device stores this information.
Include the new SAR interface in the build so that gdbus-codegen
generates support for it in libmm-glib as well as proper documentation
in the API reference.
Both the Simple.Connect() and Modem.CreateBearer() are updated to
allow a new 'multiplex' setting in the properties provided by the user
in both of these methods.
The new setting expects a MMBearerMultiplexSupport enum indicating
what kind of multiplex needs the user has:
* none: if multiplex must not be used.
* requested: if multiplex should be used if available.
* required: if multiplex must be used.
The underlying implementations will take care of accepting or
rejecting the setting depending on the system and modem capabilities.
It is no longer true that all QMI ports are exposed by the qmi_wwan
driver and that all MBIM ports are exposed by the cdc_mbim driver.
There are other generic setups that allow exposing these types of
ports using different drivers, and usually we can also know the type
of port in advance via other means. Therefore, allow adding udev port
type hints for QMI and MBIM ports as well.
This is not just a rename of the rule, we also now avoid doing an
explicit check on the port name as well, and we rely on subsystem
checks only; i.e. the same logic applied for net ports.
The port candidate rules already do a 'cdc-wdm*' device name check
so it shouldn't be a big deal.
This tag is completely redundant because users can whitelist the
platform TTY ports to use with the more generic ID_MM_DEVICE_PROCESS
tag, which is part of the explicit whitelist filter rule.
The udev tag that allows flagging devices that MAY be modems
(e.g. USB<->RS232 adapters) is only applicable to TTY devices, so
explicitly specify that in the tag name as well.
Until now the ID_MM_DEVICE_IGNORE udev tag was being used in the
internal blacklist of devices shipped by ModemManager when running in
either DEFAULT or PARANOID filter modes. The name of the tag is
extremely misleading because it doesn't really make the full device be
ignored, the tag only applied to TTY ports.
This commit repurposes the tag so that it applies to ANY kind of
port (e.g. TTY, NET, cdc-wdm...) and also to any kind of filter type
(i.e. also applicable in STRICT mode).
The internal blacklist shipped by ModemManager, which should NOT be
used in STRICT mode, uses a new tag name, ID_MM_TTY_BLACKLIST.
The new ID_MM_DEVICE_IGNORE tag is therefore much more usable and its
name is really meaningful. If there are users or third-party projects
adding their own udev rules with the ID_MM_DEVICE_IGNORE tag name,
they should have no problem as the new rule is more restrictive than
the old one.
Until now we have only allowed to use and setup 'default bearers' (in
4G) or 'primary contexts' (in 2G/3G).
We can define a couple of additional bearer types, though:
* The 'dedicated bearers' (in 4G) or 'secondary contexts' (in 2G/3G),
which are associated to a specific default/primary one, but which
provide specific QoS settings configured via traffic flow templates.
* The 'initial default EPS bearer', which is a special case of default
bearer in LTE, which is automatically created and connected when the
modem is registered in the LTE network.
This commit introduces a new 'MMBearerType' enumeration that will be
associated to each bearer through a 'BearerType' property in the
org.freedesktop.ModemManager1.Bearer interface, showing what kind of
bearer/context this is.
By default, right now, all bearer objects created are 'default'
bearers.
