Modem creation/startup order

Aleksander Morgado aleksander at
Wed Feb 15 14:11:04 UTC 2017

On Wed, Feb 15, 2017 at 10:46 AM, Colin Helliwell
<colin.helliwell at> wrote:
>> > I get the feeling its written with nearly-but-not-quite up to date methods, or just different ones. Certainly it's not easy to compare against USB-based drivers. From what I can make out, the three virtual ports are created with calls such as:
>> >  pDriver = alloc_tty_driver()
>> >  tty_set_operations(pDriver, &if_mux_ops) [after setting termios etc in pDriver, and *not* using TTY_DRIVER_DYNAMIC_DEV]
>> >  tty_register_driver(pDriver)
>> > if_mux_ops.install is a function which mallocs a struct tty_struct and then just tty_port_init(tty->port)
>> > All in all, hard to correlate against other drivers to identify where to bind to the physical device :S
>> > (Appreciate this isn't entirely a MM issue!)
>> Could you add udev rules for the two TTYs that you want to bind in the
>> same device and set the same ID_MM_PHYSDEV_UID udev tag for both? IIRC
>> that should also work even if the physical device paths stored are
>> different.
> Given that a try, but I think there's still the key problem that the TTY's physical device isn't being set?  ("[src/kerneldevice/mm-kernel-device-udev.c:458] kernel_device_is_candidate(): (tty/ttyMux0): could not get port's parent device")

Is the logic stopping there? the ID_MM_PHYSDEV_UID should take
precedence to whatever parent sysfs path is set, e.g. you could set
each tty's own sysfs path as parent sysfs path and would (should)
still work.


More information about the ModemManager-devel mailing list