Re: [PATCH] uio: eliminate extraneous irq thread under CONFIG_PREEMPT_RT
From: Sebastian Andrzej Siewior
Date: Thu Aug 20 2026 - 10:12:35 EST
On 2026-08-19 20:48:51 [+0000], Chris Packham wrote:
> Hi Sebastian,
Hi Chris,
> On 20/08/2026 03:06, Sebastian Andrzej Siewior wrote:
> > Chris, what was the use case to split this?
>
> I was dealing with having a UIO interrupt for an input on a PCA9539.
> There's some more info on the original email thread[1] but basically
> because the PCA9539 inputs are nested __setup_irq() enforces that anyone
> requesting them does so with a threaded interrupt.
>
> https://lore.kernel.org/all/20240408234050.2056374-3-chris.packham@xxxxxxxxxxxxxxxxxxx/
so you wrote:
| Prior to this the UIO registration fails with:
|
| [ 6.484699] uio_pdrv_genirq detect-gpio-9: unable to register uio device
| [ 6.484722] uio_pdrv_genirq detect-gpio-9: probe with driver uio_pdrv_genirq failed with error -22
|
| The -EINVAL ultimately comes from __setup_irq() where it knows the
| interrupt descriptor is nested but we haven't provided a thread_fn.
So we talk about this piece of kernel/irq/manage.c:
| /*
| * Check whether the interrupt nests into another interrupt
| * thread.
| */
| nested = irq_settings_is_nested_thread(desc);
| if (nested) {
| if (!new->thread_fn) {
| ret = -EINVAL;
| goto out_mput;
| }
| /*
| * Replace the primary handler which was provided from
| * the driver for non nested interrupt handling by the
| * dummy function which warns when called.
| */
| new->handler = irq_nested_primary_handler;
| } else {
If so, you realize that uio_interrupt_handler() isn't called at all?
Sebastian