linux-kernel - RFC: fake IRQchip

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-next>] [day] [month] [year] [list]

Date: Fri, 8 Mar 2024 15:37:55 +0100
From: Sebastian Fricke <sebastian.fricke@...labora.com>
To: linux-kernel@...r.kernel.org
Cc: tglx@...utronix.de, maz@...nel.org, bartosz.golaszewski@...aro.org
Subject: RFC: fake IRQchip

Hey,

I am one of the maintainers of the media subsystem and we are currently
reviewing a patch [1], where the author has developed a polling
mechanism for a driver, while the hardware (Wave5 Codec) actually always
expects an interrupt line to be present and the only reason why this
isn't uphold is because the SoC has a defect, causing the interrupt line
to be disabled.
As I am a bit reluctant to litter a driver with workarounds for defective
hardware, I suggested to the author, that he could implement fake
IRQchip, which does polling in the background. This could first be
implemented in the driver directory and then later possibly upstreamed
to /drivers/irqchip.
So, far I've got a few approving comments for that idea, but I would
really like to know what the irqchip folks think about this.

Now my question is basically, what do you think about such a solution? Would
you accept such a fake irqchip driver, that can be used by
hardware without an interrupt line to fake one? Do you think there is a
better solution or do you think that my suggestion has hidden traps?

Thomas has already pointed me to IRQ sim, any further help is highly
appreciated.

[1][https://patchwork.linuxtv.org/project/linux-media/patch/20240125130833.1953617-1-devarsht@ti.com/#155281]

Greetings,
Sebastian