Re: [RFC PATCH v2 0/6] net: wwan: add NMEA port type support

[Sergey Ryazanov <ryazanov.s.a@gmail.com>]

Hi Slark,

On 9/11/25 05:42, Slark Xiao wrote:
> At 2025-06-30 15:30:14, "Loic Poulain" <loic.poulain@oss.qualcomm.com> wrote:
>> On Sun, Jun 29, 2025 at 12:07 PM Sergey Ryazanov <ryazanov.s.a@gmail.com> wrote:
>>> On 6/29/25 05:50, Loic Poulain wrote:
>>>> On Tue, Jun 24, 2025 at 11:39 PM Sergey Ryazanov <ryazanov.s.a@gmail.com> wrote:
>>>>> The series introduces a long discussed NMEA port type support for the
>>>>> WWAN subsystem. There are two goals. From the WWAN driver perspective,
>>>>> NMEA exported as any other port type (e.g. AT, MBIM, QMI, etc.). From
>>>>> user space software perspective, the exported chardev belongs to the
>>>>> GNSS class what makes it easy to distinguish desired port and the WWAN
>>>>> device common to both NMEA and control (AT, MBIM, etc.) ports makes it
>>>>> easy to locate a control port for the GNSS receiver activation.
>>>>>
>>>>> Done by exporting the NMEA port via the GNSS subsystem with the WWAN
>>>>> core acting as proxy between the WWAN modem driver and the GNSS
>>>>> subsystem.
>>>>>
>>>>> The series starts from a cleanup patch. Then two patches prepares the
>>>>> WWAN core for the proxy style operation. Followed by a patch introding a
>>>>> new WWNA port type, integration with the GNSS subsystem and demux. The
>>>>> series ends with a couple of patches that introduce emulated EMEA port
>>>>> to the WWAN HW simulator.
>>>>>
>>>>> The series is the product of the discussion with Loic about the pros and
>>>>> cons of possible models and implementation. Also Muhammad and Slark did
>>>>> a great job defining the problem, sharing the code and pushing me to
>>>>> finish the implementation. Many thanks.
>>>>>
>>>>> Comments are welcomed.
>>>>>
>>>>> Slark, Muhammad, if this series suits you, feel free to bundle it with
>>>>> the driver changes and (re-)send for final inclusion as a single series.
>>>>>
>>>>> Changes RFCv1->RFCv2:
>>>>> * Uniformly use put_device() to release port memory. This made code less
>>>>>     weird and way more clear. Thank you, Loic, for noticing and the fix
>>>>>     discussion!
>>>>
>>>> I think you can now send that series without the RFC tag. It looks good to me.
>>>
>>> Thank you for reviewing it. Do you think it makes sense to introduce new
>>> API without an actual user? Ok, we have two drivers potentially ready to
>>> use GNSS port type, but they are not yet here. That is why I have send
>>> as RFC. On another hand, testing with simulator has not revealed any
>>> issue and GNSS port type implementation looks ready to be merged.
>>
>> Right, we need a proper user for it, I think some MHI PCIe modems already
>> have this NMEA port available, so it can easily be added to this PR. For sure
>> we will need someone to test this.
>>
> Hi Loic, Sergey,
> Any update about this topic?
> If you want to test it, we can provide some help on this. Also, I think the quicinc
> center may also do some test. You can contact it with Mani for further details.

Basically the functionality is done, Loic has reviewed it, while not 
formally acked yet. And it can be merged just now. On another hand we 
have no users for it. That is why I have not sent it as a final patch.

I was expected you, Slark, or Muhammad will take these patches, 
incorporate into a driver change that introduces NMEA port export and we 
can merge all together. Or if you prefer this series being merged first 
and then you will send your changes. In this case I need a green light 
from you that you tested this series locally and there are no objections.

To summarize, we have two options:
a) you incorporate this series into your changes and send a bigger 
series implementing everything from driver to the core;
b) we merge this series as it is, and then you send an follow up changes 
introducing a driver support.

Slark, Muhammad, let me know, which way is more suitable for you.

--
Sergey