linux-kernel - Re: 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-prev] [day] [month] [year] [list]

Message-ID: <20240313162427.lgvfvo7u6phdsbb7@basti-XPS-13-9310>
Date: Wed, 13 Mar 2024 17:24:27 +0100
From: Sebastian Fricke <sebastian.fricke@...labora.com>
To: Marc Zyngier <maz@...nel.org>
Cc: linux-kernel@...r.kernel.org, tglx@...utronix.de,
	bartosz.golaszewski@...aro.org
Subject: Re: RFC: fake IRQchip

Hey Marc,

On 09.03.2024 10:03, Marc Zyngier wrote:
>Hi Sebastian,
>
>On Fri, 08 Mar 2024 14:37:55 +0000,
>Sebastian Fricke <sebastian.fricke@...labora.com> wrote:
>>
>> 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?
>
>The problem with this approach is that it cannot be a generic irqchip,
>because it needs to know about the endpoint device to find out when
>the interrupt has been cleared. This is specially true for level
>signalling. If the device was only doing edge signalling, I could see
>a vague path forward, but that's not the case here (as evidenced by
>the DT bindings).
>
>My view on this is that given that the workaround has to know quite a
>few things about the generating device, it is better kept close to the
>driver code.

Alright thanks for your feedback. So in that case implementing polling
is definitely the better option as implementing a unique fake IRQchip
per driver seems not very efficient.

>
>Thanks,
>
>	M.

Greetings,
Sebastian

>
>-- 
>Without deviation from the norm, progress is not possible.