答复: Instantiating rmnet devices for data ports on QRTR-based modems
carl.yin at quectel.com
Fri Oct 16 23:08:28 UTC 2020
Some ideas from me.
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)
So, others part of QUALCOMM's data services and QUALCOMM's rmnet drvier, we also can simplify.
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.
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
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.
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.
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.
Thanks & Best Regards!
殷张成 Carl yin| Software System Department Engineer | Quectel Wireless Solutions
Mobile: +86-138 0569 2573 | Email : carl.yin at quectel.com | Tel: +86-551-65869386-8666
Website: www.quectel.com | QQ: 7712269 | Wechat: 13805692573
Building 1-C, China Speech Valley Area A, 3335 Xiyou Road, High-tech Zone, Hefei, Anhui 230088, China
HQ: Building 5, Shanghai Business Park Phase III (Area B), No.1016 Tianlin Road, Minhang District, Shanghai 200233, China
> 发件人: ModemManager-devel
> [mailto:modemmanager-devel-bounces at lists.freedesktop.org] 代表
> Aleksander Morgado
> 发送时间: Saturday, October 17, 2020 5:20 AM
> 收件人: Eric Caruso <ejcaruso at chromium.org>
> 抄送: ModemManager (development)
> <modemmanager-devel at lists.freedesktop.org>; Michał Mazur
> <mkm at semihalf.com>; Bjørn Mork <bjorn at mork.no>; Andrew Lassalle
> <andrewlassalle at google.com>
> 主题: Re: Instantiating rmnet devices for data ports on QRTR-based
> > > > And an additional question I have; what if we start using QMAP
> > > > also for qmi_wwan based modems that support it? I think it would
> > > > be very similar to your current needs with QRTR/IPA, right? See
> > > > https://lists.freedesktop.org/archives/libqmi-devel/2018-July/0029
> > > > 35.html Maybe we can setup a common API in libqmi that brings up
> > > > the muxed network interfaces for both cases in a common way?
> > >
> > > Yes, that exact thought stroke me as well while skimming through
> > > this discussion. It would be nice if the API could abstract away the
> > > differences wrt adding network devices etc, and just present a
> > > common muxing API.
> > I haven't personally dealt with QMAP so I'm not really sure what's
> > going on there. The linked discussion does suggest a similar
> > architecture of one "real" net interface (wwan0 for QMAP, rmnet_ipa0
> > for QRTR/IPA) over which several "virtual" net ports are overlaid
> > (qmimuxN for QMAP, rmnet_dataN for QRTR/IPA).
> > Neither case would deal with QMI directly outside of the Bind Mux Data
> > Port message though, as far as I can tell. So I'm not sure if this is
> > an argument for keeping it in libqmi or not.
> At this point, I start to prefer the idea of keeping it in libqmi, but the logic
> should not be automatic on QmiDevice open. libqmi could provide a
> common method to add/delete the muxed interfaces, and that method
> would be implemented differently depending on what kernel driver is in
> use. Then, upper layers like MM or other programs using qmicli could
> trigger the instantiation of the virtual net devices as part of the connection
> attempt procedure.
> ModemManager-devel mailing list
> ModemManager-devel at lists.freedesktop.org
More information about the ModemManager-devel