When new link ports are created, the QmiDevice link management methods
try to make sure that the port exists in the system by the time the
link addition method returns, but that doesn't guarantee that the port
has also been notified by the kernel to ModemManager (e.g. via udev or
via kernel events).
This new method allows to do a explicit wait for a given port link; if
we already have it it will return right away, and otherwise we'll wait
for it to be notified via the "link port grabbed" signal.
We will grab the ports and make them available through find_ports() or
peek_port() or get_port().
The link ports are not 'organized' so they won't be available in
e.g. get_data_ports(), which is fine, because we don't want to mix
them with the real data ports exposed by the device.
Link port additions and removals are also notified via signals in the
modem object, so that explicit wait for specific ports can be done.
Right now just with the support to setup link properties like up/down
state or the link mtu.
This features are required when using QMAP based multiplexing with the
qmi_wwan kernel driver.
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.
When the SIM switch doesn't happen as part of an async hot swap
detection, we should trigger the switch handling at base modem level,
which e.g. doesn't require explicit cleanup of the SIM hot swap
detection port context.
The auth provider setup is a bit over-engineered. Simplify it by
making a single MMAuthProvider object that may or may not use polkit,
depending on configure options. This object is also setup as a
singleton object using the helper MM_DEFINE_SINGLETON_GETTER().
Instead of flagging them as 'ignored' so that they aren't probed, we
can also flag them as 'audio' now, so that the logic knows which port
to report as used for audio in the Call object.
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.
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 will expose a new 'Ports' property listing all ports currently known by a
given modem. Ports which are not used but are detected as being part of the
modem will be listed with an 'unknown' port type.
This change uses the new 'MMModemPortType' enum and the new 'MMModemPortInfo'
helper struct to handle these values in libmm-glib. The already available
'MMPortType' enum hasn't been re-used for the interface because it contains
values that we don't need (e.g. IGNORED).
The port list is now also included in the modem information command of mmcli:
$ sudo mmcli -m 0
/org/freedesktop/ModemManager1/Modem/0 (device id '97b7b99e3e2bea103880545b619fb05a3cc81b26')
-------------------------
System | device: '/sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4'
| drivers: 'qcserial, qmi_wwan'
| plugin: 'Gobi'
| primary port: 'cdc-wdm0'
| ports: 'ttyUSB0 (qcdm), ttyUSB1 (at), cdc-wdm0 (qmi), wwp0s29u1u4 (net)'
https://bugzilla.gnome.org/show_bug.cgi?id=702678
Instead of deciding in advance which data port to use, we let the dialling
operation gather it. For the generic dialling logic, ATD-based, always an
'AT' port will be used as data port, even if we grabbed a 'net' port. Those
plugins that can work with 'net' ports will grab the specific 'net' port
themselves.
This patch adds a 'hotplugged' flag to MMBaseModem to indicate if a
modem is newly plugged in. A plugin can use this information to
determine if, for example, the modem needs to be soft reset using the
ATZ command.
Dan Williams <dcbw@redhat.com> contributed the idea of implementation.
For those who don't care about the QMI support through libqmi-glib, or if you're
stuck with glib 2.30 (libqmi-glib requires 2.32), this configure switch allows
disabling the QMI support completely.
The logic to detect cdc-wdm ports is still in place, but the QMI probing is
never launched at them. Also, all QMI-related objects won't be compiled.
QMI and wwan ports come in pairs. Each wwan port has an associated control QMI
port, which is the only port allowed to send the Start|Stop Network QMI requests
to start|stop the connection in the given wwan interface.
Paired QMI and wwan interfaces (should) share the same parent udev device,
quoting Bjørn:
"If we ignore the unfortunate 3.4 and 3.5 kernels, then a matching wwanX
and cdc-wdmY set will always share the same parent USB interface on QMI
devices.
Having the same parent USB device is *not* sufficient. You cannot control
wwan0 using cdc-wdm1 in the above example."
Different ports of the same modem may get handled by different drivers. We
therefore need to provide a list of drivers (new `Modem.Drivers' property with
signature 'as') instead of just one (removed `Modem.Driver' property with
signature 's').
$ sudo mmcli -m 0 | grep drivers
| drivers: 'qcserial, qmi_wwan'
Plugin may specify GPS-specific port tyeps when requesting to grab the port.
These could either be an AT-based GPS control port, or the raw GPS serial port
which emits the NMEA traces.
Instead of the `_in_port()' variants, we'll provide more generic
`_full()' methods. These should be used either if we want to send commands
to a specific port, or if we want to use a specific user-provided GCancellable.
In addition to this user-provided GCancellable, we keep the internal modem-wide
one.
* mm_base_modem_peek_port_* () will return either a port object (no new
reference), or NULL if none available.
You would usually peek() a port if you're going to use it just in the current
method, as there is no way to that reference to get invalid (we're single
threaded).
* mm_base_modem_get_port_* () will return either NEW references to valid
port objects, or NULL if none available.
And, you would usually get() a port, whenever you want the port object to be
valid even out of the current method, for example when keeping it in the
context of an async operation.
Also, we need to consider that the primary AT port MAY BE NULL when you
peek() or get() it. This is due to the fact that we may be releasing ports
(due to device disconnection) in the middle of async operations.
Aleksander Morgado
Dylan Van Assche
Pavan Holla
Matthew Stanger
Carlo Lobrano
Aleksander Morgado
Ben Chan