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 X-Spam-Level: X-Spam-Status: No, score=-9.0 required=3.0 tests=BAYES_00,INCLUDES_CR_TRAILER, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 29D66C433B4 for ; Tue, 6 Apr 2021 12:45:43 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id F221161279 for ; Tue, 6 Apr 2021 12:45:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S239517AbhDFMpr convert rfc822-to-8bit (ORCPT ); Tue, 6 Apr 2021 08:45:47 -0400 Received: from mail.kernel.org ([198.145.29.99]:47250 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238486AbhDFMpk (ORCPT ); Tue, 6 Apr 2021 08:45:40 -0400 Received: from disco-boy.misterjones.org (disco-boy.misterjones.org [51.254.78.96]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id B3BEC6124C; Tue, 6 Apr 2021 12:45:32 +0000 (UTC) Received: from 78.163-31-62.static.virginmediabusiness.co.uk ([62.31.163.78] helo=why.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94) (envelope-from ) id 1lTl5G-005rHG-MG; Tue, 06 Apr 2021 13:45:30 +0100 Date: Tue, 06 Apr 2021 13:45:29 +0100 Message-ID: <87k0pfponq.wl-maz@kernel.org> From: Marc Zyngier To: Geert Uytterhoeven Cc: Linus Walleij , "open list:GPIO SUBSYSTEM" , Bartosz Golaszewski , "Wesley W . Terpstra" Subject: Re: [PATCH 1/2 v1] gpio: sifive: Set affinity callback to parent In-Reply-To: References: <20201117213351.249668-1-linus.walleij@linaro.org> <87mtubpufr.wl-maz@kernel.org> 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=UTF-8 Content-Transfer-Encoding: 8BIT X-SA-Exim-Connect-IP: 62.31.163.78 X-SA-Exim-Rcpt-To: geert@linux-m68k.org, linus.walleij@linaro.org, linux-gpio@vger.kernel.org, bgolaszewski@baylibre.com, wesley@sifive.com 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-gpio@vger.kernel.org Hi Geert, On Tue, 06 Apr 2021 11:51:25 +0100, Geert Uytterhoeven wrote: > > Hi Marc, > > On Tue, Apr 6, 2021 at 12:40 PM Marc Zyngier wrote: > > On Tue, 06 Apr 2021 11:20:57 +0100, > > Geert Uytterhoeven wrote: > > > On Tue, Nov 17, 2020 at 10:37 PM Linus Walleij wrote: > > > > This assigns the .irq_set_affinity to the parent callback. > > > > I assume the sifive GPIO can be used in systems with > > > > SMP. > > > > > > > > I used the pattern making the hirerarchy tolerant for missing > > > > parent as in Marc's earlier patches. > > > > > > > > Cc: Yash Shah > > > > Cc: Wesley W. Terpstra > > > > Suggested-by: Marc Zyngier > > > > Signed-off-by: Linus Walleij > > > > > > Thanks for your patch! > > > > > > > --- > > > > ChangeLog RFT->v1: > > > > - Make the affinity setting call return -EINVAL if there > > > > is no parent. > > > > > > Would it make sense to incorporate this check into > > > irq_chip_set_affinity_parent(), so drivers can just point > > > .irq_set_affinity to the latter, without having to provide (duplicate) > > > the same wrapper over and over? > > > > Calling one of the irq_chip_*_parent() functions assumes that there > > *is* a parent at all times, because you really need to know what > > context you are in by construction. There are a couple of exceptions > > to this rule (irqchip state, retriggering), but overall I'd like to > > stick to it and leave the checks on the implementations that have > > weird setups. > > > > I would assume that it is possible to know at the point where you map > > the interrupt whether it has a parent or not, and use a different > > irqchip. Is that doable in this case? > > I think you're missing my point (or I'm missing yours ;-) > > I don't mean to set up .irq_set_affinity = irq_chip_set_affinity_parent() > by default. > > Right now, several drivers do this: > > static int foo_irq_set_affinity(struct irq_data *data, > const struct cpumask *dest, > bool force) > { > if (data->parent_data) > return irq_chip_set_affinity_parent(data, dest, force); > > return -EINVAL; > } > > .irq_set_affinity = foo_irq_set_affinity, > > If irq_chip_set_affinity_parent() would not blindly dereference > data->parent_data, there would be no need for the > foo_irq_set_affinity() wrappers. The "blind dereference" is a completely assumed design choice. That's because when you instantiate an irqchip, you know whether there is another chip on the IRQ path, or whether this is a root (or a mux, which amounts to the same thing). So in most cases, you shouldn't need to check for a parent. You know there is one by construction, and if there isn't one, you don't call the *_parent() anyway. So unless the HW is representative of what I describe below, a static parent/no-parent setup is preferable. > Or are all those drivers using such a wrapper wrong? I only know of a few drivers that have some variability around that, which resulted in some hacks similar to what you describe. See these patches for example: c351ab7bf2a5 soc/tegra: pmc: Don't create fake interrupt hierarchy levels 8681cc33f817 soc/tegra: pmc: Allow optional irq parent callbacks 986ec63d4482 gpio: tegra186: Allow optional irq parent callbacks 55567976629e genirq/irqdomain: Allow partial trimming of irq_data hierarchy This could have been avoided by restructuring the driver, but would also have had impacts on DT, resulting in something even more horrible. QC's PDC also suffer from a similar hack, which I plan to address once I get this !"£$% machine to boot... But in general, if you need to check for a parent, that's because you are doing something that is either a bit unexpected, or has a *very* broad spectrum (doing something generic enough that it must cope with all possible situations). Thanks, M. -- Without deviation from the norm, progress is not possible.