A new 'ID_MM_TTY_BAUDRATE' per-port udev tag is introduced, which
allows specifying the baudrate that will be used when opening a
specific serial port.
E.g.:
ACTION!="add|change|move", GOTO="mm_my_modem_end"
DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb1/1-1/1-1.3/*", ENV{ID_MM_TTY_BAUDRATE}="115200"
LABEL="mm_my_modem_end"
https://bugs.freedesktop.org/show_bug.cgi?id=100158
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
Modems may expose ports that are either just not used (e.g. modems exposing more
than 2 functional AT ports) or explicitly avoided (e.g. WWAN ports when we don't
know how to use them).
Those kind of ports are part of the modem, but not used by ModemManager. Still,
ModemManager should list them in the list of ports available for the modem, with
IGNORED type.
The Cinterion PHS8 reports a single AT port to be used as data port, and no
other port as primary. In this case, recover the tty as primary AT port, instead
of failing with an error.
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.
If an error occurs early during the initialization (e.g. during port setup), we
would be aborting without even having exported the modem interface. So detect
that case and skip setting the modem as valid.
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.