linux-kernel - Re: [PATCH 4/4] media: dw100: Split interrupt handler to fix timeout error

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: <20260105163748.2488d506@gandalf.local.home>
Date: Mon, 5 Jan 2026 16:37:48 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Nicolas Dufresne <nicolas@...fresne.ca>
Cc: Stefan Klug <stefan.klug@...asonboard.com>, Xavier Roumegue	
 <xavier.roumegue@....nxp.com>, Mauro Carvalho Chehab <mchehab@...nel.org>,
 Sebastian Andrzej Siewior	 <bigeasy@...utronix.de>, Clark Williams
 <clrkwllms@...nel.org>, Laurent Pinchart
 <laurent.pinchart@...asonboard.com>, linux-media@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-rt-devel@...ts.linux.dev
Subject: Re: [PATCH 4/4] media: dw100: Split interrupt handler to fix
 timeout error

On Mon, 05 Jan 2026 14:03:58 -0500
Nicolas Dufresne <nicolas@...fresne.ca> wrote:

> Le lundi 05 janvier 2026 à 12:35 +0100, Stefan Klug a écrit :
> > In the previous commit, the interrupt handler was changed to threaded.
> > This sometimes leads to DW100_INTERRUPT_STATUS_INT_ERR_TIME_OUT being
> > set after changing the vertex map. This can be seen by repeated error
> > outputs in dmesg:
> > 
> > dw100 32e30000.dwe: Interrupt error: 0x1
> > 
> > As there is no documentation available, it is unclear why that happens
> > and if this condition can simply be ignored. By splitting the interrupt
> > handling into two parts and only handling the dw100_job_finish() within
> > the threaded part, the error does not occur anymore.
> > 
> > Signed-off-by: Stefan Klug <stefan.klug@...asonboard.com>  
> 
> Ok, but arguably, this could be squashed.

Agreed. Because it doesn't seem to make sense to have a oneshot threaded
irq handler that doesn't have the two parts (non-threaded to acknowledge the
irq, and the threaded to handle it and re-enable it).

-- Steve