[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <fc1f5d15-163c-49d7-ab94-90e0522b0e57@gmail.com>
Date: Sun, 29 Jun 2025 13:07:57 +0300
From: Sergey Ryazanov <ryazanov.s.a@...il.com>
To: Loic Poulain <loic.poulain@....qualcomm.com>
Cc: Johannes Berg <johannes@...solutions.net>,
Andrew Lunn <andrew+netdev@...n.ch>, Eric Dumazet <edumazet@...gle.com>,
"David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>,
Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
Slark Xiao <slark_xiao@....com>, Muhammad Nuzaihan <zaihan@...ealasia.net>,
Qiang Yu <quic_qianyu@...cinc.com>, Manivannan Sadhasivam <mani@...nel.org>,
Johan Hovold <johan@...nel.org>
Subject: Re: [RFC PATCH v2 0/6] net: wwan: add NMEA port type support
Hi Loic,
On 6/29/25 05:50, Loic Poulain wrote:
> Hi Sergey,
>
> On Tue, Jun 24, 2025 at 11:39 PM Sergey Ryazanov <ryazanov.s.a@...il.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.
Let's wait a month or so and if no actual driver patch going to be send,
then I will resend as formal patch to have the functionality in the
kernel in advance.
--
Sergey
Powered by blists - more mailing lists