Received-SPF: pass (google.com: domain of linux-kernel+bounces-101724-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.80.249 as permitted sender) client-ip=147.75.80.249;
Date: Wed, 13 Mar 2024 17:24:27 +0100
From: Sebastian Fricke <sebastian.fricke@collabora.com>
To: Marc Zyngier <maz@kernel.org>
Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de,
	bartosz.golaszewski@linaro.org
Subject: Re: RFC: fake IRQchip
Message-ID: <20240313162427.lgvfvo7u6phdsbb7@basti-XPS-13-9310>
References: <20240308143755.jey6kr3ftlzxt6lg@basti-XPS-13-9310>
 <874jdfrabn.wl-maz@kernel.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Disposition: inline
In-Reply-To: <874jdfrabn.wl-maz@kernel.org>

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@collabora.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.