Modem creation/startup order

Tue Feb 14 17:28:07 UTC 2017

On Tue, 2017-02-14 at 15:16 +0000, Colin Helliwell wrote:
> > On 14 February 2017 at 12:59 Aleksander Morgado <aleksander at aleksan
> > der.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...?

Your modem is obviously hardware, somewhere down the line.  Your mux
driver binds to that hardware, so it clearly knows what the parent
hardware is.  Ideally your mux driver can expose that in sysfs with a
'device' symlink that points back to the physical device.

For example, a USB modem that uses CDC-ACM exposes:

/sys/class/tty/ttyACM0

your mux driver (if it uses the kernel's TTY layer) will also have a
/sys/class/tty/XXXX directory.

This TTY device has a 'device' link inside it:

lrwxrwxrwx. 1 root root    0 Feb 14 11:06 device -> ../../../2-2:1.0

which when we "cd -P ../../../2-2:1.0" we get:

/sys/devices/pci0000:00/0000:00:14.0/usb2/2-2/2-2:1.0

which is what ModemManager actually uses to figure out which TTYs are
part of the same mode.  It's a very similar process for other bus types
too, as long as they are hotpluggable (like USB, PCI, PCMCIA, etc). 
Now if it's an embedded serial UART or something, it gets a bit more
dicey.

But your MUX driver should have some way to bind the physical device
unless this is like MUX-over-UDP to a remote modem.  Typically the
driver gets a "kobject" (really "struct device") it can use from the
kernel in its bind() function.  For example, in the 'hso' driver:

ttydev = tty_port_register_device_attr(&serial->port,
		tty_drv, minor, &serial->parent->interface->dev,
		serial->parent, hso_serial_dev_groups);

where the args are:

/**
 * tty_port_register_device_attr - register tty device
 * @port: tty_port of the device
 * @driver: tty_driver for this device
 * @index: index of the tty
 * @device: parent if exists, otherwise NULL
 * @drvdata: Driver data to be set to device.
 * @attr_grp: Attribute group to be set on device.

notice the @device parameter, which in the case of 'hso' is passed as
"&serial->parent->interface->dev" which is the 'struct device' of the
USB interface this TTY is getting created for.  The kernel copies that
into the tty's 'parent' pointer, and that eventually ends up in sysfs
as the /sys/class/tty/ttyXXX/device link.

So apologies if you know all this already...  but if you're not passing
the 'struct device' from the hardware you got in your MUXs bind()
routine (or whatever actually calls the mux) to the kernel when
creating your TTY, you probably should be...

Hope that's useful!

Dan

> > 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 :)
> _______________________________________________
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel