g_free and g_object_unref are in form of `void (*)(gpointer)`, which
matches the GDestroyNotify signature. An explicit GDestroyNotify cast on
g_free and g_object_unref is thus not needed.
Vendor specific plugins that support QMI or MBIM based devices need to
handle the creation of these modems themselves.
https://bugs.freedesktop.org/show_bug.cgi?id=100372
Original patch by Aleksander Morgado.
The vendor id/string based rules should already be enough to get the
telit plugin bind telit devices.
This simplifies support for future Telit devices, as we wouldn't need
any additional change in the plugin. It also helps when working with
RS232 devices as the user wouldn't need to add the explicit tag to get
the devices bound to this plugin.
https://bugs.freedesktop.org/show_bug.cgi?id=100373
There are 2 main types of udev properties: device-specific and
port-specific.
The port-specific properties are set independently per port (e.g. port
type hints set per interface number for a given vid:pid).
The device-specific properties apply to all ports in the device. Some
of these properties are currently expected in the physical device
(e.g. ID_MM_PLATFORM_DRIVER_PROBE) while some others are expected in
each port (e.g. the plugin udev tag filters).
This patch tries to simplify the logic and just assume that the device
specific tags may be given in either the physical device or the port
device, by providing separate APIs to retrieve port-specific or
device-specific (global) properties. If the same tag is given in both
the device and the port, the one in the device takes preference.
For the generic backend, these new APIs are really useless, as all
device-specific and port-specific properties are always stored in the
port object themselves (there is no 'tree' of devices in the generic
backend, no 'physdev' device).
For the udev backend, though, there really is a difference, as the
tags may be set in port or device.
https://bugs.freedesktop.org/show_bug.cgi?id=100156
Adding the vendor string match allows us to support RS232 devices in
the Telit plugin: the USB vendor id check may now be ignored and
instead we probe for the vendor string via AT commands, which works
even if the device is behind a USB<->RS232 adapter.
https://bugs.freedesktop.org/show_bug.cgi?id=100171
The telit plugin is based on two main ways of checking the purpose of
each port: udev tags flagging specific interfaces (with info taken
from Windows .inf drivers), or otherwise using AT#PORTCFG? to query
the modem about that information. If none of those applies, the port
is ignored by default.
In order to support devices that are not explicitly tagged, the plugin
shouldn't flag as ignored the AT-capable TTYs, instead they are now
grabbed as 'secondary': ports grabbed as secondary will never be used
for either primary/data IF there is another port flagged explicitly
for primary/data.
This fixes the support for modems with a single TTY and no explicit
port type hint tag, e.g. RS232 modems with just one single TTY where
there's no point in specifying port type hints: the port will be
grabbed as secondary, and then automatically promoted to primary/data
as there is no other port grabbed.
https://bugs.freedesktop.org/show_bug.cgi?id=100159
g_type_init() has been deprecated (and also marked with the attribute
'deprecated') since glib 2.36 as the type system is automatically
initialized. Since the minimum version of glib required by ModemManager
is 2.36, calling g_type_init() isn't necessarily in the ModemManager
code.
`g_assert_true' and `g_assert_false' are defined in glib 2.38 or later.
The minimum glib version currently required by ModemMamanger is 2.36.
While `g_assert_true' and `g_assert_false' may be preferred over the
more generic `g_assert', it seems like overkill to bump the minimum glib
version requirement just for that. When more code in ModemManager later
requires newer versions of glib, we can migrate all existing code to use
`g_assert_true' and `g_assert_false' when appropriate.
In place of two slightly different regexes for 2g/3g and 2g/3g/4g modems
we now use only one regex with conditional patterns for both supported
and current Bands detection.
Adding also minor fix in test code
GE910 is a 2g only modem and when queried for bands it returns
only a 2g set of bands:
--> 'AT#BND=?<CR>'
<-- '<CR><LF>#BND: (0-3)<CR><LF><CR><LF>OK<CR><LF>'
Current regex fails, since it considers the 3g bands block mandatory.
A similar problem happens for current bands.
This patch modifies the regular expressions for properly
supporting GE910 and updates tests.
GE910 family supports #PORTCFG layouts different than HE910
family ones.
This patch properly tags GE910 ports according to Telit document
"GE910 Family Ports Arrangements, 1vv0301049"
The mm_base_modem_grab_port() now receives a MMKernelDevice directly from the
plugin, which is then stored in the MMPort corresponding to the port.
This means that we have direct access to e.g. all properties set by udev rules
everywhere, and we don't need additional GUdevClient objects (e.g. like the one
used in the Huawei plugin to detect NDISDUP support during runtime).
For virtual ports (e.g. generated during unit tests), we have a new 'generic'
kernel device object which just provides the values from the kernel device
properties given during its creation.
Instead of relying constantly on GUdevDevice objects reported by GUdev, we now
use a new generic object (MMKernelDevice) for which we provide an initial GUdev
based backend.
All ports of the same modem reported by the kernel will all be associated with
a common 'uid' (unique id), which uniquely identifies the physical device. This
logic was already in place, what we do now is avoid calling it the 'sysfs
path' of the physical device, because we may not want to use that to identify
a device.
This logic now also enables the possibility of "naming" the modems in a unique
way by setting the "ID_MM_PHYSDEV_UID" property in the "usb_device" that owns
all the ports.
E.g. a custom device has 4 modems in 4 different USB ports. The device path of
each USB device will always be the same, so the naming rules could go like this:
$ vim /usr/lib/udev/rules.d/78-mm-naming.rules
ACTION!="add|change|move", GOTO="mm_naming_rules_end"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.1", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-1"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.2", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-2"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.3", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-3"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.4", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-4"
LABEL="mm_naming_rules_end"
Each of the modems found will have a unique UID retrieved from the previous list
of rules. Then, "mmcli" has also been updated to allow using the UID instead of
the modem DBus path or index, e.g.:
$ sudo mmcli -m USB-MODEM-1
/org/freedesktop/ModemManager1/Modem/0 (device id '988d83252c0598f670c2d69d5f41e077204a92fd')
-------------------------
Hardware | manufacturer: 'ZTE CORPORATION'
| model: 'MF637'
| revision: 'BD_W7P673A3F3V1.0.0B04'
| supported: 'gsm-umts'
| current: 'gsm-umts'
| equipment id: '356516027657837'
-------------------------
System | device: 'USB-MODEM-1'
| drivers: 'option'
| plugin: 'ZTE'
| primary port: 'ttyUSB5'
| ports: 'ttyUSB5 (at)'
...
$ sudo mmcli -m USB-MODEM-1 --enable
...
Commit 7ff57f9808 introduced a change to try to
use ATTRS{bInterfaceNumber} as a common way to match by interface number, but
this logic is broken because all the rules that we use to match by interface
number (attribute in the interface device) also require matching by idVendor
and idProduct (attributes in the physdev device), and udev rules forbid matches
from more than one parent device at a time.
We could use ATTR{bInterfaceNumber} (instead of ATTRS) to tag the actual USB
interface device, but that would require a change in all the plugins to look for
the tag not in the TTY device, but in its parent.
So, recover the original behavior, where a hidden property is created containing
the first bInterfaceNumber found in the list of parent devices, and then run
the matches against idVendor and idProduct only if the hidden property is found
with the expected value.
Rules with a single condition where a parent property is checked with != don't
work properly. E.g.:
SUBSYSTEMS!="usb", GOTO="end"
or:
ATTRS{idVendor}!="abcd", GOTO="end"
Instead, we can mix both those previous parent rules and match them:
SUBSYSTEMS=="usb",ATTRS{idVendor}=="abcd", GOTO="next"
GOTO="end"
LABEL="next"
# Apply rules here
LABEL="end"
In this case both SUBSYSTEMS and ATTRS conditions apply to the parent usb_device
(idVendor attribute is only available in the usb_device), so they apply to all
ports of the same device.
MMBroadbandModemTelit:
* added logic to set MMBroadbandModem's SIM_HOT_SWAP property to TRUE
* added function to enable QSS unsolicited
* added QSS unsolicited handler
This patch makes declarations bind to definitions within the same module
to prevent the potential ambiguity if referenced directly.
AddressSanitizer think they violated one definition rule, although
those symbols are accessed by address through their modules and do
not depend on the order of the libararies loaded.
Adding dynamic port identification for Telit modems that support AT#PORTCFG
command. Port configurations for HE910/UE910/UL865 taken from document
"HE910/UE910/UL865 Families Ports Arrangements User Guide"
