linux-kernel - Re: [RFC v4] wwan dev: Add port for NMEA channel for WWAN devices

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

Message-Id: <EAIRPS.ENVJYU16CN9C3@unrealasia.net>
Date: Wed, 08 Jan 2025 16:59:02 +0800
From: Muhammad Nuzaihan <zaihan@...ealasia.net>
To: Sergey Ryazanov <ryazanov.s.a@...il.com>
Cc: Slark Xiao <slark_xiao@....com>, Loic Poulain <loic.poulain@...aro.org>,
	Johannes Berg <johannes@...solutions.net>, Andrew Lunn
	<andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>,
	Eric Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>,
	Paolo Abeni <pabeni@...hat.com>, netdev@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC v4] wwan dev: Add port for NMEA channel for WWAN devices

Hi Sergey,

On Wed, Jan 8 2025 at 01:42:00 AM +0200, Sergey Ryazanov 
<ryazanov.s.a@...il.com> wrote:
> Hi Muhammad, Slark,
> 
> I should clarify here a bit. Export through GNSS does not mean 
> creating a dedicated PCI driver. It means call the 
> gnss_register_device() function to export the device to the user 
> space as instance of the GNSS class. This should help for 
> ModemManager as well to avoid the NMEA port access. Since the device 
> class will clearly indicate that the NMEA port has nothing common 
> with a cell modem control.

Yes, after reading Slark's email, i began to understand the 
requirements and i agree with your explanation since I use ModemManager 
and support for PCIe devices with MHI seems lacking in ModemManager 
compared to USB based WWAN devices because of the issue above.

I did not try to create a dedicated PCI driver, after looking at the 
code i was trying to allocate the device from the parent driver. Which 
didn't work.

Unlike most other use-case in IoT and Embedded, my use case is more for 
Desktop usage where interaction with ModemManager is important.

> 
> Still, as it was pointed by Loic, it is a good idea to call 
> gnss_register_device() from WWAN core in order to make the WWAN 
> device a common parent of the NMEA port. This should help user space 
> applications as well. A user space application (e.g. GPSd) can easily 
> find a control AT/MBIM/etc port to activate the GNSS functionality of 
> the physical device by checking the NMEA port siblings.

Which is what my patch was trying to achieve in wwan_core.c - with the 
wwan_create_port() function with this code.

+        /* NMEA check to attach GNSS port */
+        if (type == WWAN_PORT_NMEA) {
+                struct gnss_device *gdev = 
gnss_allocate_device(parent);
+
+                if (gdev)
+                        gnss_register_device(gdev);
+        }

This was what was suggested in the email by Slark. Maybe i am missing 
something. Do i need to allocate the gnss device with 
gnss_allocate_device()?

I see from gnss code that i need a "gnss_device" to be able to register.

Also this is a just a tip of the iceberg, i would have to look at 
deregistering the device - removal as well, along the way

> 
>> But the patch i'm giving does not work. (NULL deference err,
>> possibly due to gdev being NULL).
>> 
>> Just sharing on some progress i've made.
> 
> A small hint. If a patch is not going to be merged here and now, it's 
> good idea put "RFC" keyword in the subject. E.g.:
> 
> [RFC v4] wwan dev: Add port for NMEA channel for WWAN devices

Will do.
> 
> And another small hint. Use the bottom/inline posting style please. 
> It's really hard to read the email conversation backward.

Sorry about that, i'll follow the list etiquette from now on.
> 
>> I'm still looking at it and trying to figure out though.
> 
> It will be great if you will manage to create the discussed 
> infrastructure inside the WWAN core code. I've already promised Slark 
> to make a prototype, but have a hard time to find a time to do it 
> properly. Sorry :(

You mean a new function to pass the parent device, allocate and 
register?

Tried:

Modem PCIe driver <-> WWAN core <-> GNSS core <-> /dev/gnss0

I can work on this but i would need some guidance on what needs to be 
done. The gnss patch above i did was all the understanding i had with 
what Slark mentioned in this email. The gnss patch did try to 
initialize gnss in dmesg but it just crashes. No /dev/gnss0 device.

Eventhough it's not that urgent for me because i still can read gps 
data on the current setup but i hope to implement this for sake of 
completeness since USB WWAN support with GPS is already well supported 
with ModemManager. (mmcli CLI for GPS subcommands gets error all the 
time for my PCIe device but that problem's specific to ModemManager)

and since i have the hardware, so why not i try to implement to support 
it. ;-)

I think i'll figure something out. :-)

> 
>> On Tue, Jan 7 2025 at 02:05:38 PM +0800, Slark Xiao 
>> <slark_xiao@....com> wrote:
>>> 
>>> At 2025-01-07 03:44:35, "Loic Poulain" <loic.poulain@...aro.org> 
>>> wrote:
>>>> Hi Muhammad,
>>>> 
>>>> + Slark