Received: by 2002:a05:6602:18e:0:0:0:0 with SMTP id m14csp3426122ioo; Tue, 24 May 2022 23:41:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJw0cVMtop4+d/Oc/X+SLO0aQY7HWBlCWaROrMzJQ9DgKNv37HeBaHINzpN/zSIC6qj7+cam X-Received: by 2002:a17:907:9612:b0:6fe:e969:e09b with SMTP id gb18-20020a170907961200b006fee969e09bmr11804648ejc.767.1653460879300; Tue, 24 May 2022 23:41:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1653460879; cv=none; d=google.com; s=arc-20160816; b=imS/aOhvx9PT20UW2526h9kEP6Edgzu8pb4/IYtN6dnx0d2+PAVJJMH10JVdA1MLiO EdPUBktuT3h8oLFOsRX98k3C9l2rmMB+Kls1W3EYC0q2hsKgrSJFBqYzrCd/fF1welH7 nDIdwAsPHvUyWuGsGFItYXQ3QDoIszYqoRLmeNbBHyeumue93x3/gjFMH7YPHnlH6GTO C8fR4itaWqqs3H6PEYnNO3xNfG1DXuLbx+ciEEcRRgPlVVAtIlTujz0BsoTY4soJEa11 EmqmbnU+cRhSL5D0g/LBSg0JYl8Aeo1UQ+OCoeMcsj0o75QKEsle7wuYyHapxZ1LmEYD D+Fg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=TvF2v3Zdj4AvC6elhsnAGyTKo72kfURW1pII2j4gt/Q=; b=TJFiN33ruFvE+LBDOOQYxm5FbkvALyR9kJkHjv0fKUAC0EdfvQzzUj5g5ma+7TU1UL LLdmShtgQdxlMyJZiDYCQcUbfBGnO378ZVMcmceX+1mOpOxTaLbAHOCNPW1sNHZT8W4X CCodFJ1SLcTp+QjcmhxaiyMQ/VYmSVi5THwEtWdGTPTVlwdBjc2YwWhv53uC2n4e2zkj 65+TLrmoFZ5lz5OfXHVDygZhbbfD/vVNCszfVZAVLZMV52MjcVEEZjYWKHNtGEqyqz7a 7fRQQdF+6wlVzY0kSJ9WF3zQieS2KQPzC0AdrgqxR8wBecshvMfMgsc+4OE+g7i7jf/g RlAA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=XpzHTpvN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hc40-20020a17090716a800b006fec3023067si12906333ejc.343.2022.05.24.23.40.50; Tue, 24 May 2022 23:41:19 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=XpzHTpvN; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235548AbiEXJ0t (ORCPT + 99 others); Tue, 24 May 2022 05:26:49 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33092 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S235531AbiEXJ0q (ORCPT ); Tue, 24 May 2022 05:26:46 -0400 Received: from mail-yb1-xb33.google.com (mail-yb1-xb33.google.com [IPv6:2607:f8b0:4864:20::b33]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 2FB8DFD33 for ; Tue, 24 May 2022 02:26:44 -0700 (PDT) Received: by mail-yb1-xb33.google.com with SMTP id q184so974978ybg.11 for ; Tue, 24 May 2022 02:26:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=TvF2v3Zdj4AvC6elhsnAGyTKo72kfURW1pII2j4gt/Q=; b=XpzHTpvN6AmprZmrulW4mS/lY8Nyve1zMhfriFFCBRVY2hE/9QHmXRJzy8s7Gc8ET2 OXS1sMp9MZ0vpV0wrG/c8HGO+Rr3nBmG9R5WJK4eOCAhNZ9lioFMUlC5XhP6xOa9hKUW MGALMYsCxHaNVg2xNoRgxWhVX4oXfryYfUeZ8lekKH8aLmzAb7xigj5rdoj+RvtKLhoA UJ5JvFb+pzrC6SxzjzSUBwn81XdzPlb+ZN1SJhkUiaq7cc5HK0a1ZziMgbyB0hNqAfgV LAMnJwsbzNgrW1mt/QDwRzHRfst7jFGePVTaQd7LpHfdwmE7Ls0rIk3ecs7yCIn+AWdR OPfQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TvF2v3Zdj4AvC6elhsnAGyTKo72kfURW1pII2j4gt/Q=; b=NE8p53N7MR4TsqNOYKMfd1Vzjl6PU7pM+sBDX9MPEZ07PyPFBaJB6/Ps0BINxANffW FQDojBRLTsMRbG+m7uRrW0m0t5rf1y2K7dbTMWSxEIfwxeL6EVUp8gr/xPVCZPSxbGbv TA19RypEBslD0Z1Sc7Z7GbIpzdXTbL1NxW27ULy0uN/sXdXyPAeVCVH17PqEP5jIMup4 eTAvypGi/XqBClinQDkJqB3zeEzB+SE7akpGL8ASjzzmzcUukIkc8Nk/MPc7CuzStfKd kvzDxUrHYTUj5v8kyHwIOPmzSZFkbl33kbAtc2K4E1s6V8m96mX5jAQzEQPILVf+gP7w GyxQ== X-Gm-Message-State: AOAM530W2cofZGYtbXbC04PTAIfqshtKBn/H4JXtp1gzmgcM4gsIx6Lo LitJAdyh3R7WWVZOUsC7sK6HJKlekySz2Uurp1T3TQ== X-Received: by 2002:a25:6cd6:0:b0:64f:c489:5382 with SMTP id h205-20020a256cd6000000b0064fc4895382mr10539555ybc.514.1653384403397; Tue, 24 May 2022 02:26:43 -0700 (PDT) MIME-Version: 1.0 References: <20220523174238.28942-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20220523174238.28942-6-prabhakar.mahadev-lad.rj@bp.renesas.com> In-Reply-To: From: Linus Walleij Date: Tue, 24 May 2022 11:26:31 +0200 Message-ID: Subject: Re: [PATCH v5 5/5] pinctrl: renesas: pinctrl-rzg2l: Add IRQ domain to handle GPIO interrupt To: "Lad, Prabhakar" , Marc Zyngier , Hans Verkuil Cc: Lad Prabhakar , Geert Uytterhoeven , Thomas Gleixner , Rob Herring , Krzysztof Kozlowski , Bartosz Golaszewski , Thierry Reding , Jonathan Hunter , Bjorn Andersson , Andy Gross , Philipp Zabel , Andy Shevchenko , "open list:GPIO SUBSYSTEM" , linux-tegra , linux-arm-msm , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , LKML , Linux-Renesas , Phil Edworthy , Biju Das Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 24, 2022 at 11:01 AM Lad, Prabhakar wrote: > On Tue, May 24, 2022 at 9:57 AM Linus Walleij wrote:> > > > On Mon, May 23, 2022 at 7:43 PM Lad Prabhakar > > wrote: > > > > > Add IRQ domain to RZ/G2L pinctrl driver to handle GPIO interrupt. > > > > > > GPIO0-GPIO122 pins can be used as IRQ lines but only 32 pins can be > > > used as IRQ lines at a given time. Selection of pins as IRQ lines > > > is handled by IA55 (which is the IRQC block) which sits in between the > > > GPIO and GIC. > > > > > > Signed-off-by: Lad Prabhakar > > > > I don't know if I'm too tired or reading it wrong, but it seems you > > went through the trouble of making it possible to override .free() in > > the irqdomain in patch 3/5 and yet not using it in this patch 5/5? > > > I think you missed it, free callback is overridden with > rzg2l_gpio_irq_domain_free(). > > [0] https://patchwork.kernel.org/project/linux-renesas-soc/patch/20220523174238.28942-6-prabhakar.mahadev-lad.rj@bp.renesas.com/ Yeah my bad, can't read properly today :/ Why is it necessary to do this stuff in the irqdomain rather than in the irqchip? Especially this: + bitmap_release_region(pctrl->tint_slot, i, get_order(1)); Since the idea with irq_domain is to translate physical (hardware) IRQs to Linux IRQ numbers, I don't see how this is related to that. To me it seems you have taken the usecase that is normally in irqchip and moved it to irqdomain. To me this seems much more like a job that needs to happen in the irqchip .irq_enable()/.irq_disable() pair, and which we have done before in Hans Verkuils patch series: 461c1a7d4733 gpiolib: override irq_enable/disable 4e9439ddacea gpiolib: add flag to indicate if the irq is disabled ca620f2de153 gliolib: set hooks in gpiochip_set_irq_hooks() This gets used by drivers such as: drivers/media/cec/platform/cec-gpio/cec-gpio.c Where you can see these dynamic calls: static bool cec_gpio_enable_irq(struct cec_adapter *adap) { struct cec_gpio *cec = cec_get_drvdata(adap); enable_irq(cec->cec_irq); return true; } static void cec_gpio_disable_irq(struct cec_adapter *adap) { struct cec_gpio *cec = cec_get_drvdata(adap); disable_irq(cec->cec_irq); } Which end up calling .irq_enable()/.irq_disable() on the irq_chip dynamically enabling/disabling the irq. If you prefer to have this done in process context up front when the irq is requested/released then irq_chip also have these callbacks: int (*irq_request_resources)(struct irq_data *data); void (*irq_release_resources)(struct irq_data *data); So I would think over the usecase here a bit. Why does this have to be in the irqdomain? Yours, Linus Walleij