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.
If ModemManager is not built with QMI support, the generic MBIM modem
object will not have any location support, so we cannot assume that
iface_modem_location_parent will be valid and that it will have all
load_location_capabilities(), enable_location_gathering() and
disable_location_gathering() implemented.
Fixes https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/362
0x0489 is the vendor ID of T77W968, 0x105b is the vendor ID of T99W175.
{0x105b, 0xe0b0},{0x105b, 0xe0b1} is T99W175 PCI device, used by Dell.
{0x105b, 0xe0ab} is T99W175 PCI device, used by Lenovo.
If the modem has an mbim port, create a MbimFoxconn object, regardless
of what the product ID is.
The firmware version format in the T99W175 was selected to have
firmware version + carrier config version + apps version.
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.
