From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8729523DB for ; Sat, 9 Mar 2024 10:03:44 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709978624; cv=none; b=Q+oHz3OdwCs/Dj9E3/Q4qYCv1mS5A8ojO9zZHxNGgkdD1JBOuV+6kxWnSCWtN3KDs3aRLuUgHolNlujQ6M0VqiNuSMMWT0Uq06IBLrmoJePQUlSeA0X5eRuVMnvvEOszeG/sU9JoaKnBs8B8uJwI6G77qMk0u3IjWas9k2z467w= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709978624; c=relaxed/simple; bh=htyoWLfhwhN0ImakCKy1p5CskoMqkspgyGQqqaQNWVI=; h=Date:Message-ID:From:To:Cc:Subject:In-Reply-To:References: MIME-Version:Content-Type; b=YyM2xcmZaO15vQ2o5uZODt52cOQQRXv3at41XbrgP0pqCjxRS1tX6/rjlV+TQXZzK9hscfzcSpupHUT6qxnhZ43ixAmVaMGIFoYYWnPy1zrYjLiBrKaDVGB+4rZD3KnCZNK1JaJlTqjI+T6tpHHlezgJF9EX0eaILZgiRsa657c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=ou7BNd17; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="ou7BNd17" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 14934C433C7; Sat, 9 Mar 2024 10:03:44 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1709978624; bh=htyoWLfhwhN0ImakCKy1p5CskoMqkspgyGQqqaQNWVI=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=ou7BNd17agypewrByHMKdoYH7+ugEbj/JsFmswEZUSdl9Ynd8zhZADd/PVoOENse6 azUkNj5ohKboU8dIYhWFOsHW7jsjY5I9Si/gm+xvUtifnx2VizpZpVWXAfANekXFtI 28SiZGO7Km6kpYMvmGB+kZLVkeVQadrp52se6m/nlyQZ4LJ3XuoF1w3bgycxX5WidY 2ipK5+4ufi38TN2EMzqEonoohFF8v1jOQ//LPtnq2n5f55uIEo5aByc3fBNlSln07c rR5n6ejaeQ2Qk3i7CoWBqtiEVxEqvlAmaKHi7rKMsiJYQE7lBktJYkQ2SJ2WE63Lod mjX0YFBL2AhFg== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1ritYL-00AxfT-Kh; Sat, 09 Mar 2024 10:03:41 +0000 Date: Sat, 09 Mar 2024 10:03:40 +0000 Message-ID: <874jdfrabn.wl-maz@kernel.org> From: Marc Zyngier To: Sebastian Fricke Cc: linux-kernel@vger.kernel.org, tglx@linutronix.de, bartosz.golaszewski@linaro.org Subject: Re: RFC: fake IRQchip In-Reply-To: <20240308143755.jey6kr3ftlzxt6lg@basti-XPS-13-9310> References: <20240308143755.jey6kr3ftlzxt6lg@basti-XPS-13-9310> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/28.2 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: sebastian.fricke@collabora.com, linux-kernel@vger.kernel.org, tglx@linutronix.de, bartosz.golaszewski@linaro.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Hi Sebastian, On Fri, 08 Mar 2024 14:37:55 +0000, Sebastian Fricke 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. Thanks, M. -- Without deviation from the norm, progress is not possible.