- kernelnewbies@kernelnewbies.org - Kernelnewbies Mailing Lists

Help figuring out how to associate a device with GNSS subsystem (gnss_* modules)
by John Scott Jan. 20, 2026

Jan. 20, 2026

Hello, I'm trying to figure out how to use the kernel's GNSS subsystem to create device nodes such as /dev/gnss0 on a conventional (non-embedded) system. Some information from the author about the subsystem is at https://events19.linuxfoundation.org/wp-content/uploads/2017/12/The-GNSS-Su… GNSS receivers usually use a serial interface to send geolocation information to a host in a text format known informally as NMEA-0183. The hardware I have is an Adafruit Ultimate GPS (MediaTek MT3333) with a bundled USB serial converter (Silicon Labs CP2102N) so that the device can be plugged into a computer with USB. At https://cdn-shop.adafruit.com/product-files/1059/CD+PA1616D+Datasheet+v.05.… is a detailed description. I have been using it without the GNSS subsystem, just accessing the TTY in user-space applications like gpsd and GeoClue. Enumerating serial devices is notoriously difficult in general, but I'm lucky that the serial converter has a manufacturer's serial number baked in so I can reliably detect device insertion with a udev rule like this: SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", ATTRS{serial}=="0e30054dff9fec11a7ec8fcfa29c855c", ... I can use such a udev rule to match the hardware or start a service if I want, but without such a rule and out-of-the-box, the cp210x kernel driver gets loaded for this family of USB-serial converters, and the GNSS receiver is accessible at /dev/ttyUSB0 for example. Then I can read from the device to my heart's content. What's confusing me, however, is how to tell the appropriate GNSS kernel module(s) about this device so they can offer advanced features. (For example, some GNSS receivers such as MediaTek's allow changing the serial baud rate on-the-fly using a special command. It's conceivable that a MediaTek GNSS driver would take care of this negotiation if a user application does 'stty 115200', say.) There are Devicetree properties recognized by the kernel for setting up GNSS device nodes, but I'm using an ordinary x86_64 PC at the moment which doesn't use Devicetree at all. The USB vendor/product ID is for the generic serial converter, and I would like to use a udev rule or something similar with "smarts" to use my device's serial number for intelligent identification. There are a couple kernel modules to this subsystem: • gnss • gnss-mtk (depends on gnss-serial) • gnss-serial (depends on gnss) • gnss-usb (depends on gnss) Technically gnss-mtk is the most specialized to my device; this is for MediaTek receivers. I think gnss-usb is for a non-TTY-type device that sends and receives the NMEA-0183 data from the USB endpoint descriptors directly, so I *think* it's irrelevant for me. In particular, the cp210x driver does a great job with the serial converter and exposing the USB serial converter as a TTY, so I guess gnss-mtk (and transitively gnss-serial) is supposed to "wrap" around the TTY device. The USB device is probably useless without cp210x because otherwise there'd be no way to know how to talk to the converter. There is a teeny bit of information at https://docs.kernel.org/admin-guide/abi-testing.html#abi-sys-class-gnss-gns… that shows sysfs nodes for devices should look like "/sys/class/gnss/gnss<N>". We shouldn't have to worry about setting the 'type' parameter described there because it's implicit in the use of gnss-mtk. As suggested at https://lwn.net/Articles/143397/ my serial adapter gets exposed as /dev/char/188:0, so I tried doing this: # printf '188:0' > /sys/bus/serial/drivers/gnss-mtk/bind but I get "No such device". Also, that LWN article is only using USB devices in its example and it's not obvious what syntax I would use for a serial device anyway. It also says that the device should not be bound to any driver already, but we need gnss-mtk to "wrap" around the serial converter's own driver so this is very tricky... I also looked in /sys/class/gnss/ for clues but that directory is empty. It looks like in drivers/gnss/core.c there is a gnss_allocate_device() function that creates device nodes and assigns them names. In summary, how do I actually use this subsystem? Is Devicetree the only way to set this up? Thanks

1 0

Re: [PATCH 0/2] UIO: Optional custom threaded IRQ handler
by Greg KH Jan. 5, 2026

Jan. 5, 2026

On Mon, Jan 05, 2026 at 01:29:53PM +0100, Kevin Bube wrote: > Greg KH <gregkh(a)linuxfoundation.org> writes: > > On Mon, Jan 05, 2026 at 11:21:48AM +0100, Kevin Bube wrote: > >> Greg KH <gregkh(a)linuxfoundation.org> writes: > >> > On Sat, Jan 03, 2026 at 09:06:29PM +0100, Kevin Bube wrote: > >> >> Add an optional threaded IRQ handler to the generic UIO driver. This allows > >> >> driver developers to keep the fast IRQ handler small and move tasks to the IRQ > >> >> thread. We also update the documentation accordingly. > >> >> > >> >> Kevin Bube (2): > >> >> UIO: Add optional IRQ thread callback > >> >> Documentation: Document threaded IRQ handler for UIO > >> >> > >> >> Documentation/driver-api/uio-howto.rst | 8 ++++++++ > >> >> drivers/uio/uio.c | 6 +++++- > >> >> include/linux/uio_driver.h | 2 ++ > >> >> 3 files changed, 15 insertions(+), 1 deletion(-) > >> > > >> > But as no in-kernel driver now uses this, it will just be removed again > >> > :( > >> > > >> > Please always provide real users for api changes, otherwise we can't > >> > determine if they are actually working or not. > >> > >> I see. Thanks for taking a look. > > > > How was this tested if you don't have an actual user for it? Why add it > > if you don't have a user for it? > > We have special hardware with a FPGA that requires its own customized > driver at my dayjob. While the driver is GPL, the FPGA image is not (not > my decision). So it makes little sense to include the driver in > mainline. There's no reason not to include it, so why not submit it? > The patch is just a part of the whole change we make for our device. I > sent it because I think it may be useful for others, too. But I > understand that it is bad to add an API without knowing its users and > not being able to test it. My misunderstanding was that the generic UIO > driver is more of a framework to derive custom drivers. We can't ever support out-of-tree drivers for obvious reasons, so just submit your driver and then it should be fine. thanks, greg k-h

1 0

Re: [PATCH 0/2] UIO: Optional custom threaded IRQ handler
by Greg KH Jan. 5, 2026

Jan. 5, 2026

On Mon, Jan 05, 2026 at 11:21:48AM +0100, Kevin Bube wrote: > Greg KH <gregkh(a)linuxfoundation.org> writes: > > On Sat, Jan 03, 2026 at 09:06:29PM +0100, Kevin Bube wrote: > >> Add an optional threaded IRQ handler to the generic UIO driver. This allows > >> driver developers to keep the fast IRQ handler small and move tasks to the IRQ > >> thread. We also update the documentation accordingly. > >> > >> Kevin Bube (2): > >> UIO: Add optional IRQ thread callback > >> Documentation: Document threaded IRQ handler for UIO > >> > >> Documentation/driver-api/uio-howto.rst | 8 ++++++++ > >> drivers/uio/uio.c | 6 +++++- > >> include/linux/uio_driver.h | 2 ++ > >> 3 files changed, 15 insertions(+), 1 deletion(-) > > > > But as no in-kernel driver now uses this, it will just be removed again > > :( > > > > Please always provide real users for api changes, otherwise we can't > > determine if they are actually working or not. > > I see. Thanks for taking a look. How was this tested if you don't have an actual user for it? Why add it if you don't have a user for it? confused, greg k-h

1 0

Re: [PATCH 0/2] UIO: Optional custom threaded IRQ handler
by Greg KH Jan. 4, 2026

Jan. 4, 2026

On Sat, Jan 03, 2026 at 09:06:29PM +0100, Kevin Bube wrote: > Add an optional threaded IRQ handler to the generic UIO driver. This allows > driver developers to keep the fast IRQ handler small and move tasks to the IRQ > thread. We also update the documentation accordingly. > > Kevin Bube (2): > UIO: Add optional IRQ thread callback > Documentation: Document threaded IRQ handler for UIO > > Documentation/driver-api/uio-howto.rst | 8 ++++++++ > drivers/uio/uio.c | 6 +++++- > include/linux/uio_driver.h | 2 ++ > 3 files changed, 15 insertions(+), 1 deletion(-) But as no in-kernel driver now uses this, it will just be removed again :( Please always provide real users for api changes, otherwise we can't determine if they are actually working or not. thanks, greg k-h

1 0

post
by laughing lucky Dec. 20, 2025

Dec. 20, 2025

2 2

Development environment discussion
by Isaac Gonzalez Dec. 18, 2025

Dec. 18, 2025

Hello everyone, I'm new posting to the newbies kernel list and currently learning kernel driver and subsystem development. I am considering working on a Macbook air with virtual machines for my learning and experimentation process. Is it reasonable or would it be better to consider native development, especially while working remotely? I plan to use the macbook as a remote development environment with tools to work on code inside virtual machines and remotely (ssh) to a desktop with Ubuntu 24. It has been cumbersome getting the kernel to build due to configurations in Ubuntu for certificates which do not exist in the mainline kernel so any suggestions on any other host OS are appreciated. I have no issues switching between distributions and consider it a great part of the development learning process. Thanks, Isaac Gonzalez

5 6

Query: Y2038 patch series for 3.18 Kernel
by Pintu Kumar Agarwal Dec. 17, 2025

Dec. 17, 2025

Hi, We have an arm32 based embedded product which is based on the 3.18 kernel and a simple busybox. We wanted to support the Y2038 issue on this older kernel. Is this feasible Do we have the Y2038 separate patches available for both kernel and userspace ? Or upgrading the kernel is the only option ? Thanks, Pintu

4 7

Hello form a new Kernel contributor
by Pavan Kumar Yalagada Nov. 20, 2025

Nov. 20, 2025

Hi everyone, My name is Pavan Kumar Yalagada. I am starting to learn Linux Kernel development and plan to submit my first small patch soon. Currently, I am reading "Linux Kernel Development" by Robert Love to better understand kernel internals. I would appreciate any guidance or advice for a beginner like me. Thanks, Pavan

2 1

Rust: how to implement file_operations for a misc device?
by Fabio Nov. 20, 2025

Nov. 20, 2025

Hello, brand-new kernel newbie here. I'm interested in the Rust side of the kernel. To get acquainted, I'm following the Linux Driver Development book, 3rd edition, also integrating it with modern documentation and best practices (or at least I hope so). I'm developing the scull module on top of the `kernel::miscdevice::MiscDevice` trait. Where I'm stuck at is the lack of the `kernel::file::Operations` trait [1], that most online resources refer to. I need such trait to implement read and write operations for the misc device. AFAIU, this trait used to exist but it's no longer in the mainline codebase [2]. Also, `kernel::miscdevice::MiscdeviceVTable` is private inside the miscdevice module, so there's no way I can somehow extend it. Is there any workaround for what I want to achieve, or is ioctl the only allowed interface to misc devices in Rust? Thank you, Fabio. [^1]: https://rust-for-linux.github.io/docs/kernel/file/trait.Operations.html [^2]: https://rust.docs.kernel.org/kernel/fs/index.html

5 7

Existing patches of similar content
by Torin Carey Sept. 15, 2025

Sept. 15, 2025

Hi KernelNewbies, Apologies if this is a stupid question. I was finishing up on a patch to add a new (fairly small) feature to an existing driver. While looking at the archives for the relevant mailing list, I noticed another contributor had submitted a patch to add the exact same feature just under a year ago, but the thread seems to have gone stale. I believe there are some bits that were missing from this patch in terms of correctness. What's the usual etiquette to approach this situation? I could: 1. submit my patch for review anyway; or 2. resurrect this thread providing a review for it along with the additions I think might be necessary; or 3. a combination of both? --- Torin

2 2