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.

Changes since V1:
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!

Changes since V2:
Add supplement of Loic and Slark about some fix

CC: Slark Xiao <slark_xiao@163.com>
CC: Muhammad Nuzaihan <zaihan@unrealasia.net>
CC: Qiang Yu <quic_qianyu@quicinc.com>
CC: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
CC: Johan Hovold <johan@kernel.org>
CC: Sergey Ryazanov <ryazanov.s.a@gmail.com>

Loic Poulain (1):
  net: wwan: prevent premature device unregister when NMEA port is
    present

Sergey Ryazanov (6):
  net: wwan: core: remove unused port_id field
  net: wwan: core: split port creation and registration
  net: wwan: core: split port unregister and stop
  net: wwan: add NMEA port support
  net: wwan: hwsim: refactor to support more port types
  net: wwan: hwsim: support NMEA port emulation

Slark Xiao (1):
  net: wwan: mhi_wwan_ctrl: Add NMEA channel support

 drivers/net/wwan/Kconfig         |   1 +
 drivers/net/wwan/mhi_wwan_ctrl.c |   1 +
 drivers/net/wwan/wwan_core.c     | 248 ++++++++++++++++++++++++++-----
 drivers/net/wwan/wwan_hwsim.c    | 201 ++++++++++++++++++++-----
 include/linux/wwan.h             |   2 +
 5 files changed, 383 insertions(+), 70 deletions(-)

-- 
2.25.1

On 12/31/25 7:51 AM, Slark Xiao 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.
> 
> Changes since V1:
> 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!
> 
> Changes since V2:
> Add supplement of Loic and Slark about some fix
> 
> CC: Slark Xiao <slark_xiao@163.com>
> CC: Muhammad Nuzaihan <zaihan@unrealasia.net>
> CC: Qiang Yu <quic_qianyu@quicinc.com>
> CC: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> CC: Johan Hovold <johan@kernel.org>
> CC: Sergey Ryazanov <ryazanov.s.a@gmail.com>

Uhm... I thingh I already shared the following with you ?!?

## Form letter - net-next-closed

The net-next tree is closed for new drivers, features, code refactoring
and optimizations due to the merge window and the winter break. We are
currently accepting bug fixes only.

Please repost when net-next reopens after Jan 2nd.

RFC patches sent for review only are obviously welcome at any time.

At 2025-12-31 17:06:29, "Paolo Abeni" <pabeni@redhat.com> wrote:
>On 12/31/25 7:51 AM, Slark Xiao 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.
>> 
>> Changes since V1:
>> 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!
>> 
>> Changes since V2:
>> Add supplement of Loic and Slark about some fix
>> 
>> CC: Slark Xiao <slark_xiao@163.com>
>> CC: Muhammad Nuzaihan <zaihan@unrealasia.net>
>> CC: Qiang Yu <quic_qianyu@quicinc.com>
>> CC: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
>> CC: Johan Hovold <johan@kernel.org>
>> CC: Sergey Ryazanov <ryazanov.s.a@gmail.com>
>
>Uhm... I thingh I already shared the following with you ?!?
>
>## Form letter - net-next-closed
>
>The net-next tree is closed for new drivers, features, code refactoring
>and optimizations due to the merge window and the winter break. We are
>currently accepting bug fixes only.
>
>Please repost when net-next reopens after Jan 2nd.
>
>RFC patches sent for review only are obviously welcome at any time.
Yeah, I have received that notice.
Since there is a holiday from Jan 1st to Jan 4th, so I post them to net-next in advance.

You can start to review it after Jan 2nd(according to my previous experience,
maintainer will ignore these patches until the merge window is opened).

Thank you for your notice again.
Happy new year!