qmi_wwan add_mux/del_mux

[Daniele Palmas]

Il giorno ven 22 gen 2021 alle ore 12:52 Aleksander Morgado
<aleksander at aleksander.es> ha scritto:
>
> Hey Daniele,
>
> > > 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?
> > >
> >
> > Yes, all your questions make sense to me and, to my understanding,
> > currently there's no solution at the driver level.
> >
> > As you sugget, the easiest change would probably be a sysfs file in
> > the qmimux network interface: I quickly wrote the attached patch,
> > without claiming to be correct, just to give the idea (applies to
> > current net-next).
> >
> > So it works something like:
> >
> > root at LABNL-ITC-SW01:~# ip link show
> > 7: wwp0s20u2i2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
> > mode DEFAULT group default qlen 1000
> >     link/ether 5e:1a:7e:1c:86:d4 brd ff:ff:ff:ff:ff:ff
> > root at LABNL-ITC-SW01:~# echo 5 >
> > /sys/bus/usb/devices/3-2:1.2/net/wwp0s20u2i2/qmi/add_mux
> > root at LABNL-ITC-SW01:~# echo 9 >
> > /sys/bus/usb/devices/3-2:1.2/net/wwp0s20u2i2/qmi/add_mux
> > root at LABNL-ITC-SW01:~# ip link show
> > 7: wwp0s20u2i2: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN
> > mode DEFAULT group default qlen 1000
> >     link/ether 5e:1a:7e:1c:86:d4 brd ff:ff:ff:ff:ff:ff
> > 8: qmimux0: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc noop state
> > DOWN mode DEFAULT group default qlen 1000
> >     link/none
> > 9: qmimux1: <POINTOPOINT,MULTICAST,NOARP> mtu 1500 qdisc noop state
> > DOWN mode DEFAULT group default qlen 1000
> >     link/none
> > root at LABNL-ITC-SW01:~# cat
> > /sys/bus/usb/devices/3-2:1.2/net/wwp0s20u2i2/upper_qmimux0/qmap/mux_id
> > 0x05
> > root at LABNL-ITC-SW01:~# cat
> > /sys/bus/usb/devices/3-2:1.2/net/wwp0s20u2i2/upper_qmimux1/qmap/mux_id
> > 0x09
> >
> > However, I'm not sure this is the best solution and would be accepted,
> > since there's reluctance to add new sysfs files.
> >
>
> As I understand it, the add_mux/del_mux API won't go away even if we
> integrate the rmnet support, so I think it would be a good idea to
> have the new "mux_id" sysfs attribute for the muxed interface, so that
> there's a clear way on how to map those interfaces by userspace.
> Otherwise, the integration using add_mux/del_mux would need to heavily
> rely on having "just one" application doing that management, which is
> a bit limited.
>

Agree, I can try working on it and submit to have some feedback.

Regards,
Daniele

> --
> Aleksander
> https://aleksander.es