Hi All:
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....@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
安徽省合肥市高新区习友路3335号中国（合肥）国际智能语音产业园A区1号中试楼 230088
HQ: Building 5, Shanghai Business Park Phase III (Area B), No.1016 Tianlin
Road, Minhang District, Shanghai 200233, China
总部：上海市闵行区田林路1016号科技绿洲3期（B区）5号楼 200233
> -----邮件原件-----
> 发件人: ModemManager-devel
> [mailto:modemmanager-devel-boun...@lists.freedesktop.org] 代表
> Aleksander Morgado
> 发送时间: Saturday, October 17, 2020 5:20 AM
> 收件人: Eric Caruso <ejcar...@chromium.org>
> 抄送: ModemManager (development)
> <modemmanager-devel@lists.freedesktop.org>; Michał Mazur
> <m...@semihalf.com>; Bjørn Mork <bj...@mork.no>; Andrew Lassalle
> <andrewlassa...@google.com>
> 主题: Re: Instantiating rmnet devices for data ports on QRTR-based
> modems
>
> Hey,
>
> > > > 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.
>
> --
> 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
