Modem creation/startup order

[Colin Helliwell]

> On 14 February 2017 at 11:33 Aleksander Morgado <aleksander at aleksander.es> wrote:
> 
> On Tue, Feb 14, 2017 at 11:39 AM, 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 (?)

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);
 
     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;
+        }
+
         /* If error retrieving driver: unsupported */
         if (!drivers) {
             mm_dbg ("(%s) [%s] filtered as couldn't retrieve drivers",