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:dnl...@gmail.com]
> 发送时间: Monday, October 19, 2020 10:16 PM
> 收件人: Aleksander Morgado <aleksan...@aleksander.es>
> 抄送: Carl Yin(殷张成) <carl....@quectel.com>; Eric Caruso
> <ejcar...@google.com>; Eric Caruso <ejcar...@chromium.org>; Naveen Kumar
> <naveen.ku...@quectel.com>; ModemManager (development)
> <modemmanager-devel@lists.freedesktop.org>; Michał Mazur
> <m...@semihalf.com>; Amit Dayan <amit.da...@quectel.com>; Andrew
> Lassalle <andrewlassa...@google.com>; Bjørn Mork <bj...@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
> <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/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@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
