Modem creation/startup order

[Colin Helliwell]

> On 15 February 2017 at 14:11 Aleksander Morgado <aleksander at aleksander.es> wrote:
> 
> 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.
> 

Hmmmm. Not fully understanding this (I'm sure drivers used to be much easier on the 2.6 kernel lol). 
Following Dan's reply, I'm trying to modify the driver in order to set the parent. Not sure if this is what you also mean by the "parent sysfs path", but I think you're saying that using the ID_MM_PHYSDEV_UID should/might allow it to work anyway, without the parent stuff? That would be my preference, over modifying the 3rd party driver, if it's possible.

On that assumption, I've been working through the code and can see that mm_kernel_device_get_physdev_uid() [which points to the udev kernel_device_get_physdev_uid()] is indeed called by device_added(), but *after* mm_kernel_device_is_candidate() is called [which points to the udev kernel_device_is_candidate()], and which 'errors' with the above message from line 458. I think!