Commit Graph
17 Commits
Author SHA1 Message Date
Aleksander Morgado aa4577dfb9 core: new kernel device object instead of an explicit GUdevDevice
Instead of relying constantly on GUdevDevice objects reported by GUdev, we now
use a new generic object (MMKernelDevice) for which we provide an initial GUdev
based backend.
2016-09-29 15:43:05 +02:00
Aleksander Morgado 1f813c4e96 core: allow identifying devices by a user-provided 'uid'
All ports of the same modem reported by the kernel will all be associated with
a common 'uid' (unique id), which uniquely identifies the physical device. This
logic was already in place, what we do now is avoid calling it  the 'sysfs
path' of the physical device, because we may not want to use that to identify
a device.

This logic now also enables the possibility of "naming" the modems in a unique
way by setting the "ID_MM_PHYSDEV_UID" property in the "usb_device" that owns
all the ports.

E.g. a custom device has 4 modems in 4 different USB ports. The device path of
each USB device will always be the same, so the naming rules could go like this:

    $ vim /usr/lib/udev/rules.d/78-mm-naming.rules

    ACTION!="add|change|move", GOTO="mm_naming_rules_end"
    DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.1", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-1"
    DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.2", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-2"
    DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.3", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-3"
    DEVPATH=="/devices/pci0000:00/0000:00:1d.0/usb4/4-1/4-1.5/4-1.5.4", ENV{ID_MM_PHYSDEV_UID}="USB-MODEM-4"
    LABEL="mm_naming_rules_end"

Each of the modems found will have a unique UID retrieved from the previous list
of rules. Then, "mmcli" has also been updated to allow using the UID instead of
the modem DBus path or index, e.g.:

    $ sudo mmcli -m USB-MODEM-1
    /org/freedesktop/ModemManager1/Modem/0 (device id '988d83252c0598f670c2d69d5f41e077204a92fd')
      -------------------------
      Hardware |   manufacturer: 'ZTE CORPORATION'
               |          model: 'MF637'
               |       revision: 'BD_W7P673A3F3V1.0.0B04'
               |      supported: 'gsm-umts'
               |        current: 'gsm-umts'
               |   equipment id: '356516027657837'
      -------------------------
      System   |         device: 'USB-MODEM-1'
               |        drivers: 'option'
               |         plugin: 'ZTE'
               |   primary port: 'ttyUSB5'
               |          ports: 'ttyUSB5 (at)'
    ...

    $ sudo mmcli -m USB-MODEM-1 --enable
    ...
2016-09-29 15:41:21 +02:00
Aleksander Morgado 9641d27518 device: allow creating 'virtual' devices 2014-02-13 13:41:33 +01:00
Aleksander Morgado b7fa48dd22 device: new 'hotplugged' property 2014-02-13 13:41:31 +01:00
Ben Chan e75dba639f core: add 'hotplugged' flag to indicate if modem is newly plugged in
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.
2013-01-18 11:27:51 +01:00
Aleksander Morgado 731812fe34 plugin: avoid QMI-managed net ports when compiling without QMI support 2012-12-27 13:51:28 +01:00
Aleksander Morgado 0436b3e457 api,introspection: report list of drivers, not just one
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'
2012-08-24 13:34:51 +02:00
Aleksander Morgado f6415a71b6 device: keep all unsupported ports in a separate list
Ports being marked as unsupported should not be passed to the plugin specific
create_modem() or grab_port() methods.
2012-08-06 20:07:50 +02:00
Aleksander Morgado ff8a962d99 port-probe: let us peek the `MMDevice' owning the probe from the probe itself 2012-08-06 20:06:47 +02:00
Aleksander Morgado bfc3cb27e1 device,plugin: let the MMPlugin' API know about MMDevice' 2012-08-06 20:06:46 +02:00
Aleksander Morgado 9d14e4e8e9 device: get vendor/product IDs
And don't do it in MMPlugin.
2012-08-06 20:06:45 +02:00
Aleksander Morgado b791e87b23 device: keep a list of port probes instead of just ports 2012-08-06 20:06:45 +02:00
Aleksander Morgado 66ec5cd724 device: signal grabbed/released ports 2012-08-06 20:06:44 +02:00
Aleksander Morgado 72ffa7a1e5 device: load driver being used when first port grabbed 2012-08-06 20:06:44 +02:00
Aleksander Morgado 7b7f5b9dcb device: keep sysfs path around for logging 2012-08-06 20:06:44 +02:00
Aleksander Morgado 0aff871b04 device: split `MMDevice' creation and plugin setting
We want to be able to create the MMDevice way before we have decided which
plugin to use.
2012-08-06 20:06:44 +02:00
Aleksander Morgado 815693661c core: compile all ports before creating the modem object
Before this, we only exported the modem to DBus when all ports were organized,
in order to make sure that we select as primary port the one we really want and
not the first AT port grabbed. Given that to get all the ports organized we also
needed to wait to get all the ports grabbed, we can now also defer the creation
of the modem object until all the ports get grabbed. This allows us to create
different types of objects based on the ports available (e.g. we can now create
QMI-supported modem objects if we see a QMI port around).
2012-08-06 20:06:44 +02:00