netdev - Re: [PATCH net-next 1/1] net: wwan: t7xx: Add AP CLDMA and GNSS port

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHNKnsTpxKF2bQMEyGfL=73YvtGWZmra_eL4n_qF+smtwSvmhA@mail.gmail.com>
Date:   Wed, 22 Jun 2022 02:45:02 +0300
From:   Sergey Ryazanov <ryazanov.s.a@...il.com>
To:     "moises.veleta" <moises.veleta@...ux.intel.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 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.

-- 
Sergey