| Message ID | R8AFPS.THYVK2DKSEE83@unrealasia.net (mailing list archive) |
|---|---|
| State | Changes Requested |
| Headers | show |
| Series | Add NMEA GPS character device for PCIe MHI Quectel Module to read NMEA statements. | expand |
Hi netdev, I made a mistake in choosing AT mode IPC, which is incorrect. For NMEA streams it should use LOOPBACK for IPC. If it uses AT, i noticed that using gpsd will cause intermittent IOCTL errors which is caused when gpsd wants to write to the device. Attached is the patch. Thank you. Signed-off-by: Muhammad Nuzaihan Bin Kamal Luddin <zaihan@unrealasia.net> On Thu, Jan 2 2025 at 02:34:03 AM +0800, Muhammad Nuzaihan <zaihan@unrealasia.net> wrote: > Hi netdev, > > I am using a Quectel RM520N-GL *PCIe* (not USB) module which uses the > MHI interface. > > In /devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0 i can see > "mhi0_NMEA" but the actual NMEA device is missing in /dev and needs a > character device to be useful with tty programs. > > NMEA statements are a stream of GPS information which is used to tell > the current device location in the console (like minicom). > > Attached is the patch to ensure a device is registered (as > /dev/wwan0nmea0) so this device will stream GPS NMEA statements and > can be used to be read by popular GPS tools like gpsd and then > tracking with cgps, xgps, QGIS, etc. > > Regards, > Muhammad Nuzaihan > > Signed-off-by: Muhammad Nuzaihan Bin Kamal Luddin > <zaihan@unrealasia.net> >
On Thu, Jan 02, 2025 at 05:12:41AM +0800, Muhammad Nuzaihan wrote: > Hi netdev, > > I made a mistake in choosing AT mode IPC, which is incorrect. For NMEA > streams it should use LOOPBACK for IPC. If it uses AT, i noticed that using > gpsd will cause intermittent IOCTL errors which is caused when gpsd wants to > write to the device. > > Attached is the patch. This is not my area, so i cannot do a full review, but a few things to note. Please start a new thread for each version of a patch, and wait at lest 24 hours between each version. The commit message should be formal, since it will be part of the kernel history. https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html > @@ -876,7 +880,8 @@ static long wwan_port_fops_ioctl(struct file *filp, unsigned int cmd, > struct wwan_port *port = filp->private_data; > int res; > > - if (port->type == WWAN_PORT_AT) { /* AT port specific IOCTLs */ > + if (port->type == WWAN_PORT_AT || > + WWAN_PORT_NMEA) { /* AT or NMEA port specific IOCTLs */ This looks wrong. || WWAN_PORT_NMEA will always be true, assuming WWAN_PORT_NMEA is not 0. Andrew --- pw-bot: cr
Hi Andrew, I'm actually new to netdev and the main kernel.org documentation on submitting patches (https://www.kernel.org/doc/html/v4.17/process/submitting-patches.html) was not clear on the commit message (or i've missed it). Thank you for pointing me to the netdev maintainer process page. Anyway, i will make a new v3 patch tomorrow on a new thread to address the issues you mentioned. I'll follow the guidelines as you required. Sorry for the mess. Thank you, Muhammad Nuzaihan On Thu, Jan 2 2025 at 02:22:15 PM +0100, Andrew Lunn <andrew@lunn.ch> wrote: > On Thu, Jan 02, 2025 at 05:12:41AM +0800, Muhammad Nuzaihan wrote: >> Hi netdev, >> >> I made a mistake in choosing AT mode IPC, which is incorrect. For >> NMEA >> streams it should use LOOPBACK for IPC. If it uses AT, i noticed >> that using >> gpsd will cause intermittent IOCTL errors which is caused when gpsd >> wants to >> write to the device. >> >> Attached is the patch. > > This is not my area, so i cannot do a full review, but a few things to > note. > > Please start a new thread for each version of a patch, and wait at > lest 24 hours between each version. > > The commit message should be formal, since it will be part of the > kernel history. > > https://www.kernel.org/doc/html/latest/process/maintainer-netdev.html > >> @@ -876,7 +880,8 @@ static long wwan_port_fops_ioctl(struct file >> *filp, unsigned int cmd, >> struct wwan_port *port = filp->private_data; >> int res; >> >> - if (port->type == WWAN_PORT_AT) { /* AT port specific IOCTLs */ >> + if (port->type == WWAN_PORT_AT || >> + WWAN_PORT_NMEA) { /* AT or NMEA port specific IOCTLs */ > > This looks wrong. || WWAN_PORT_NMEA will always be true, assuming > WWAN_PORT_NMEA is not 0. > > Andrew > > --- > pw-bot: cr
Hi Muhammad and welcome to netdev, On 01.01.2025 23:12, Muhammad Nuzaihan wrote: > Hi netdev, > > I made a mistake in choosing AT mode IPC, which is incorrect. For NMEA > streams it should use LOOPBACK for IPC. If it uses AT, i noticed that > using gpsd will cause intermittent IOCTL errors which is caused when > gpsd wants to write to the device. > > Attached is the patch. Do you had a chance to check this discussion: https://lore.kernel.org/all/CAMZdPi_MF=-AjTaBZ_HxtwpbQK5+WwR9eXsSvnvK_-O30ff+Tw@mail.gmail.com/ To summarize, an NMEA port suppose to be exported through the GNSS subsystem to properly indicate the device class. Still, the port needs to be exported through the WWAN subsystem to facilitate a corresponding control port discovery. Looks like that the WWAN changes going to be a bit more tricky. > Thank you. > > Signed-off-by: Muhammad Nuzaihan Bin Kamal Luddin <zaihan@unrealasia.net> > > On Thu, Jan 2 2025 at 02:34:03 AM +0800, Muhammad Nuzaihan > <zaihan@unrealasia.net> wrote: >> Hi netdev, >> >> I am using a Quectel RM520N-GL *PCIe* (not USB) module which uses the >> MHI interface. >> >> In /devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0 i can see >> "mhi0_NMEA" but the actual NMEA device is missing in /dev and needs a >> character device to be useful with tty programs. >> >> NMEA statements are a stream of GPS information which is used to tell >> the current device location in the console (like minicom). >> >> Attached is the patch to ensure a device is registered (as /dev/ >> wwan0nmea0) so this device will stream GPS NMEA statements and can be >> used to be read by popular GPS tools like gpsd and then tracking with >> cgps, xgps, QGIS, etc. >> >> Regards, >> Muhammad Nuzaihan >> >> Signed-off-by: Muhammad Nuzaihan Bin Kamal Luddin <zaihan@unrealasia.net> >> >
Hi Sergey, So there is a separate GNSS subsystem in the linux kernel. I'll check that out. I went through a bit of research to get this working. Went to quectel forums to figure out and quectel has their own set of drivers. They showed me their own source code and they have their own implementation of their NMEA interface in their driver with port at /dev/mhi_LOOPBACK. But i was not quite happy because i have to use their connection manager instead of ModemManager since i am using it for my Lenovo laptop and not embedded which their software was designed for. Went around /sys in the kernel and found: root@muhammads-ThinkPad:/sys# find . -name 'mhi0*' ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0 ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0/mhi0_DIAG ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0/mhi0_IP_HW0_MBIM ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0/mhi0_MBIM ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0/mhi0_NMEA ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0/mhi0_DUN ./bus/mhi/devices/mhi0 ./bus/mhi/devices/mhi0_DIAG ./bus/mhi/devices/mhi0_IP_HW0_MBIM ./bus/mhi/devices/mhi0_MBIM ./bus/mhi/devices/mhi0_NMEA ./bus/mhi/devices/mhi0_DUN ./bus/mhi/drivers/mhi_wwan_mbim/mhi0_IP_HW0_MBIM ./bus/mhi/drivers/mhi_wwan_ctrl/mhi0_DIAG ./bus/mhi/drivers/mhi_wwan_ctrl/mhi0_MBIM ./bus/mhi/drivers/mhi_wwan_ctrl/mhi0_NMEA ./bus/mhi/drivers/mhi_wwan_ctrl/mhi0_DUN So i figured it has mhi0_NMEA and that's how i thought of writing the patch to expose mhi0_NMEA after reading some linaro guy's presentation on MHI and his initial mhi0_QMI work with ModemManager. With my patch, on bootup, it doesn't automatically attach nmea0 port at all, 5G works properly with modemmanager at boot but no nmea port. To get that nmea0 port i had to unload all mhi_* and wwan modules and load them back again to ensure wwan0nmea0 gets attached to /dev. After that i run commands with quectel's own AT commands at wwan0at0 with AT+QGPS+1 and then AT+QGPSGNMEA="RMC" (also AT+QGPSCFG="outport",usbnmea) and this starts the streaming of the NMEA gps statements. If i don't run the AT commands, even 5G connectivity with modemmananager do not work as well. After running it, all NMEA streams starts to come and 5G connectivity works. After that i would only run gpsd to read /dev/wwan0nmea0 (the port can only be use/locked by one program) and run cgps (client gps) to make nmea values more easier to read. All this is stable, i have been running "cgps" program for hours together with 5g on modemmanager and no issues. Just the above quirks about unloading and loading of kernel modules and running AT commands (i wrote a shell script to automate this) I can try to help out as much as i can. NMEA continous stream --- Welcome to minicom 2.8 OPTIONS: I18n Port /dev/wwan0nmea0, 22:50:48 Press CTRL-A Z for help on special keys $GPRMC,172551.00,A,0607.736155,N,10217.012565,E,0.0,,020125,0.4,W,A,V*74 $GPRMC,172552.00,A,0607.736156,N,10217.012566,E,0.0,,020125,0.4,W,A,V*77 $GPGGA,172553.00,0607.736156,N,10217.012566,E,1,07,0.4,15.0,M,-7.3,M,,*47 $GPRMC,172553.00,A,0607.736156,N,10217.012566,E,0.0,,020125,0.4,W,A,V*76 $GPGGA,172554.00,0607.736157,N,10217.012567,E,1,07,0.4,15.0,M,-7.3,M,,*40 $GPRMC,172554.00,A,0607.736157,N,10217.012567,E,0.0,,020125,0.4,W,A,V*71 ... continuously Regards, Zaihan On Thu, Jan 2 2025 at 07:18:46 PM +0200, Sergey Ryazanov <ryazanov.s.a@gmail.com> wrote: > Hi Muhammad and welcome to netdev, > > On 01.01.2025 23:12, Muhammad Nuzaihan wrote: >> Hi netdev, >> >> I made a mistake in choosing AT mode IPC, which is incorrect. For >> NMEA streams it should use LOOPBACK for IPC. If it uses AT, i >> noticed that using gpsd will cause intermittent IOCTL errors which >> is caused when gpsd wants to write to the device. >> >> Attached is the patch. > > Do you had a chance to check this discussion: > https://lore.kernel.org/all/CAMZdPi_MF=-AjTaBZ_HxtwpbQK5+WwR9eXsSvnvK_-O30ff+Tw@mail.gmail.com/ > > To summarize, an NMEA port suppose to be exported through the GNSS > subsystem to properly indicate the device class. Still, the port > needs to be exported through the WWAN subsystem to facilitate a > corresponding control port discovery. Looks like that the WWAN > changes going to be a bit more tricky. > >> Thank you. >> >> Signed-off-by: Muhammad Nuzaihan Bin Kamal Luddin >> <zaihan@unrealasia.net> >> >> On Thu, Jan 2 2025 at 02:34:03 AM +0800, Muhammad Nuzaihan >> <zaihan@unrealasia.net> wrote: >>> Hi netdev, >>> >>> I am using a Quectel RM520N-GL *PCIe* (not USB) module which uses >>> the MHI interface. >>> >>> In /devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0 i can see >>> "mhi0_NMEA" but the actual NMEA device is missing in /dev and >>> needs a character device to be useful with tty programs. >>> >>> NMEA statements are a stream of GPS information which is used to >>> tell the current device location in the console (like minicom). >>> >>> Attached is the patch to ensure a device is registered (as /dev/ >>> wwan0nmea0) so this device will stream GPS NMEA statements and >>> can be used to be read by popular GPS tools like gpsd and then >>> tracking with cgps, xgps, QGIS, etc. >>> >>> Regards, >>> Muhammad Nuzaihan >>> >>> Signed-off-by: Muhammad Nuzaihan Bin Kamal Luddin >>> <zaihan@unrealasia.net> >>> >> >
Hi Sergey, On Fri, Jan 3 2025 at 02:05:19 AM +0800, Muhammad Nuzaihan <zaihan@unrealasia.net> wrote: > Hi Sergey, > > So there is a separate GNSS subsystem in the linux kernel. I'll check > that out. > > I went through a bit of research to get this working. Went to quectel > forums to figure out and quectel has their own set of drivers. They > showed me their own source code and they have their own > implementation of their NMEA interface in their driver with port at > /dev/mhi_LOOPBACK. > > But i was not quite happy because i have to use their connection > manager instead of ModemManager since i am using it for my Lenovo > laptop and not embedded which their software was designed for. > > Went around /sys in the kernel and found: > > root@muhammads-ThinkPad:/sys# find . -name 'mhi0*' > ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0 > ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0/mhi0_DIAG > ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0/mhi0_IP_HW0_MBIM > ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0/mhi0_MBIM > ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0/mhi0_NMEA > ./devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0/mhi0_DUN > ./bus/mhi/devices/mhi0 > ./bus/mhi/devices/mhi0_DIAG > ./bus/mhi/devices/mhi0_IP_HW0_MBIM > ./bus/mhi/devices/mhi0_MBIM > ./bus/mhi/devices/mhi0_NMEA > ./bus/mhi/devices/mhi0_DUN > ./bus/mhi/drivers/mhi_wwan_mbim/mhi0_IP_HW0_MBIM > ./bus/mhi/drivers/mhi_wwan_ctrl/mhi0_DIAG > ./bus/mhi/drivers/mhi_wwan_ctrl/mhi0_MBIM > ./bus/mhi/drivers/mhi_wwan_ctrl/mhi0_NMEA > ./bus/mhi/drivers/mhi_wwan_ctrl/mhi0_DUN > > So i figured it has mhi0_NMEA and that's how i thought of writing the > patch to expose mhi0_NMEA after reading some linaro guy's > presentation on MHI and his initial mhi0_QMI work with ModemManager. The Linaro guy was Loic! Thank you. :) - https://static.linaro.org/connect/lvc21/presentations/lvc21-317.pdf > > With my patch, on bootup, it doesn't automatically attach nmea0 port > at all, 5G works properly with modemmanager at boot but no nmea port. > > To get that nmea0 port i had to unload all mhi_* and wwan modules and > load them back again to ensure wwan0nmea0 gets attached to /dev. > > After that i run commands with quectel's own AT commands at wwan0at0 > with AT+QGPS+1 and then AT+QGPSGNMEA="RMC" (also > AT+QGPSCFG="outport",usbnmea) and this starts the streaming of the > NMEA gps statements. If i don't run the AT commands, even 5G > connectivity with modemmananager do not work as well. After running > it, all NMEA streams starts to come and 5G connectivity works. > > After that i would only run gpsd to read /dev/wwan0nmea0 (the port > can only be use/locked by one program) and run cgps (client gps) to > make nmea values more easier to read. > > All this is stable, i have been running "cgps" program for hours > together with 5g on modemmanager and no issues. Just the above quirks > about unloading and loading of kernel modules and running AT commands > (i wrote a shell script to automate this) > > I can try to help out as much as i can. > > NMEA continous stream > --- > > Welcome to minicom 2.8 > > OPTIONS: I18n > Port /dev/wwan0nmea0, 22:50:48 > > Press CTRL-A Z for help on special keys > > $GPRMC,172551.00,A,0607.736155,N,10217.012565,E,0.0,,020125,0.4,W,A,V*74 > $GPRMC,172552.00,A,0607.736156,N,10217.012566,E,0.0,,020125,0.4,W,A,V*77 > $GPGGA,172553.00,0607.736156,N,10217.012566,E,1,07,0.4,15.0,M,-7.3,M,,*47 > $GPRMC,172553.00,A,0607.736156,N,10217.012566,E,0.0,,020125,0.4,W,A,V*76 > $GPGGA,172554.00,0607.736157,N,10217.012567,E,1,07,0.4,15.0,M,-7.3,M,,*40 > $GPRMC,172554.00,A,0607.736157,N,10217.012567,E,0.0,,020125,0.4,W,A,V*71 > ... continuously > > > Regards, > Zaihan > > On Thu, Jan 2 2025 at 07:18:46 PM +0200, Sergey Ryazanov > <ryazanov.s.a@gmail.com> wrote: >> Hi Muhammad and welcome to netdev, >> >> On 01.01.2025 23:12, Muhammad Nuzaihan wrote: >>> Hi netdev, >>> >>> I made a mistake in choosing AT mode IPC, which is incorrect. For >>> NMEA streams it should use LOOPBACK for IPC. If it uses AT, i >>> noticed that using gpsd will cause intermittent IOCTL errors >>> which is caused when gpsd wants to write to the device. >>> >>> Attached is the patch. >> >> Do you had a chance to check this discussion: >> https://lore.kernel.org/all/CAMZdPi_MF=-AjTaBZ_HxtwpbQK5+WwR9eXsSvnvK_-O30ff+Tw@mail.gmail.com/ >> >> I've read the discussion. Interesting that I had that i had the same thought of using AT interface to communicate with the NMEA. There was a question about NMEA with MHI, not sure if what i did is identical to Slark's idea. >> To summarize, an NMEA port suppose to be exported through the GNSS >> subsystem to properly indicate the device class. Still, the port >> needs to be exported through the WWAN subsystem to facilitate a >> corresponding control port discovery. Looks like that the WWAN >> changes going to be a bit more tricky. >> Read about the GNSS subsystem, some really old article but it sounded it doesn't support all devices (and it only support dedicated GPS devices), not sure if there are improvements after that. Should we be focusing on WWAN would be appropriate rather than duplicating work with GNSS? The part that i am unsure is whether the MHI NMEA implementation i have currently supports features like showing a map of satellites like normal GPS hardware with Linux GNSS would and i don't see yet in my data. Just for the start is to get the data like altitude, speed, mean sea level, climb rate, time, lat/lng - which i got. I'll try to improve on my patches and see how i can load and fix the issues i encountered earlier. >> >>> Thank you. >>> >>> Signed-off-by: Muhammad Nuzaihan Bin Kamal Luddin >>> <zaihan@unrealasia.net> >>> >>> On Thu, Jan 2 2025 at 02:34:03 AM +0800, Muhammad Nuzaihan >>> <zaihan@unrealasia.net> wrote: >>>> Hi netdev, >>>> >>>> I am using a Quectel RM520N-GL *PCIe* (not USB) module which uses >>>> the MHI interface. >>>> >>>> In /devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0 i can see >>>> "mhi0_NMEA" but the actual NMEA device is missing in /dev and >>>> needs a character device to be useful with tty programs. >>>> >>>> NMEA statements are a stream of GPS information which is used to >>>> tell the current device location in the console (like >>>> minicom). >>>> >>>> Attached is the patch to ensure a device is registered (as /dev/ >>>> wwan0nmea0) so this device will stream GPS NMEA statements >>>> and can be used to be read by popular GPS tools like gpsd and >>>> then tracking with cgps, xgps, QGIS, etc. >>>> >>>> Regards, >>>> Muhammad Nuzaihan >>>> >>>> Signed-off-by: Muhammad Nuzaihan Bin Kamal Luddin >>>> <zaihan@unrealasia.net> >>>> >>> >>
Hi Sergey,
Apparently after a new recompilation the entire kernel and modules
fixes the problem with wwan0nmea0 port get attached at bootup. I had
previously only compiled modules without the kernel during development.
Before that i went to debug several wwan_core.c device wwan_create_port
and wwan_create_dev functions to see what's going on not being loaded
at bootup and seemed that a recompile the entire kernel and module
fixes that. Checked my diffs and saw no changes.
So now, everything works perfectly at bootup and I have to tell
ModemManager to ignore NMEA port type. So booting up with a fresh new
kernel and module gets my 5G working automatically at boot.
No need to unload and reload of the kernel modules and configuring with
AT commands to wwan0at0 with scripts, now everything works seamlessly.
So to ensure ModemManager can work with this setup, i would add a new
udev rule for ModemManager to not probe wwan0nmea0 port (which i think
i will submit this to ModemManger project):
# ModemManager ignore NMEA
ATTRS{vendor}=="0x1eac", ATTRS{device}=="0x1007", ATTR{type}=="NMEA",
ENV{ID_MM_PORT_IGNORE}="1"
I'll submit the "cleaned up" v3 nmea patch later tomorrow, it's a
pretty small patch. (It's 12AM now here in Malaysia)
- Zaihan
On Fri, Jan 3 2025 at 03:15:34 AM +0800, Muhammad Nuzaihan
<zaihan@unrealasia.net> wrote:
> Hi Sergey,
>
>
> On Fri, Jan 3 2025 at 02:05:19 AM +0800, Muhammad Nuzaihan
> <zaihan@unrealasia.net> wrote:
>> Hi Sergey,
>>
diff --git a/drivers/net/wwan/iosm/iosm_ipc_chnl_cfg.c b/drivers/net/wwan/iosm/iosm_ipc_chnl_cfg.c index bcfbc6b3d617..4d4fc3813c86 100644 --- a/drivers/net/wwan/iosm/iosm_ipc_chnl_cfg.c +++ b/drivers/net/wwan/iosm/iosm_ipc_chnl_cfg.c @@ -60,6 +60,10 @@ static struct ipc_chnl_cfg modem_cfg[] = { { IPC_MEM_CTRL_CHL_ID_6, IPC_MEM_PIPE_12, IPC_MEM_PIPE_13, IPC_MEM_MAX_TDS_MBIM, IPC_MEM_MAX_TDS_MBIM, IPC_MEM_MAX_DL_MBIM_BUF_SIZE, WWAN_PORT_MBIM }, + /* NMEA */ + { IPC_MEM_CTRL_CHL_ID_7, IPC_MEM_PIPE_14, IPC_MEM_PIPE_15, + IPC_MEM_MAX_TDS_AT, IPC_MEM_MAX_TDS_AT, IPC_MEM_MAX_DL_AT_BUF_SIZE, + WWAN_PORT_NMEA }, /* Flash Channel/Coredump Channel */ { IPC_MEM_CTRL_CHL_ID_7, IPC_MEM_PIPE_0, IPC_MEM_PIPE_1, IPC_MEM_MAX_TDS_FLASH_UL, IPC_MEM_MAX_TDS_FLASH_DL, diff --git a/drivers/net/wwan/mhi_wwan_ctrl.c b/drivers/net/wwan/mhi_wwan_ctrl.c index e9f979d2d851..e13c0b078175 100644 --- a/drivers/net/wwan/mhi_wwan_ctrl.c +++ b/drivers/net/wwan/mhi_wwan_ctrl.c @@ -263,6 +263,7 @@ static const struct mhi_device_id mhi_wwan_ctrl_match_table[] = { { .chan = "QMI", .driver_data = WWAN_PORT_QMI }, { .chan = "DIAG", .driver_data = WWAN_PORT_QCDM }, { .chan = "FIREHOSE", .driver_data = WWAN_PORT_FIREHOSE }, + { .chan = "NMEA", .driver_data = WWAN_PORT_NMEA }, {}, }; MODULE_DEVICE_TABLE(mhi, mhi_wwan_ctrl_match_table); diff --git a/drivers/net/wwan/wwan_core.c b/drivers/net/wwan/wwan_core.c index a51e2755991a..0131d9795d6c 100644 --- a/drivers/net/wwan/wwan_core.c +++ b/drivers/net/wwan/wwan_core.c @@ -342,6 +342,10 @@ static const struct { .name = "MIPC", .devsuf = "mipc", }, + [WWAN_PORT_NMEA] = { + .name = "NMEA", + .devsuf = "nmea", + }, }; static ssize_t type_show(struct device *dev, struct device_attribute *attr, @@ -876,7 +880,8 @@ static long wwan_port_fops_ioctl(struct file *filp, unsigned int cmd, struct wwan_port *port = filp->private_data; int res; - if (port->type == WWAN_PORT_AT) { /* AT port specific IOCTLs */ + if (port->type == WWAN_PORT_AT || + WWAN_PORT_NMEA) { /* AT or NMEA port specific IOCTLs */ res = wwan_port_fops_at_ioctl(port, cmd, arg); if (res != -ENOIOCTLCMD) return res; diff --git a/include/linux/wwan.h b/include/linux/wwan.h index 79c781875c09..9e794fc53a7e 100644 --- a/include/linux/wwan.h +++ b/include/linux/wwan.h @@ -19,6 +19,7 @@ * @WWAN_PORT_FASTBOOT: Fastboot protocol control * @WWAN_PORT_ADB: ADB protocol control * @WWAN_PORT_MIPC: MTK MIPC diagnostic interface + * @WWAN_PORT_NMEA: NMEA GPS statements interface * * @WWAN_PORT_MAX: Highest supported port types * @WWAN_PORT_UNKNOWN: Special value to indicate an unknown port type @@ -34,6 +35,7 @@ enum wwan_port_type { WWAN_PORT_FASTBOOT, WWAN_PORT_ADB, WWAN_PORT_MIPC, + WWAN_PORT_NMEA, /* Add new port types above this line */
Hi netdev, I am using a Quectel RM520N-GL *PCIe* (not USB) module which uses the MHI interface. In /devices/pci0000:00/0000:00:1c.6/0000:08:00.0/mhi0 i can see "mhi0_NMEA" but the actual NMEA device is missing in /dev and needs a character device to be useful with tty programs. NMEA statements are a stream of GPS information which is used to tell the current device location in the console (like minicom). Attached is the patch to ensure a device is registered (as /dev/wwan0nmea0) so this device will stream GPS NMEA statements and can be used to be read by popular GPS tools like gpsd and then tracking with cgps, xgps, QGIS, etc. Regards, Muhammad Nuzaihan Signed-off-by: Muhammad Nuzaihan Bin Kamal Luddin <zaihan@unrealasia.net>