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
...
This patch adds another Infineon flashloader device 0x8087/0x0801
to the blacklist
Reference to the kernel commit:
github.com/torvalds/linux/commit/f190fd92458da3e869b4e2c6289e2c617490ae53
Commit a66871a287 introduced an additional
ATTRS{idVendor} match condition in the same rules matching by interface class,
subclass and protocol. We shouldn't be doing that because we cannot mix parent
attribute matchings from different parents.
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.
Implement the detailed signal info interface for some Huawei 3GPP modems
including those based on HiSilicon chipsets like the E3276. Known not to
work on many Qualcomm-based Huawei modems like E392, E397, and E367 as
they don't support the ^HCSQ command, but they do support QMI and so
have access to the extended signal interface via QMI.
MMBroadbandModemTelit:
* added logic to set MMBroadbandModem's SIM_HOT_SWAP property to TRUE
* added function to enable QSS unsolicited
* added QSS unsolicited handler
BaseModem
added reprobe property.
MMDevice
added logic to recreate the modem if it is set invalid and "to reprobe"
MMBroadbandModem
* added initialization step for SIM hot swap:
1. keep dedicated ports open to listen to modem's unsolicited
2. dedicated error management in case of initialization failure due to SIM missing
* added function to be called in order to act upon SIM insertion/removal:
1. close dedicated ports
2. set the modem to be reprobed
3. disable modem
* added SIM HOT SWAP boolean property
MMIfaceModem
* added initialization step for SIM hot swap, if supported by the plugin
* dedicated error management in case of initialization failure due to SIM missing
We may want to use the mm_get_()_from_match_info() calls to read optional items,
so that the method returns FALSE if the item index doesn't apply. So, avoid the
implicit warning issued by g_return_val_if_fail().
The rules were matched only against devices with an exact 'tty' subsystem, and
that means that we were not properly adding additional tags on e.g. wwan or
cdc-wdm devices.
When a CDMA-only modem is registered with the EVDO network, its not possible to
read signal strength in the following cases:
1) while a data connection is active on single-AT-port modems, because the AT
port is used for PPP and not available for AT+CSQ, AT+CIND or vendor-specific
signal strength commands
2) when the modem reports only CDMA 1x signal strength with AT+CSQ
Now that we have a reasonable interpretation of RSSI from the QCDM
EVDO Pilot Sets V2 log messgae, use that when other means of getting
signal strength aren't available.
Inverted steps UPDATE_LOCK_INFO_CONTEXT_STEP_RETRIES and
UPDATE_LOCK_INFO_CONTEXT_STEP_AFTER_UNLOCK.
Soon after the unlock, the SIM can be busy and
loading unlock retries might fail.
When implemented, let run "after unlock" logic before any other step in
update lock info, when SIM is not locked this change does not have any
effect since "after unlock" is not executed.
PyGIWarning: ModemManager was imported without specifying a version first. Use gi.require_version('ModemManager', '1.0') before import to ensure that the right version gets loaded.
We now don't break the strict aliasing rules.
Also, having a compiler flag that disables a warning among the flags that are
meant to add extra sanity checking is not correct either:
--enable-extra-warnings=no would generate a bad aliasin warning while
the --enable-extra-warnings=yes would not.
We shouldn't be accessiing u_int8_t * as u_int16_t *. Let's construct
the 16-bit value by or-ing the 8-bit halves directly; avoiding the
endianness conversion too.
The mm_iface_modem_is_*_only() checks were validating that all the other
capabilities except for the ones being queried were unset, but the check wasn't
explicitly checking that the actual capabilities being queried were set.
This was making the check fail when capabilities == MM_MODEM_CAPABILITY_NONE.
Reported-by: Matthew Stanger <stangerm2@gmail.com>
Deciding the IP method to use based on the underlying QMI port LLP should not be
done when the bearer object is created, because the QMI port in use may not
actually be open or have been opened at that time. During the connection attempt
we do make sure the QMI port is open, so we should check the LLP to use just
after that step.
