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] [thread-next>] [day] [month] [year] [list]
Message-ID: <3c7d38cb.5336.1943f5e66de.Coremail.slark_xiao@163.com>
Date: Tue, 7 Jan 2025 14:05:38 +0800 (CST)
From: "Slark Xiao" <slark_xiao@....com>
To: "Loic Poulain" <loic.poulain@...aro.org>
Cc: "Muhammad Nuzaihan" <zaihan@...ealasia.net>, 
	"Sergey Ryazanov" <ryazanov.s.a@...il.com>, 
	"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:Re: [PATCH net-next v4] wwan dev: Add port for NMEA channel for
 WWAN devices


At 2025-01-07 03:44:35, "Loic Poulain" <loic.poulain@...aro.org> wrote:
>Hi Muhammad,
>
>+ Slark
>
>On Sun, 5 Jan 2025 at 13:53, Muhammad Nuzaihan <zaihan@...ealasia.net> wrote:
>>
>> Based on the code: drivers/bus/mhi/host/pci_generic.c
>> which already has NMEA channel (mhi_quectel_em1xx_channels)
>> support in recent kernels but it is never exposed
>> as a port.
>>
>> This commit exposes that NMEA channel to a port
>> to allow tty/gpsd programs to read through
>> the /dev/wwan0nmea0 port.
>>
>> Tested this change on a new kernel and module
>> built and now NMEA (mhi0_NMEA) statements are
>> available (attached) through /dev/wwan0nmea0 port on bootup.
>>
>> Signed-off-by: Muhammad Nuzaihan Bin Kamal Luddin <zaihan@...ealasia.net>
>
>This works for sure but I'm not entirely convinced NMEA should be
>exposed as a modem control port. In your previous patch version Sergey
>pointed to a discussion we had regarding exposing that port as WWAN
>child device through the regular GNSS subsystem, which would require
>some generic bridge in the WWAN subsystem.
>
>Slark, did you have an opportunity to look at the GNSS solution?
>
>Regards,
>Loic

Hi Loic,
This solution same as what I did in last time. We got a wwan0nmea0 device but this
device can't support flow control.
Also, this is not the solution what Sergey expected, I think. 
Please refer to the target we talked last time:
/////////////////////
>>> Basically, components should interact like this:
>>>
>>> Modem PCIe driver <-> WWAN core <-> GNSS core <-> /dev/gnss0
>>>
>>> We need the GNSS core to export the modem NMEA port as instance of
>>> 'gnss' class.
>>>
>>> We need WWAN core between the modem driver and the GSNN core because we
>>> need a common parent for GNSS port and modem control port (e.g. AT,
>>> MBIM). Since we are already exporting control ports via the WWAN
>>> subsystem, the GNSS port should also be exported through the WWAN
>>> subsystem. To keep devices hierarchy like this:
>>>
>>>                        .--> AT port
>>> PCIe dev -> WWAN dev -|
>>>                        '--> GNSS port
>>>
>>> Back to the implementation. Probably we should introduce a new port
>>> type, e.g. WWAN_PORT_NMEA. And this port type should have a special
>>> handling in the WWAN core.
>>>
>> Similar like what I did in my local. I named it as WWAN_PORT_GNSS and
>> put it as same level with AT port.
>> 
>>> wwan_create_port() function should not directly create a char device.
>>> Instead, it should call gnss_allocate_device() and
>>> gnss_register_device() to register the port with GNSS subsystem.
////////////////////

Thanks

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ