Modem creation/startup order

Tue Feb 14 12:59:28 UTC 2017

On Tue, Feb 14, 2017 at 12:54 PM, Colin Helliwell
<colin.helliwell at ln-systems.com> wrote:
>> > > > Thanks. The question arises from needing to have monitoring & URCs etc on one port of my mux driver, and ppp on the other - I need to make sure that ppp doesn't get run on the 'monitoring' port i.e. the one that gets in first with having the URCs enabled.
>> > > > This all makes me think I need this 'primary'/'secondary' port stuff - after all that's more or less what the mux is doing too.
>> > > > Perhaps I can modify Cinterion's grab_port() to flag the ports as primary/secondary? (They're /dev/ttyMux0, /dev/ttyMux1). Does this sound feasible, or is there more to the dual-portness than that....?
>> > >
>> > > Just setup new Cinterion-specific udev rules to flag ports as primary
>> > > or secondary, as done in other plugins; e.g.
>> > > ID_MM_SIMTECH_PORT_TYPE_MODEM (primary+ppp) or
>> > > ID_MM_SIMTECH_PORT_TYPE_AUX (secondary).
>> >
>> > I've made that change in grab_port() and in the udev rules and it seems to be doing the flagging. But is the idea that the two [virtual] ports should show up as a single modem? (mmcli -L)
>> > If so, then I reckon I need something more somewhere - the debug is showing, for both ports, messages including:
>> > [src/mm-plugin-manager.c:979] device_context_continue(): [plugin manager] task 0: no more ports to probe
>> > [src/mm-device.c:525] mm_device_create_modem(): Creating modem with plugin 'Cinterion' and '1' ports
>> > [plugins/cinterion/mm-plugin-cinterion.c:175] grab_port(): (tty/ttyMux0)' Port flagged as primary {or PPP on the other}
>> > [src/mm-base-modem.c:280] mm_base_modem_grab_port(): (ttyMux0) type 'at' claimed by /sys/devices/virtual/tty/ttyMux0
>> > [src/mm-base-modem.c:864] log_port(): (/sys/devices/virtual/tty/ttyMux0) tty/ttyMux0 at (primary)
>> > [src/mm-base-modem.c:864] log_port(): (/sys/devices/virtual/tty/ttyMux0) tty/ttyMux0 data (primary)
>>
>> Yes, the idea is that both ports end up grabbed in the same modem. How
>> are these ports exposed by the kernel? Not via the usb subsystem it
>> seems? MM needs a way to find a common "physical device sysfs path"
>> for both ttys.
>>
>
> Indeed, not via USB but via my mux driver sitting on a plain UART. The underlying real hardware port - i.e. the common physical path - is /dev/ttymxc2, or (if this is the correct type of path...) I believe it's  /sys/devices/soc0/soc/2100000.aips-bus/21ec000.serial/tty/ttymxc2
> In terms of the mux driver itself, there's /sys/bus/platform/devices/linmux/  whose 'driver' symlink is to /sys/bus/platform/drivers/LinMux
>
>
> Early on in working with MM, I found I 'needed' to do some modifications to get the Cinterion plugin used. Albeit, I might not have done this is a good way - might have done it in a poor way that's now causing a problem with dual ports (?)
>

Yeah, likely.

> diff -Nu a/src/mm-base-manager.c b/src/mm-base-manager.c
> --- a/src/mm-base-manager.c     2017-01-17 09:20:13.872328767 +0000
> +++ b/src/mm-base-manager.c     2017-01-17 09:24:27.952329995 +0000
> @@ -194,6 +194,9 @@
>      name = g_udev_device_get_name (child);
>      if (name && strncmp (name, "rfcomm", 6) == 0)
>          return g_object_ref (child);
> +    /* LinMux doesn't have a parent */
> +    if (name && strncmp (name, "ttyMux", 6) == 0)
> +        return g_object_ref (child);
>

This is it. You're saying here that the "physical device" that owns
this port is the port device itself. And for each TTY exposed in the
same way, the same will happen, so none of the TTYs will share a
parent physical device object. You need a way to return a common
object for all your TTYs.

I'd suggest you work on this on git master, though, because this code
changed already there (e.g. with the optional udev-less backend)...

>      iter = g_object_ref (child);
>      while (iter && i++ < 8) {
>
> diff -Nur a/plugins/cinterion/mm-plugin-cinterion.c b/plugins/cinterion/mm-plugin-cinterion.c
> --- a/plugins/cinterion/mm-plugin-cinterion.c   2016-11-15 10:07:40.000000000 +0000
> +++ b/plugins/cinterion/mm-plugin-cinterion.c   2017-01-18 10:00:30.000000000 +0000
> @@ -203,6 +203,7 @@
>      static const gchar *subsystems[] = { "tty", "net", "usb", NULL };
>      static const gchar *vendor_strings[] = { "cinterion", "siemens", NULL };
>      static const guint16 vendor_ids[] = { 0x1e2d, 0x0681, 0 };
> +    static const gchar *drivers[] = { "linmux", NULL };
>      static const MMAsyncMethod custom_init = {
>          .async  = G_CALLBACK (cinterion_custom_init),
>          .finish = G_CALLBACK (cinterion_custom_init_finish),
> @@ -214,6 +215,7 @@
>                        MM_PLUGIN_ALLOWED_SUBSYSTEMS,     subsystems,
>                        MM_PLUGIN_ALLOWED_VENDOR_STRINGS, vendor_strings,
>                        MM_PLUGIN_ALLOWED_VENDOR_IDS,     vendor_ids,
> +                      MM_PLUGIN_ALLOWED_DRIVERS,        drivers,
>                        MM_PLUGIN_ALLOWED_AT,             TRUE,
>                        MM_PLUGIN_ALLOWED_QMI,            TRUE,
>                        MM_PLUGIN_CUSTOM_INIT,            &custom_init,
> diff -Nur a/src/mm-plugin.c b/src/mm-plugin.c
> --- a/src/mm-plugin.c   2016-11-15 10:07:40.000000000 +0000
> +++ b/src/mm-plugin.c   2017-01-18 11:05:16.553578652 +0000
> @@ -200,6 +200,7 @@
>      gboolean product_filtered = FALSE;
>      gboolean vendor_filtered = FALSE;
>      guint i;
> +    gboolean force_cinterion = FALSE;
>
>      *need_vendor_probing = FALSE;
>      *need_product_probing = FALSE;
> @@ -230,12 +231,19 @@
>          !self->priv->mbim) {
>          static const gchar *virtual_drivers [] = { "virtual", NULL };
>          const gchar **drivers;
> +        static const gchar *linmux_drivers [] = { "linmux", NULL };
>
>          /* Detect any modems accessible through the list of virtual ports */
>          drivers = (is_virtual_port (g_udev_device_get_name (port)) ?
>                     virtual_drivers :
>                     mm_device_get_drivers (device));
>
> +        force_cinterion = g_udev_device_get_property_as_boolean (port, "ID_MM_FORCE_CINT"); // my own custom var for udev rule
> +        if (force_cinterion)
> +        {
> +            drivers = linmux_drivers;
> +        }

I'm not totally sure why you would do this. What is the benefit of
hardcoding some driver string based on a udev tag in the generic code,
just to match then the driver in the Cinterion plugin? If you want a
given plugin to use a given modem, just tag the device as you did and
enable the "udev tag filter" in the plugin
(MM_PLUGIN_ALLOWED_UDEV_TAGS). See the 'mbm' plugin for example.

-- 
Aleksander
https://aleksander.es