From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9C769C433F5 for ; Thu, 30 Dec 2021 11:25:51 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S238856AbhL3LZv (ORCPT ); Thu, 30 Dec 2021 06:25:51 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55340 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238841AbhL3LZu (ORCPT ); Thu, 30 Dec 2021 06:25:50 -0500 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 76560C061574; Thu, 30 Dec 2021 03:25:50 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 170E46167E; Thu, 30 Dec 2021 11:25:50 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74E03C36AE9; Thu, 30 Dec 2021 11:25:49 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1640863549; bh=F0EzMjdjS2x7XL3rHnxGr+iR7j35Qs3LzSjdlDQxNAw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=HVIGh4zq+lUzsLr9ny8Q6AUCIgYi1s8ThjzrRvddjW5UPABIfEskFJpZHymDtWtz2 +ptcI0NLacYCr5VxJbExezhZsafEtrfvknws7NxY+xSiDr/LmlOGn7B1+XjKjWOP+p pOhjuzyhcggSPhPKzQ+7lcKuXkzesmeunGPFjYRECEWpHvyhH2DfOKJl1M0G5vxImn r1UkoiIAQAVWXtUFKYljNfoPVlg2qSmgfTb9UEh0Wc55n9AsplsgToOijbl69H5XZx yeC7Du5bu4Gjj0doUK+RDeVJxyqrKioBE87/5aUtIcFWHEmzMcw5Njb7XfkYvH/AH5 N/tMnupRHG1kg== Received: from cfbb000407.r.cam.camfibre.uk ([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.94.2) (envelope-from ) id 1n2tZ5-00F3zS-F4; Thu, 30 Dec 2021 11:25:47 +0000 Date: Thu, 30 Dec 2021 11:25:46 +0000 Message-ID: <87czlez64l.wl-maz@kernel.org> From: Marc Zyngier To: Nikita Yushchenko Cc: Thomas Gleixner , Geert Uytterhoeven , Magnus Damm , linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH/RFC] drivers/irqchip: add irq-inverter In-Reply-To: <9df5e85b-79e6-b796-e5ce-bc47d2cbed67@cogentembedded.com> References: <20211228165642.2514766-1-nikita.yoush@cogentembedded.com> <87h7aszj70.wl-maz@kernel.org> <87fsqbznc2.wl-maz@kernel.org> <37db485e-b832-9ff1-4d21-606eeeba871c@cogentembedded.com> <87ee5uz8hk.wl-maz@kernel.org> <9df5e85b-79e6-b796-e5ce-bc47d2cbed67@cogentembedded.com> 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/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) 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: nikita.yoush@cogentembedded.com, tglx@linutronix.de, geert+renesas@glider.be, magnus.damm@gmail.com, linux-renesas-soc@vger.kernel.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false Precedence: bulk List-ID: X-Mailing-List: linux-renesas-soc@vger.kernel.org On Thu, 30 Dec 2021 10:53:30 +0000, Nikita Yushchenko wrote: > > >>>>> The right way to do it is to use the existing API by exposing the > >>>>> inverter (there are existing examples in the tree, using the > >>>>> hierarchical model)... > >>> > >>> A much simpler version can be written in a few minutes, see below... > >> > >> Can something like that be used if the parent domain is not > >> hierarchical (i.e. does not provide alloc(), but provides map() > >> instead)? > > > > No. This definitely relies on the parent being hierarchical, as that's > > exactly what it was designed for the first place. > > Is supporting hierarchical API now mandatory for kernel irqchips? It isn't. But you are definitely giving me some ideas now. > > If yes, then perhaps you can at least document it somewhere? > E.g. declare irq_domain.map() as deprecated? > > If no, then I'd like to discuss a solution for irq_inverter that can > work for non-hierarchical case. You are still missing the point. Any active element on the interrupt path that changes the signal without multiplexing must be described in the hierarchical model. Anything else is wrong, and I am not interested in reinventing that particular wheel (it was painful enough to kill all these hacks years ago, and I'm not doing it again). Moving these GPIO chips into the hierarchical model isn't rocket science, as there is plenty of support for that already, and is the right thing to do. M. -- Without deviation from the norm, progress is not possible.