Hi Slark,

On 9/11/25 05:42, Slark Xiao wrote:

At 2025-06-30 15:30:14, "Loic Poulain" [off-list ref] wrote:

quoted

On Sun, Jun 29, 2025 at 12:07 PM Sergey Ryazanov [off-list ref] wrote:

quoted

On 6/29/25 05:50, Loic Poulain wrote:

quoted

On Tue, Jun 24, 2025 at 11:39 PM Sergey Ryazanov [off-list ref] wrote:

quoted

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