During modem initialization we detected the flow control settings
supported by the modem, and selected the best one to use from them,
notifying it to the device via AT+IFC. The device was therefore
instructed to use that flow control setting for data transmission in
the TTY (i.e. not during AT control commands).
The missing thing was to also configure ourselves our end of the
serial port with the same flow control settings when getting into data
mode. By doing it ourselves, we avoid requiring any explicit setting
in pppd for flow control; pppd can assume the flow control settings
are already the expected ones.
Worth noting that all this setup is completely ignored for TTYs
exposed directly via USB.
https://bugs.freedesktop.org/show_bug.cgi?id=100394
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 previously had the modem initialization command merged with some other port
setup commands in the 'modem_init' step of the 'Modem' interface. Instead of
doing this, we now split the logic into two separate steps:
A first 'enabling_modem_init' modem initialization step is to be run just after
the ports have been opened, but only during the first enabling operation, and
only if the modem was not hotplugged. A hotplugged modem is assumed to be
properly initialized already, so no need to ATZ-it. Also, we will now wait 500ms
by default after the modem initialization command has been sent, to let it
settle down.
The second 'modem_init' step will be run during the 'Modem' interface
initialization, and it currently only holds specific setup of the primary and
secondary serial ports. We'll be modifying this logic a bit in the next commits,
so no big deal to have that step name unchanged.
The default AT commands to play with SMS rely on AT+CPMS to select the default
memory storages for different operations. AT+CPMS defines 3 different storages,
called 'mem1' (for reading/listing/deleting), 'mem2' (for storing or sending
from storage) and 'mem3' (for receiving).
For example, when an SMS is to be deleted, we first need to select with AT+CPMS
the proper 'mem1' storage before issuing the command to delete the SMS part.
But, in order to do this properly we need to synchronize the access to the
currently set storages, so that no more than one action is run in the storages
at the same time (e.g. don't store an SMS while another SMS is being deleted).
In order to synchronize this access, we now provide commands to lock()/unlock()
the storages, which should be used when we want to do some operation on them.
Note that this logic is only required because we cannot specify the storage
explicitly in the specific AT command operations. With QMI we don't need this
locking/unlocking.
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'
Instead of hardcoding the logic to decide which ports are open or closed in the
different steps, we now let the subclasses of MMBroadbandModem to do that
themselves.
We now provide:
* initialization_started() and initialization_stopped(): the generic
implementation does the serial port open/close in these steps.
* enabling_started(): the generic implementation does the serial port opening
here. The serial ports are kept open as long the modem is in enabled state.
* disabling_stopped(): the generic implementation does the serial port closing
here.
If we base our supported modes default guessing only on capabilities listed by
AT+GCAP, we find that we don't know how to differenciate between 2G and 3G 3GPP
modems. So, if supported, we will try to query the list of supported networks
with AT+WS46=?, which explicitly tells us if the modem supports GERAN and/or
UTRAN and/or E-UTRAN. Note that plugins need to request this new behaviour by
setting the `MM_BROADBAND_MODEM_USE_WS46' property to TRUE when creating the
modem object.