qmi_wwan add_mux/del_mux

[Aleksander Morgado]

Hey all,

> > >> > > 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 :)
>

The patch is already in net-next, yey!

Regarding libqmi-glib, I thought of adding new APIs in the QmiDevice
to allow setting/getting the pass through value, but given that this
setting *requires* first enabling raw-ip, I have instead updated the
QmiDeviceExpectedDataFormat enum with a new "QMAP_PASS_THROUGH" value,
in addition to "802_3" and "RAW_IP". The
qmi_device_set_expected_data_format() will update the "raw_ip" and
"pass_through" settings to the required values for each
QmiDeviceExpectedDataFormat (considering also that in older kernels
these may not exist)

See https://gitlab.freedesktop.org/mobile-broadband/libqmi/-/merge_requests/205

Comments welcome!

-- 
Aleksander
https://aleksander.es