lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <cb473297-f64d-7346-d649-58413f3e033e@linux.intel.com>
Date:   Tue, 21 Jun 2022 23:40:58 -0700
From:   "moises.veleta" <moises.veleta@...ux.intel.com>
To:     Sergey Ryazanov <ryazanov.s.a@...il.com>
Cc:     Loic Poulain <loic.poulain@...aro.org>, netdev@...r.kernel.org,
        Jakub Kicinski <kuba@...nel.org>,
        David Miller <davem@...emloft.net>,
        Johannes Berg <johannes@...solutions.net>,
        M Chetan Kumar <m.chetan.kumar@...el.com>,
        "Devegowda, Chandrashekar" <chandrashekar.devegowda@...el.com>,
        Intel Corporation <linuxwwan@...el.com>,
        chiranjeevi.rapolu@...ux.intel.com,
        Haijun Liu (刘海军) 
        <haijun.liu@...iatek.com>,
        Ricardo Martinez <ricardo.martinez@...ux.intel.com>,
        Andy Shevchenko <andriy.shevchenko@...ux.intel.com>,
        "Sharma, Dinesh" <dinesh.sharma@...el.com>,
        Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
        "Veleta, Moises" <moises.veleta@...el.com>,
        Madhusmita Sahu <madhusmita.sahu@...el.com>
Subject: Re: [PATCH net-next 1/1] net: wwan: t7xx: Add AP CLDMA and GNSS port


On 6/21/22 16:45, Sergey Ryazanov wrote:
> On Tue, Jun 21, 2022 at 7:45 PM moises.veleta
> <moises.veleta@...ux.intel.com> wrote:
>> On 6/18/22 04:55, Sergey Ryazanov wrote:
>>> On Fri, Jun 17, 2022 at 8:28 PM moises.veleta
>>> <moises.veleta@...ux.intel.com> wrote:
>>>> On 6/16/22 10:29, Loic Poulain wrote:
>>>>> On Tue, 14 Jun 2022 at 22:58, Moises Veleta
>>>>> <moises.veleta@...ux.intel.com> wrote:
>>>>>> The t7xx device contains two Cross Layer DMA (CLDMA) interfaces to
>>>>>> communicate with AP and Modem processors respectively. So far only
>>>>>> MD-CLDMA was being used, this patch enables AP-CLDMA and the GNSS
>>>>>> port which requires such channel.
>>>>>>
>>>>>> Signed-off-by: Haijun Liu <haijun.liu@...iatek.com>
>>>>>> Co-developed-by: Madhusmita Sahu <madhusmita.sahu@...el.com>
>>>>>> Signed-off-by: Madhusmita Sahu <madhusmita.sahu@...el.com>
>>>>>> Signed-off-by: Moises Veleta <moises.veleta@...ux.intel.com>
>>>>>> ---
>>>>> [...]
>>>>>>     static const struct t7xx_port_conf t7xx_md_port_conf[] = {
>>>>>>            {
>>>>>> +               .tx_ch = PORT_CH_AP_GNSS_TX,
>>>>>> +               .rx_ch = PORT_CH_AP_GNSS_RX,
>>>>>> +               .txq_index = Q_IDX_CTRL,
>>>>>> +               .rxq_index = Q_IDX_CTRL,
>>>>>> +               .path_id = CLDMA_ID_AP,
>>>>>> +               .ops = &wwan_sub_port_ops,
>>>>>> +               .name = "t7xx_ap_gnss",
>>>>>> +               .port_type = WWAN_PORT_AT,
>>>>> Is it really AT protocol here? wouldn't it be possible to expose it
>>>>> via the existing GNSS susbsystem?
>>>> The protocol is AT.
>>>> It is not possible to using the GNSS subsystem as it is meant for
>>>> stand-alone GNSS receivers without a control path. In this case, GNSS
>>>> can used for different use cases, such as Assisted GNSS, Cell ID
>>>> positioning, Geofence, etc. Hence, this requires the use of the AT
>>>> channel on the WWAN subsystem.
>>> To make it clear. When you talking about a control path, did you mean
>>> that this GNSS port is not a simple NMEA port? Or did you mean that
>>> this port is NMEA, but the user is required to activate GPS
>>> functionality using the separate AT-commands port?
>>>
>>> In other words, what is the format of the data that are transmitted
>>> over the GNSS port of the modem?
>>>
>> It is an AT port where MTK GNSS AT commands can be sent and received.
>> Not a simple NMEA port, but NMEA data can be sent to Host via an AT
>> command. Control port is exposed for Modem Manager to send GNSS comands,
>> which may include disable/enable GPS functionality (enabled by default).
>>
>> These are MTK GNSS AT commands, which follow the syntax as defined by
>> 3GPP TS 27.007.  These are not standard AT commands.
> Now it is pretty clear. Thank you for your explanation. Please add
> this info somewhere near the GNSS port static configuration. This will
> help avoid similar confusion in the future.
>
> BTW, does the regular AT port of this modem support the MTK GNSS AT
> commands? Or maybe the GNSS port supports regular modem management AT
> commands (PDP, RSSI, SMS, etc.)? In other words, are these GNSS and AT
> ports interchangeable or does each have a specific purpose?
>
> If both ports are interchangeable, then it is ok to expose each as a
> WWAN AT port. But if the GNSS port only supports the MTK GNSS AT
> commands, then I am afraid we should not expose it via the WWAN
> subsystem at least as a regular AT port. This probably will confuse a
> user a lot.
>
> It is not the format of the command used, it is a matter of the
> interface nature. There will be different controlling daemons. E.g.,
> the AT port will be used by ModemManager or something similar and the
> GNSS port will be used by gpsd. And a user will have a hard time to
> figure out which WWAN AT port should be used for what purpose if we
> expose these ports simply as wwan0at0 and wwan0at1.
>
The ports are not interchangeable. Each has a specific purpose. Modem 
port is used for sending Modem commands and GNSS port for GNSS commands.

MTK architecture is defined to have Modem as part of the base-band 
processor and GNSS chip part of the Application Processor. MTK wanted to 
keep the architecture simple and common for SKU's that have GNSS 
solution or not. One example is the MTK's M70 which did not have a GNSS 
solution.

We have different architectures, some fully AT based WWAN modems, or 
fully MBIM, and composite Modems (where Modem interfaces go on MBIM and 
GNSS on AT). This falls under the third category where GPS control port 
(over AT) supports GNSS functionality. There are not standard MBIM 
commands for GNSS and thus GNSS is only supported over AT via MTK 
proprietary commands.

This has been discussed with ModemManager maintainer (Aleksander) who 
introduced MM_PORT_SERIAL_AT_FLAG_GPS_CONTROL, an AT port that is used 
purely for GPS control.  See Gerrit 
https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/merge_requests/753/diffs?commit_id=343f27a5e7b0226e10aec025c502703d0be9d1ac#0dbbdd1ea5ff4bb4ee5b3bd70e9bb0502e02eeea

Since the GNSS solution is part of the M.2 WWAN module, we believe that 
the GNSS port should be exposed by the WWAN subsystem and that 
ModemManager treats this AT port as a GPS control port.

Note that the GNSS port helps supports functionalities such as:
1. Start/Stop GNSS sessions
2. Configuration commands to support Assisted GNSS positioning
3. Crash & reboot (notifications when device is reset (AP) & host is reset)
4. Settings to Enable/Disable GNSS solution
5. Geofencing

Regards,
Moises

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ