January 2026 - kernelnewbies@kernelnewbies.org

None
by Syed Kumail Hussain Sherazi Jan. 27, 2026

Jan. 27, 2026

Hi everyone, I'm working on a simple kernel module to get an idea of platform drivers and devices. I created a dtbo for my board (Beaglebone Black) and loaded it. When I install my kernel module with insmod I get an error from the pinmuxing driver. Here is the relevant dmesg output: [10971.691781] gpio_platform_drv: loading out-of-tree module taints kernel. [10971.699577] pinctrl-single 44e10800.pinmux: Invalid number of rows: 0 [10971.708571] pinctrl-single 44e10800.pinmux: no pins entries for gpio-irq-pin C code for the kernel module is at this link: https://hastebin.com/share/ejimanodir.cpp And the dtbo source is at this link: https://hastebin.com/share/xasizepicu.javascript I assume the issue is with the dtbo but I might be wrong. Any help might be appreciated. Thanks, Syed Kumail

1 0

Re: Query: Y2038 patch series for 3.18 Kernel
by Arnd Bergmann Jan. 20, 2026

Jan. 20, 2026

On Tue, Jan 20, 2026, at 02:05, syrus wrote: > From: [Syrus] <[syrus.lssu(a)ingenic.com]> > > Hi Arnd, all, > > Thanks for the discussion. While kernel upgrade solves Y2038 for new > projects, our legacy devices on 3.10.14 kernel face upgrade challenges > due to driver compatibility and limited resources (limited manpower, > communication barriers between different departments and companies, etc.). > > Has anyone successfully backported Y2038 fixes to older kernels like > 3.10.x? I'm looking for patch summaries or experiences with such > backports, or at least a summary of the commit history that addresses > this issue. Any guidance on key subsystems to focus on would be very > helpful for maintaining our legacy devices. Hi Syrus, As I replied earlier, anything older than 5.4 has pretty much no chance of getting the kernel backports. If you are specifically working on Ingenic's own SoC support, I do think that you are in luck as these seem to be fairly well supported in recent kernels, based on the work that Paul Cercueil has done over the years, at least for the chips that ended up in popular development boards and gaming handhelds (jz4725, jz4740, jz4760, jz4770). If there are specific drivers that are not yet supported upstream but work on the patched 3.10 kernel, I'm sure you can find consulting companies that are able to port those drivers as well. Arnd

1 0

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