Modem creation/startup order

[Aleksander Morgado]

On Wed, Feb 15, 2017 at 4:16 PM, Colin Helliwell
<colin.helliwell at ln-systems.com> wrote:
>> On 15 February 2017 at 15:07 Colin Helliwell <colin.helliwell at ln-systems.com> wrote:
>>
>> > On 15 February 2017 at 14:11 Aleksander Morgado <aleksander at aleksander.es> wrote:
>> >
>> > 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.
>>
> ...
>>
>> 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!
>>
>
> Not sure of the intended purpose of ID_MM_PHYSDEV_UID but, if it's there as an override, would it be acceptable to allow its presence to override the
>     if (!self->priv->physdev) {
> in kernel_device_is_candidate() ?

Yes, I think that would be somewhat acceptable, you could try that.

The purpose of ID_MM_PHYSDEV_UID is to have the user provide a "unique
id" which may be used as name when referencing a modem, e.g. "mmcli -m
NAME"; but that also serves the purpose of binding together ports with
the same "unique id", as the default "unique id" being used right now
is the sysfs path of the physical device (the one that owns all
ports).

-- 
Aleksander
https://aleksander.es