Hey Carl, > Some ideas from me.
Thanks for your comments, very much appreciated. > The discussion is based on QUALCOMM's rmnet driver and his data > services. > We are discussing how porting these software to MM and libqmi. > But I think QUALLCOMM's solution is too complex, porting is > impossible. > What we have to do is re-implementation. > > 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? > > So, others part of QUALCOMM's data services and QUALCOMM's rmnet > drvier, we also can simplify. > I'm all for simplifying :D > Take rmnet driver for example: > QUALCOMM;s rmnet driver consist of two parts. > 1. physic netcard part, name as rmnet_usb.c/rmnet_mhi.c/rmnet_ipa.c,, > depend on the hardware interface used. > this driver response for transfer QMAP packet to modem. > 2. virtual nectar part, name as rmnet_data.c, this driver response > for: rx IP packets from tcp/ip stack, and add QMAP header to IP packet, and > sent to rmnet physic driver. > Ok, understood. > So the process can next: > 1. rmnet physic driver probe, create netcard > rmnet_usb0/rmnet_mhi0/rmnet_ipa0, and call register_rmnet_data > 2. rmnet data driver create rmnet_data0 Are you suggesting that there is always a virtual network interface created for the physical network interface? In terms of qmi_wwan, are you suggesting a virtual qmimux0 is always created when the physical wwan0 interface is exposed? What would be the benefit of doing that? > 3. MM query qmap-version, ep-type, iface-id, > dll_data_aggregation_max_size from rmnet physic driver > 4. MM send QMIWDS_ADMIN_SET_DATA_FORMAT_REQ to modem. > 5. MM get ul_data_aggregation_max_size from > QMIWDS_ADMIN_SET_DATA_FORMAT_RESP, and send to rmnet physic driver. @Bjørn Mork @Daniele Palmas is that step 5 something we're not currently doing and we may need to do? Does the physical wwan interface truly need to know the ul_data_aggregation_max_size? > 6. MM want to setup data call on PDN-x. MM send muxid-X to rmnet > physic driver, rmnet physic driver tell rmnet data driver to create > rmnet_dataX. > 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. It is true, though, that with the current qmi_wwan logic we cannot force Qualcomm's relationship between mux ID and the name of the interface being ID-1, because the qmimux names are given sequentially as they're allocated. Not a big deal, though. -- Aleksander https://aleksander.es _______________________________________________ ModemManager-devel mailing list ModemManager-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel
