Modem creation/startup order

[Colin Helliwell]

> On 14 February 2017 at 12:59 Aleksander Morgado <aleksander at aleksander.es> wrote:
> 
> On Tue, Feb 14, 2017 at 12:54 PM, Colin Helliwell
> 
...
> > > 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.
>

Any tips on how to get started with that...?
 
> 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)...
> 

OK, will do.

...

> > 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
> > @@ -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.
> 

Just lack of understanding :)