qmi_wwan add_mux/del_mux

[Aleksander Morgado]

Hey Subash,

> >> > > Say I create a new muxed interface for mux id 5:
> >> > >   echo 5 > /sys/class/net/wwan0/qmi/add_mux
> >> > > A new qmimux0 interface is created.
> >> > >
> >> > > Is there any way to know which mux id was used to create the qmimux0
> >> > > looking just at sysfs or some other way? In other words, how would I
> >> > > know what the mux id is for a given qmimuxN interface that may not
> >> > > have been created by me?
> >> > >
> >> > > Also, say that I have 2 different programs creating this kind of
> >> > > interfaces, and both use the qmi/add_mux attribute. If they both run
> >> > > at the same time (asking for different mux ids), and two interfaces
> >> > > qmimux0 and qmimux1 are created, how can each program know which was
> >> > > the interface corresponding to the mux id they requested?
> >> > >
> >> > > Not sure I'm missing something, but I didn't find a way to do this
> >> > > kind of matchings. If the virtual qmimux interface exposed a sysfs
> >> > > attribute specifying which is the mux id they correspond to, the
> >> > > matching would be much easier. Would that be possible?
> >> > >
> >> > > For context, I'm trying to work on adding support for this interface
> >> > > in libqmi, with the new qmi_device_add_link() interface that is right
> >> > > now only available when using rmnet with netlink.
> >> > >
> >> >
> >> > In the context of multiplexing QMUX data sessions, Stephan also
> >> > suggested we revive this old patch that never got a v2 in the LKML:
> >> > https://lore.kernel.org/netdev/1530066614-24995-1-git-send-email-subashab@codeaurora.org/
> >> >
> >> > Adding support to use rmnet on top of qmi_wwan seems like a good idea,
> >> > and we would be able to use the implementation we already have for
> >> > e.g. IPA, e.g.:
> >> > https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/merge_requests/184#note_715900
> >> >
> >> > What do you all think?
> >>
> >> I think that would be the best solution, since it also allows
> >> homogeneity with PCIe MHI.
> >>
> >> Reading again the comments, it seems to me that the patch was not too
> >> far to be acceptable, so maybe it would be worth looking at it again.
> >>
> >
> > Subash, any reason why the patch was forgotten and no v2 proposed? Is
> > there something we can do to push it forward?
>
> Hi
>
> That was my bad. I will send an updated patch with the changes mentioned
> by Bjørn.

Great! Thanks for doing that :)

-- 
Aleksander
https://aleksander.es