The set_initial_eps_bearer_settings() operation is the same in XMM
capable and generic MBIM modem objects. Place it in a common shared
interface so that we don't duplicate code.
This silents a warning given by udev:
Configuration file /usr/lib/udev/rules.d/77-mm-fibocom-port-types.rules is marked executable. Please remove executable permission bits. Proceeding anyway.
We won't create a full new different modem object based on whether the
ID_MM_FIBOCOM_INITIAL_EPS_OFF_ON tag is found or not. Instead, we
always will create the same object type, and detect whether the OFF/ON
cycle is required during runtime.
Assume that the method to change the initial EPS bearer settings is
always implemented in the parent, so that we can avoid the runtime
check.
This also fixes the codepath that would happen if the
iface_modem_3gpp_parent->set_initial_eps_bearer_settings == NULL
condition was valid, as that would end up with a GTask never completed.
When the attach APN settings are changed, the device will go through a
radio on -> radio off -> radio on cycle so that the new changes are
taken into consideration.
This change is done in a Fibocom-specific MBIM modem implementation
because it's working around a firmware bug that would prevent for the
attach settings to be considered automatically.
Fibocom's documentation states that we must double-check the connection
is established when setting up an ECM connection. The possible replies -
according to the documentation - are:
+GTRNDIS: <state>,<cid>,<ip>,<prim. dns>,<sec. dns>
OK
or
+GTRNDIS: 0
We just care about the state value which is 1 if everything worked.
The port type hints for the FM101 were updated to be in line with the final product layout,
where USB interface #2 is now used as an AT port (not ignored) and USB interface #4 is now
used as debug port. USB interface #6 is removed as it no longer exists.
There are modems out there, that reuse the same vid:pid for multiple
USB layouts, so there may be port type hints that are not really
applicable in all layouts.
E.g. the EM7565 in MBIM layout uses interface #0 for the MBIM port,
while in QMI layout it uses interface #0 for the QCDM port (which is
what the port type hint included in MM states). With these rules, if
we don't bind the port type hint to TTY ports only, we would be
wrongly flagging the MBIM port as possible QCDM port:
<debug> [plugin/sierra] probes required for port cdc-wdm0: 'mbim'
<debug> [cdc-wdm0/probe] no AT/QMI/MBIM probing in possible QCDM port
<debug> [cdc-wdm0/probe] port is not AT-capable
<debug> [cdc-wdm0/probe] port is not QMI-capable
<debug> [cdc-wdm0/probe] port is not MBIM-capable
<debug> [cdc-wdm0/probe] port probing finished: no more probings needed
Avoid this, by making sure all port type hints are added exclusively
to TTY ports. It's not a perfect solution, but it's enough for the
known cases.
Back in Linux < 3.6 days, the cdc-wdm ports exposed by the QMI driver
were flagged as owned by the 'usb' subsystem. That changed in 3.6 when
the subsystem was renamed to 'usbmisc':
https://mail.gnome.org/archives/networkmanager-list/2012-June/msg00125.html
This patch removes all monitoring of the 'usb' subsystem completely,
which is anyway a valid subsystem but for which we shouldn't need any
special handling. Right now, with newer kernels, we were using that
monitoring exclusively to get notified of full USB device remove
events, which is really not required as we already process the port
removals one by one.
We simplify the logic everywhere that attempted to match either the
'usb' or 'usbmisc' subsystems, and we no longer require the explicit
checks for the port name being named 'cdc-wdm[0-9]*' in the code, as
that is already taken care of by the ID_MM_CANDIDATE udev tag rule.
