If we end up allocating too many CIDs without releasing them new allocations
will fail with client-ids-exhausted errors. This usually happens specially
when debugging/developing as you're all the time Ctrl+C-ing the daemon without
rebooting the system.
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."
We'll try to cope with getting devices being reported in either 'usb' or
'usbmisc', trying to avoid the need of checking kernel version during runtime.
All grabbed 'net' ports are added to the new list of data ports. It is a task
for the specific plugin to decide how each of the data ports should be
connected. In the case of not having 'net' ports, the list of data ports will
only contain a single AT port.
All grabbed 'qmi' ports are added to the new list of QMI ports. The first port
in the list is to be considered the 'primary' one, and will be the one used
for all services. The remaining QMI ports, if any, will only be used to for WDS,
to manage the associated 'net' ports.
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'
Modems which end up being found unusable (e.g. no SIM, fatal SIM error, no
capabilities) will be exposed in DBus, but just with the Modem interface and
in a FAILED state which allows no actions.
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.
Make port roles more flexible. We have modems that do PPP
on interfaces other than the primary interface, and that
wasn't possible with the old code. So clean up all that
logic and move the port organization code into the core
so we can reduce code in the plugins.
In the new world order, the plugins say whether the port
is a QCDM port, an AT port, or ignored. If it's an AT
port the plugins get to tag it as primary, secondary, or
PPP, or any combination of the 3. This allows for modems
where PPP should really be done on the secondary port
(Huawei E220, Sierra devices) so that the primary port
stays open for command and status.
After all ports are grabbed by the generic classes, they get
"organized", which assigns various ports to the roles of
PRIMARY, SECONDARY, DATA, and QCDM based on specific rules
and hints that the plugin provided (which are expressed as
MMAtPortFlags).
The plugin code is responsible for determining the port
hints (ie MMAtPortFlags) at probe time, instead of having
a combination of the plugin and the modem class do the
job. This simplifies things greatly for the plugins at
the expense of more complicated logic in the core.
This is the port of commit 96505d42ed62327101dcee7c2bf31177b0bb1c9f
to the 06-api branch.
Bearers will ask for data ports that can be used for connections. Right now,
only one data port is expected to be handled, but we don't impose any
restriction in the API.
When the port is grabbed, we setup NULL callbacks for all unsolicited
registration message handlers. If we do enable 3GPP registrations
afterwards, we'll set proper callbacks.
When the first AT port is grabbed, modem initialization is launched, using that
specific port. This port is also passed to all interface initialization methods.
Aleksander Morgado