Modem creation/startup order

Tue Feb 14 12:15:15 UTC 2017

> On 14 February 2017 at 11:54 Colin Helliwell <colin.helliwell at ln-systems.com> wrote:
> 
> > 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",
> 

Just reviewing the changes I did to mm-base-manager.c, I'm sensing it in fact needs something a little (lot) less crude in terms of patching device_added() and/or find_physical_device(), so as to somehow actually get and thus be able to use the mux driver's identity ?