> On 14 February 2017 at 12:59 Aleksander Morgado <aleksan...@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 :)
_______________________________________________
ModemManager-devel mailing list
ModemManager-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
