Instantiating rmnet devices for data ports on QRTR-based modems
dnlplm at gmail.com
Mon Oct 19 14:16:29 UTC 2020
Il giorno lun 19 ott 2020 alle ore 09:57 Aleksander Morgado
<aleksander at aleksander.es> ha scritto:
> > > > I seem we have done for "QMI based on QTRT" in libqmi.
> > > > For QUALCOMM's data services, there are lots of QMI library,
> > > > and libqmi used a more simply solution. (in fact, if just send QMI,
> > > > QTRT is also not a good idea)
> > >
> > > Why do you say QRTR is not a good idea? Isn't QMI over QRTR the only way to
> > > handle the communication in certain setups?
> > [carl.yin] 1. QRTR codes is much complex than direct send QMI message via QMI channel like /dev/cdc-wdm0
> > And it is not easy to find real hardware device for the QTRT node.
> > No matter the hardware interface between AP and Qualcomm modem is USB/PCIE/SMD,
> > (SMD is for QUALCOMM inter-AP, like MDM, APQ,MSM chipset.)
> > There always have QMI channel can be used to send QMI message.
> > If use these QMI channel, very few modifies is need apply to libqmi and MM
> I cannot comment on this, probably @Eric Caruso has a better point of view.
> > > This logic you're suggesting, except for step 5 I think, is what we already had in
> > > mind more or less. I think we could have that done by ModemManager, and
> > > connection managers like NetworkManager will get that working automatically,
> > > but now I also fear that if we change the default QMI modem behavior w.r.t.
> > > which is the connected network interface, we may be breaking user setups out
> > > there that rely on fixed interface names (e.g. for iptables rules).
> > >
> > > > rmnet_dataX is not a good name, there may be rment_usb0,
> > > rment_mhi0 exist at the same time, so can named as rment_usb0_X.
> > >
> > > In qmi_wwan, the muxed interfaces are named qmimux0, qmimux1 ... And if you
> > > have 5 different modems, each of them instantiating muxed virtual interfaces,
> > > they'll just get assigned sequential interface names, without any reference in the
> > > interface name to which physical interface they're mapped to. I don't think the
> > > name of the interface matters much at this point, as long as we can know which
> > > virtual interface maps to which physical interface.
> > >
> > > E.g. qmi_wwan adds a "lower_wwan0" file in the virtual interface sysfs contents
> > > pointing to the physical interface:
> > > # ls -ltr /sys/class/net/qmimux0/lower_wwan0
> > > lrwxrwxrwx 1 root root 0 Oct 17 20:52
> > > /sys/class/net/qmimux0/lower_wwan0 ->
> > > ../../../pci0000:00/0000:00:16.0/usb1/1-1/1-1.2/1-1.2:1.8/net/wwan0
> > >
> > > And it adds a "upper_qmimux0" file in the physical interface sysfs pointing to the
> > > virtual device:
> > > # ls -ltr /sys/class/net/wwan0/upper_qmimux0
> > > lrwxrwxrwx 1 root root 0 Oct 17 20:53
> > > /sys/class/net/wwan0/upper_qmimux0 ->
> > > ../../../../../../../../virtual/net/qmimux0
> > >
> > > As long as we have this kind of relationship between the virtual and physical
> > > interfaces, we're good to go, regardless of the actual naming of the interface.
> > [carl.yin] developer can find the relationship of wwanX and qmimuxX.
> > But for the end customers, maybe it is difficult, maybe he want to setup data call on PDN-x on modem y.
> > It will be Very intuitive if we can make PDN-x to muxid-X to rmnet_modemY_X.
> I truly don't have a strong opinion on that, kernel devs probably have
> a better idea on what the naming should look like. Either way, it is
> true that the current kernel implementation for the muxing in qmi_wwan
> already relies on that naming mechanism, so not sure if that could be
> changed right now without breaking the API.
Maybe a possibility to align things is to add rmnet support to
qmi_wwan? In the past there was an attempt for this (see
but not completed.
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
More information about the ModemManager-devel