Modem creation/startup order

[Aleksander Morgado]

On Wed, Feb 15, 2017 at 10:46 AM, Colin Helliwell
<colin.helliwell at ln-systems.com> 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.

-- 
Aleksander
https://aleksander.es