aboutsummaryrefslogtreecommitdiff
path: root/src/mm-plugin.h
AgeCommit message (Collapse)Author
2025-02-21base-modem: add subsystem device ID propertySushrut Shree Trivedi
Subsystem device ID can be used for identifying PCI modems, so expose the property. Signed-off-by: Sushrut Shree Trivedi <quic_sushruts@quicinc.com>
2024-07-31port-probe: detect XMMRPC portsThomas Vogt
2023-09-18api,modem: new 'Physdev' propertyLukas Voegl
Signed-off-by: Lukas Voegl <lvoegl@tdt.de>
2023-01-03plugins: setup new helper macros to define shared utilsAleksander Morgado
2023-01-03plugins: setup new helper macros to define pluginsAleksander Morgado
We also remove the plugin headers completely as they are not really required anywhere.
2022-06-19port-probe: avoid QCDM port probing if not for specific pluginsDaniele Palmas
The QCDM/DIAG port is usually nowadays exclusively used by applications gathering traces from the modem, so avoid port probing and grabbing when plugins set the property MM_PLUGIN_ALLOWED_QCDM. A new property MM_PLUGIN_REQUIRED_QCDM is created for those plugins requiring the QCDM port for properly using a modem.
2022-05-24filter: add vendor id/subsystem vendor id filterDaniele Palmas
Some PCI modems prefer customizing the subsytem vendor ID, instead of the vendor ID. Add a filter for the couple vendor/subsystem vendor IDs.
2022-05-24base-modem: add subsystem vendor ID propertyDaniele Palmas
Subsystem vendor ID can be used for identifying PCI modems, so expose the property.
2020-11-13base-manager: automatic required subsystem detectionAleksander Morgado
Instead of assuming we require a fixed set of subsystems to monitor, compile the full list based on what the plugins have requested themselves.
2020-09-19core: add autoptr cleanup methods to all internal typesAleksander Morgado
2020-06-04filter: setup automatic per-vid checks in the plugin whitelistAleksander Morgado
Until now, the plugin whitelist rule in the filter would only handle those plugins that require specific udev tags, and those that had explicit full vid:pid pairs. This update makes a new implicit automatic whitelist for all devices that match any of the vids managed by the different plugins. Looking at the current list of devices in the blacklist and greylist maintained by ModemManager, there are no devices falling under the list of supported plugin vids that would need to be blacklisted; except for u-blox GPS modules: huawei -> 0x12d1 -> None in blacklist/greylist thuraya -> 0x1a26 -> None in blacklist/greylist telit -> 0x1bc7 -> None in blacklist/greylist dLink -> 0x2001 -> None in blacklist/greylist wavecom -> 0x114f -> None in blacklist/greylist x22x -> 0x1bbb,0x0b3c -> None in blacklist/greylist anydata -> 0x16d5 -> None in blacklist/greylist quectel -> 0x2c7c -> None in blacklist/greylist haier -> 0x201e -> None in blacklist/greylist novatel -> 0x1410 -> None in blacklist/greylist dell -> 0x413c -> None in blacklist/greylist option -> 0x0af0,0x1931 -> None in blacklist/greylist nokia -> 0x0421 -> None in blacklist/greylist cinterion -> 0x1e2d,0x0681 -> None in blacklist/greylist simtech -> 0x1e0e -> None in blacklist/greylist iridium -> 0x1edd -> None in blacklist/greylist pantech -> 0x106c -> None in blacklist/greylist longcheer -> 0x1c9e,0x1bbb -> None in blacklist/greylist linktop -> 0x230d -> None in blacklist/greylist sierra -> 0x1199 -> None in blacklist/greylist ublox -> 0x1546 -------------> GPS chips blacklisted !!!!! foxconn -> 0x0489 -> None in blacklist/greylist broadmobi -> 0x2020 -> None in blacklist/greylist fibocom -> 0x2cb7 -> None in blacklist/greylist tplink -> 0x2357 -> None in blacklist/greylist zte -> 0x19d2 -> None in blacklist/greylist The rules used to blacklist the u-blox GPS chips have already been moved to the u-blox plugin itself, and now they use the broader ID_MM_DEVICE_IGNORE tag that applies in all filter modes.
2020-04-08plugin: don't match generic plugin by nameAleksander Morgado
2019-09-11filter: update plugin whitelist logic to use 'allowed product ids'Aleksander Morgado
Several plugins define the specific device vid:pid pairs they support. Let's use this information as a direct indication that ModemManager can probe the devices.
2019-09-06filter: new plugin whitelist logicAleksander Morgado
Several plugins define specific udev tags that must be available in the device in order for the plugins to use them. Let's use these tags as a direct indication that ModemManager can probe the devices. In particular, this change would make all Ericsson MBM modems probed right away also in STRICT filter mode, without needing to check the ttyACM interface type or the available net ports.
2019-09-06plugin: minor coding style updateAleksander Morgado
2018-08-21plugin: new properties to support Intel XMM capability probingAleksander Morgado
2016-09-29core: new kernel device object instead of an explicit GUdevDeviceAleksander Morgado
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-29core: allow identifying devices by a user-provided 'uid'Aleksander Morgado
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-05-28plugin-manager: protect mm_plugin_{major,minor}_versionTing-Yuan Huang
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-03-09plugin: allow cancellation of the port probe operationAleksander Morgado
2013-04-17plugin: allow plugins to require MBIM probing of cdc-wdm portsAleksander Morgado
2013-03-28serial: add support to optionally send line-feed at the end of AT commands.ori inbar
2013-03-28plugin: explicitly request QMI probingAleksander Morgado
Plugins which may support QMI ports need to explicitly request QMI probing in cdc-wdm devices. This should also avoid probing cdc-wdm ports when we know that the plugin doesn't support them (e.g. with Ericsson MBM devices). https://bugzilla.gnome.org/show_bug.cgi?id=696701
2012-10-30plugin-manager,plugin: run pre-probing filters earlyAleksander Morgado
For each port, we will construct the list of plugins to test with. In that list we will include those plugins which are likely to handle a given port, so we will skip all those which aren't. To see if a plugin is likely or not, we will run the pre-probing filters before adding them to the list, with the new `mm_plugin_discard_port_early()'. This method will return one of these hints: * UNSUPPORTED: The plugin will not be able to handle this port. * MAYBE: The plugin may handle this port. * LIKELY: The plugin may (very likely) handle this port. * SUPPORTED: If any plugin should support the port, this is it. Plugins reported to be 'likely' supporting the port will be probed before the ones reported just as 'maybe'. If a plugin reports 'supported' only that one and the fallback generic ones will be tried.
2012-08-31plugin: let plugins decide if they want echo removal during AT probingAleksander Morgado
This is the port to git master of the following patch: commit 21e66dfa1774ac2ee037ac8b6e8bb4d71a6f7931 Author: Dan Williams <dcbw@redhat.com> Date: Thu Aug 23 21:13:35 2012 -0500 core: add function to open probe ports without removing echo Some devices (Sierra GSM ones) return stuff we need but don't bother to prefix it with <CR><LF>, so we need to optionally turn off the echo removal at probe time.
2012-08-24api,introspection: report list of drivers, not just oneAleksander Morgado
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-20plugin: new filters for forbidden product IDs/stringsAleksander Morgado
Plugins may specify that specific vendor & product IDs or strings are not supported. This is useful when plugins need to specify that they support all devices of a given vendor except for some specific ones.
2012-08-06plugin: let plugins request Icera support checks and Icera based filtersAleksander Morgado
2012-08-06plugin: if no grab_port() method given, use the default oneAleksander Morgado
2012-08-06device,plugin: let the `MMPlugin' API know about `MMDevice'Aleksander Morgado
2012-08-06plugin: new method to compare pluginsAleksander Morgado
Instead of providing a method to get if a plugin is requesting to get sorted last, we provide a way to comparing two plugins, compatible with the GCompareFunc required in g_list_sort().
2012-08-06plugin: new `MM_PLUGIN_CUSTOM_INIT' propertyAleksander Morgado
We let plugins execute some custom initialization in the ports, specified by a `MMAsyncMethod'.
2012-08-06plugin: new `MM_PLUGIN_FORBIDDEN_DRIVERS' propertyAleksander Morgado
It allows plugins to specify whether they cannot support ports handled by specific drivers.
2012-08-06plugin: remove no longer used `MM_PLUGIN_SORT_LAST' propertyAleksander Morgado
The behaviour previously handled by this property is now automatically handled.
2012-08-06plugin: renamed `custom-init' property to `custom-at-probe'Aleksander Morgado
The `custom-at-probe' property is just to modify the way we check for AT port support.
2012-08-06plugin: setup a `priv' opaque pointer for the internal dataAleksander Morgado
G_TYPE_INSTANCE_GET_PRIVATE() is really slow, so try to call it as less as possible.
2012-08-06plugin: don't provide an additional method to cancel the probingAleksander Morgado
We'll do it with a GCancellable.
2012-08-06plugin: simplify interface by passing around the device and/or port objectsAleksander Morgado
2012-08-06device: keep a list of port probes instead of just portsAleksander Morgado
2012-08-06core: merge `MMPluginBase' and `MMPlugin'Aleksander Morgado
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-06core: compile all ports before creating the modem objectAleksander Morgado
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-03-26plugin: bump major plugin versionAleksander Morgado
The PluginBase object got modified during the new codebase development, and therefore we need to ensure that the current codebase doesn't try to load old plugins.
2012-03-16plugin: remove unnecessary callback typeAleksander Morgado
2012-03-15plugin-manager: new defer-until-suggested support check result handlingAleksander Morgado
'net' ports will be supported as soon as there is another port reporting successful support.
2012-03-15core: start using MMBroadbandModem objectsAleksander Morgado
We chain up the Generic plugin created MMBroadbandModem objects within the GDBusObjectManagerServer in MMManager, so that they get properly exported in DBus.
2012-03-15plugin-base: remove `MM_PLUGIN_SUPPORTS_PORT_IN_PROGRESS' statusAleksander Morgado
Support checks are fully asynchronous and result is always reported when the check is considered ready, so in-progress replies to `mm_plugin_supports_port_finish()' don't make any sense.
2012-03-15plugin-base: don't report numeric support level in the [0-100] rangeAleksander Morgado
There is no single case where more than one plugin may end up wanting to support a given port, and therefore there is no need to report the numeric support level when reporting SUPPORTED.
2012-03-15plugin-base: rename 'cancel_supports_port' to 'supports_port_cancel'Aleksander Morgado
We now have 'supports_port' (async method) and 'supports_port_finish' (to get the result of the async method), so it makes sense to rename the method to 'supports_port_cancel'.
2012-03-15plugin-base: rewrite port supports check as fully asynchronousAleksander Morgado
Before this change, supports check was either synchronous (e.g. in some UNSUPPORTED cases) or asynchronous (when IN_PROGRESS was returned). With this fix, the supports check requested to the plugin will always be completed asynchronously; either directly in an idle before launching any real probing operation, or once the probing operation is finished. Therefore, it is not expected to get a IN_PROGRESS reply in mm_plugin_supports_port_finish(), only UNSUPPORTED|SUPPORTED|DEFERRED.
2011-06-06plugin base: let plugins decide if they should be sorted lastAleksander Morgado
Note that even if a plugin says it wants to be sorted last, the generic plugin will always be the last one. Also, there is no order guaranteed between two plugins that request to be sorted last.
generated by cgit v1.2.3-70-g09d2 (git 2.46.0) at 2025-06-07 20:19:33 +0000