答复: Instantiating rmnet devices for data ports on QRTR-based modems

Tue Oct 20 04:20:01 UTC 2020

Hi Daniele:
	Your message is very useful,  QUALCOMM had try to upstream his rmnet driver.
	the rmnet driver need user space tool/software do lots of configure work,
	Like his process netmgrd detect rmnet hardware network interface, and then register to rmnet virtual driver.
	And hardware parameters of the modem like ep-type, dl_agg_max_size is not auto read from rmnet hardware driver.

> -----邮件原件-----
> 发件人: Daniele Palmas [mailto:dnlplm at gmail.com]
> 发送时间: Monday, October 19, 2020 10:16 PM
> 收件人: Aleksander Morgado <aleksander at aleksander.es>
> 抄送: Carl Yin(殷张成) <carl.yin at quectel.com>; Eric Caruso
> <ejcaruso at google.com>; Eric Caruso <ejcaruso at chromium.org>; Naveen Kumar
> <naveen.kumar at quectel.com>; ModemManager (development)
> <modemmanager-devel at lists.freedesktop.org>; Michał Mazur
> <mkm at semihalf.com>; Amit Dayan <amit.dayan at quectel.com>; Andrew
> Lassalle <andrewlassalle at google.com>; Bjørn Mork <bjorn at mork.no>
> 主题: Re: Instantiating rmnet devices for data ports on QRTR-based modems
> 
> Hi,
> 
> Il giorno lun 19 ott 2020 alle ore 09:57 Aleksander Morgado
> <aleksander at 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/wwan
> > > > 0
> > > >
> > > > 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 at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/modemmanager-devel