Hey, > > > 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. -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
