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 CB7D3C433F5 for ; Thu, 12 May 2022 13:24:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1354347AbiELNYx (ORCPT ); Thu, 12 May 2022 09:24:53 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55316 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S242623AbiELNYw (ORCPT ); Thu, 12 May 2022 09:24:52 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F1095F68B5; Thu, 12 May 2022 06:24:51 -0700 (PDT) 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 9551660DB6; Thu, 12 May 2022 13:24:51 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E773BC34114; Thu, 12 May 2022 13:24:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1652361891; bh=5DrSkrfZ376gmNIOa8YiJJpftUPjCe49Dwd/ROqERXo=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=J7qNG6aVE39IZKKT8v/WQnNB6GmrEUVTT+cqQRF+fEFqr9rQkU453e6gFDg2B+nVB oQgTybEPyBgP3Dp6ruY8B/xbZM8k3aFyJufroPdmlPd/Sk045P4WW3YyC31dfqB2Z5 lg0GHNdV6Hrh2C7/peJJoUKdt4b0Doi3M8GuONodCO8GCpGEbJOgOjkm/AAjNynb8y sqgJea3tlns87y9PxrTl7r+rJ01Wmyu05dl6ob3eZ7csA0aHONfuQL6RHBb66nYYFA LBCTEdwiOKDRWqnboFOXd3skP5K0Joa6hj0tQ40FO/KrTz1qvm9qDF6IAILrv8myi7 dTmICfTU7MDdQ== Received: from sofa.misterjones.org ([185.219.108.64] 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.2) (envelope-from ) id 1np8oC-00AsdL-B5; Thu, 12 May 2022 14:24:48 +0100 Date: Thu, 12 May 2022 14:24:48 +0100 Message-ID: <87wneq6fz3.wl-maz@kernel.org> From: Marc Zyngier To: "Lad, Prabhakar" Cc: Lad Prabhakar , Geert Uytterhoeven , Linus Walleij , Thomas Gleixner , Rob Herring , Krzysztof Kozlowski , Bartosz Golaszewski , Philipp Zabel , "open list:GPIO SUBSYSTEM" , LKML , Linux-Renesas , "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" , Phil Edworthy , Biju Das Subject: Re: [PATCH v3 3/5] gpio: gpiolib: Allow free() callback to be overridden In-Reply-To: References: <20220511183210.5248-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20220511183210.5248-4-prabhakar.mahadev-lad.rj@bp.renesas.com> <87y1z75770.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=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: prabhakar.csengg@gmail.com, prabhakar.mahadev-lad.rj@bp.renesas.com, geert+renesas@glider.be, linus.walleij@linaro.org, tglx@linutronix.de, robh+dt@kernel.org, krzysztof.kozlowski+dt@linaro.org, brgl@bgdev.pl, p.zabel@pengutronix.de, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, devicetree@vger.kernel.org, phil.edworthy@renesas.com, biju.das.jz@bp.renesas.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 On Thu, 12 May 2022 13:48:53 +0100, "Lad, Prabhakar" wrote: > > Hi Marc, > > Thank you for the review. > > On Thu, May 12, 2022 at 12:19 PM Marc Zyngier wrote: > > > > On Wed, 11 May 2022 19:32:08 +0100, > > Lad Prabhakar wrote: > > > > > > Allow free() callback to be overridden from irq_domain_ops for > > > hierarchical chips. > > > > > > This allows drivers to free any resources which are allocated during > > > populate_parent_alloc_arg(). > > > > Do you mean more than the fwspec? I don't see this being used. > > > The free callback is used in patch 5/5 where free is overridden by > rzg2l_gpio_irq_domain_free. I just gave an example there as an > populate_parent_alloc_arg() In actual in the child_to_parent_hwirq > callback I am using a bitmap [0] to get a free tint slot, this bitmap > needs freeing up when the GPIO interrupt is released from the driver > that as when overridden free callback frees the allocated tint slot so > that its available for re-use. Right, so that's actually a different life-cycle, and the whole populate_parent_alloc_arg() is a red herring. What you want is to free resources that have been allocated via some other paths. It'd be good if your commit message actually reflected this instead of using an example that doesn't actually exist. > > > There is also the question of why we need to have dynamic allocation > > for the fwspec itself. Why isn't that a simple stack allocation in the > > context of gpiochip_hierarchy_irq_domain_alloc()? > > > you mean gpio core itself should handle the fwspec > allocation/freeing? Yes. The only reason we resort to dynamic allocation is because ThunderX is using MSI-based GPIOs, and thus doesn't use a fwspec (no firmware is involved here). If we had a union of the two types, we could just have a stack variable, and pass that along, completely sidestepping the whole dynamic allocation/freeing business. M. -- Without deviation from the norm, progress is not possible.