Commit Graph
10 Commits
Author SHA1 Message Date
Aleksander Morgado 950abbf8ee core: stop monitoring the 'usb' subsystem
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.
2020-11-13 08:57:06 +00:00
Aleksander Morgado c07382a486 udev: add tags also on bind action
When a new USB device is hotplugged, e.g. a USB<->RS232 converter that
exposes a single ttyUSB0, these udev events happen:

  add  /devices/pci0000:00/0000:00:14.0/usb2/2-1 (usb/usb-device)
  add  /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 (usb/usb-interface)
  add  /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0 (usb-serial)
  add  /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0/tty/ttyUSB0 (tty)
  bind /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0/ttyUSB0 (usb-serial)
  bind /devices/pci0000:00/0000:00:14.0/usb2/2-1/2-1:1.0 (usb/usb-interface)
  bind /devices/pci0000:00/0000:00:14.0/usb2/2-1 (usb/usb-device)

Our udev rules in MM only added tags in the 'add' events, and it looks
like the only ones 'persistent' after this sequence are those of the
last event happening on the specific path.

This meant that all TTY subsystem rules (e.g. ID_MM_CANDIDATE) would
be stored for later check (e.g. if ModemManager is started after these
rules have been applied), which was ok. "udevadm info -p ..." would
show these tags correctly always.

But this also meant that the 'bind' udev event happening for the USB
device didn't get any of our device-specific tags, and so we would be
missing them (e.g. ID_MM_DEVICE_MANUAL_SCAN_ONLY) if MM is started
after the last event has happened. "udevadm info -p ..." would
not show these tags.

Modify all our rules to also run at the 'bind' events.

See, for context:
  https://github.com/systemd/systemd/issues/8221
2018-06-02 16:54:37 +02:00
Aleksander Morgado c7c65e2d57 udev: simpler check for rfcomm device names
Just the same kind of match we use for cdc-wdm devices.
2016-08-06 10:41:52 +02:00
Lubomir Rintel d44690489b udev: Don't mark disconnected RFCOMM ttys as candidates
Bluetooth serial devices are weird. They begin life being bound with
RFCOMMCREATEDEV ioctl() and then move around the sysfs tree when they are
connected and disconnected. The connection is estabilished upon the first
open() and torn down upon last close(), their first user virtually being
"owner" of the connection. We don't want to be that process, we're only
interested in actually connected modems. However, currently we have no
knowledge of that and therefore we connect and disconnect multiple times while
probing.

This patch marks unconnected RFCOMM devices as uninteresting to us.
The actual connection and disconnection will be handled by NetworkManager.
2014-11-01 20:07:40 +01:00
Aleksander Morgado 494a70a8ff core: handle the 'usb'->'usbmisc' subsystem rename in the kernel
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.
2012-08-29 17:26:46 +02:00
Aleksander Morgado f1e711e01b udev: don't require specific driver for cdc-wdm ports
Reported by Bjørn Mork <bjorn@mork.no>
2012-08-29 17:14:47 +02:00
Aleksander Morgado 306b4eb509 core: allow grabbing QMI ports 2012-08-29 17:14:47 +02:00
Dan Williams 00b0b70f5d bluetooth: tag 'moved' bluetooth ttys as candidates
The kernel appears to add the device first without any parents,
then to move it to the correct place in the hierarchy, with its
immediate parent being the device's HCI controller.  So we need
to capture the 'move' event too since that's when the rfcomm
device is finally usable.
2010-12-19 15:18:12 -06:00
Dan Williams a4e620aca0 bluetooth: ensure bluetooth rfcomm devices get tagged as candidates 2010-12-19 15:07:56 -06:00
Dan Williams 592d71ff76 core: work around udev parallel startup race
Ignore devices that aren't completely configured by udev yet.  If
ModemManager is started in parallel with udev, explicitly requesting
devices may return devices for which not all udev rules have yet been
applied (a bug in udev/gudev).  Since we often need those rules to match
the device to a specific ModemManager driver, we need to ensure that all
rules have been processed before handling a device.

Do this by adding an item to the environment of each device that MM
might possibly be interested in, and ignoring devices that don't
have that.  When the device is fully processed by udev, MM will get
an 'add' event and the device will have all rules applied.
2010-12-08 17:04:59 -06:00