Hi, Il giorno lun 19 ott 2020 alle ore 09:57 Aleksander Morgado <aleksan...@aleksander.es> ha scritto: > > 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. >
Maybe a possibility to align things is to add rmnet support to qmi_wwan? In the past there was an attempt for this (see https://www.mail-archive.com/netdev@vger.kernel.org/msg239867.html), but not completed. Regards, Daniele > -- > Aleksander > https://aleksander.es > _______________________________________________ > ModemManager-devel mailing list > ModemManager-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
