Commit Graph

15 Commits

Author SHA1 Message Date
Aleksander Morgado
ae9ede926a core: use the kernel device object in the port object and the plugin interface
The mm_base_modem_grab_port() now receives a MMKernelDevice directly from the
plugin, which is then stored in the MMPort corresponding to the port.

This means that we have direct access to e.g. all properties set by udev rules
everywhere, and we don't need additional GUdevClient objects (e.g. like the one
used in the Huawei plugin to detect NDISDUP support during runtime).

For virtual ports (e.g. generated during unit tests), we have a new 'generic'
kernel device object which just provides the values from the kernel device
properties given during its creation.
2016-09-29 15:43:05 +02:00
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
a5baec65be simtech: support QMI devices 2016-05-31 11:22:13 +02:00
Ting-Yuan Huang
969189d42c plugin-manager: protect mm_plugin_{major,minor}_version
This patch makes declarations bind to definitions within the same module
to prevent the potential ambiguity if referenced directly.

AddressSanitizer think they violated one definition rule, although
those symbols are accessed by address through their modules and do
not depend on the order of the libararies loaded.
2016-05-28 13:59:54 +02:00
Aleksander Morgado
7c347aa3ec port: store parent sysfs path in each MMPort 2014-06-23 18:12:27 +02:00
Aleksander Morgado
6f235b9948 ports: rename 'MMAtSerialPort' to 'MMPortSerialAt' 2014-02-13 13:40:01 +01:00
Aleksander Morgado
3f3950bd12 plugins: log about all port type hints received from udev 2013-02-26 21:02:12 +01:00
Aleksander Morgado
c250fa3797 libmm-glib: remove the `libmm-common.h' header
Both the ModemManager daemon and the mmcli will now include `libmm-glib.h' only.

We also handle two new special `_LIBMM_INSIDE_MM' and `LIBMM_INSIDE_MMCLI'
symbols, which if included before the `libmm-glib.h' library allow us to:

 * Don't include the libmm-glib high level API in the ModemManager daemon, as
   the object names would clash with those in the core.

 * Define some of the methods of helper objects to be included only if compiling
   ModemManager daemon or the mmcli.
2012-10-04 10:17:12 +02: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
a9075b0c09 port-probe: rename _get_port() to _peek_port() as there is no ownership transfer 2012-08-06 20:06:45 +02:00
Aleksander Morgado
e5e46f489e core: merge MMPluginBase' and MMPlugin'
There's no real point in maintaining a separate `MMPlugin' interface, as all the
plugins will inherit from `MMPluginBase', so just merge them and simplify
everything.
2012-08-06 20:06:45 +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
Aleksander Morgado
8cd4b29fde simtech: new `MMBroadbandModemSimtech' object 2012-04-14 16:04:17 +02:00
Aleksander Morgado
7183216d9d simtech: start porting the SimTech plugin 2012-04-14 16:04:17 +02:00