Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp638024imw; Fri, 8 Jul 2022 09:04:01 -0700 (PDT) X-Google-Smtp-Source: AGRyM1sv+cmEdhICe/SXpTcBYwCSuYuWDz6muTQobuaCYVn27FcZmaK5ln6OEl3sEGdiVgI4gJWL X-Received: by 2002:a05:6402:2391:b0:43a:7ecd:5a63 with SMTP id j17-20020a056402239100b0043a7ecd5a63mr5741035eda.235.1657296240825; Fri, 08 Jul 2022 09:04:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657296240; cv=none; d=google.com; s=arc-20160816; b=COqicBRlcBRM00hSJFlQo4s62z5nTHF7bZU+nafyUCtUmOQaApdVTd8x3eLBMOyRek 2/7nzWjRmGm3qY8LM9S/NMa8265F3/9B8c9hAncnCVjMvwMaFfTNuxHGhQetC4fqActa HxXqgI2JgXMUdXlBxm/QLbu1dpV7wgEuqQd4/jYa+A6QRNbBx6pdCYTbNn/DvTOverFz 44QvFrAlXDEZ/viVKSWx8X1JTbIRoebKEcmTjjtF9Rl02jQlICRotly6nuOpTJIae+PY jLAoS+0FByiIKLuY25gJ29MwG42opkqpuc0BJ5DlsKsnIKI3W7Diu+SRHvmsKFDjrJK9 EJVw== 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=y6xprDpcoZOGJDj+kaMmTTKPyjy0F33A9f2Olt1+Xws=; b=MScFht9qk8RVNl40SRHMgjDxyMN/kmFWFCE7FaX5ETUd6T91gG45lFXUsp28zQ5Rgx C2zahQ9QjRc6a7/7K5zoXLwP1m0o9dHgf2pEZGGMIBDi+NrqwmoyZitc9Cn9cTFvcQTW FwX52DNCT+OgsqJsXm13Z4ZFrM8QwGpi8Ga8MzupOUOofr3utdskrHY2PnljlMrQxAxx A6SfTFme2/ZIF4IDNTQyEuoLRKj/4Ss3BxXZbFdZkhBZE4S8qThuKhbBxEmvVCyNLC5S 2hlwme7nKldKOMx98LMfCBoeG5L6/rTKl/KlG3XKSPz3r97HCU7dTesgbf4qT2tao9O9 PgcA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@bgdev-pl.20210112.gappssmtp.com header.s=20210112 header.b=v9hyV+ha; 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 Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id ht21-20020a170907609500b0072a605a57e9si8339760ejc.329.2022.07.08.09.03.27; Fri, 08 Jul 2022 09:04:00 -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=@bgdev-pl.20210112.gappssmtp.com header.s=20210112 header.b=v9hyV+ha; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S237753AbiGHPv4 (ORCPT + 99 others); Fri, 8 Jul 2022 11:51:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:36684 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S237623AbiGHPvx (ORCPT ); Fri, 8 Jul 2022 11:51:53 -0400 Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com [IPv6:2a00:1450:4864:20::631]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C12A273922 for ; Fri, 8 Jul 2022 08:51:51 -0700 (PDT) Received: by mail-ej1-x631.google.com with SMTP id d2so38452715ejy.1 for ; Fri, 08 Jul 2022 08:51:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bgdev-pl.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y6xprDpcoZOGJDj+kaMmTTKPyjy0F33A9f2Olt1+Xws=; b=v9hyV+haJfHpcHdA8b+dErnqxVGVjmEgLJE/af5R8VMDAXP8sPp5Yp3p8IU4Jo+7Rt nHR5lgvsPZ1nT+wkRwW7EojB+UukkdYqKqq54JELDI3vgTB/XKQF2ELOYcWWq8DBcqzl OpizpvkE+T159NNENJqqYY4LGqn2if7Pt9S99IDEjJLgU8RPbijnPJBgiwZSIakZvNfW /nPfwi+XNCCAsThBbL/NemE2egw5L7mJkdZ9HPuHqczDoZfFFLnDfgYGCEin73g2K/BC wU1UgqieyoWYiV5GD7WN/5M+Q3wIJcUwTOIFzWZjhvtPUvZ9XmSTwUaY8Yj/Y3x09NaG /KBg== 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=y6xprDpcoZOGJDj+kaMmTTKPyjy0F33A9f2Olt1+Xws=; b=KzamG4eLfnDot37QsqGlYFm0uN/88XwqLgKPkZizbLiru1lh68DCwSjkLwcyqPALJV 3d6VcITYDPRk7F9wkBhZhaoK43MiL35ANNFd3alOFrJ7dl7Li542hKWUguZSsEJYzD9W JS5j3/zO0W1hdGuDHzAqHrL44FfjEqvLYcKy6gRYhQGWKmlycPoTnMB9DEf8eGUcUygB 1DU0qXO2WKCIzVMXNkLf6Oh9mby9mXdTHjeoPa9OhHuB6dJ9PtYFkHTAM1+it01hq22I Ql364JoIvypvj79+xgE1WKsAYp2xZLZ8mIvV1asvxvGVJmY5iG1J8/WNZAbFKJVlNkLT S79w== X-Gm-Message-State: AJIora/OlNSUNjhFwgPu0/D0I5+/wxDE9I316Jgr7brwirIBSeyM4BS6 OpNxdxT0VdeCuZi3NzcD12YRrpqXLrR8PDkDIKhORQ== X-Received: by 2002:a17:907:60cc:b0:722:e564:eb11 with SMTP id hv12-20020a17090760cc00b00722e564eb11mr4152727ejc.736.1657295510287; Fri, 08 Jul 2022 08:51:50 -0700 (PDT) MIME-Version: 1.0 References: <20220707182314.66610-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20220707182314.66610-2-prabhakar.mahadev-lad.rj@bp.renesas.com> In-Reply-To: <20220707182314.66610-2-prabhakar.mahadev-lad.rj@bp.renesas.com> From: Bartosz Golaszewski Date: Fri, 8 Jul 2022 17:51:39 +0200 Message-ID: Subject: Re: [PATCH v8 1/6] gpio: Remove dynamic allocation from populate_parent_alloc_arg() To: Prabhakar Cc: Marc Zyngier , Thomas Gleixner , Rob Herring , Krzysztof Kozlowski , Geert Uytterhoeven , Linus Walleij , Philipp Zabel , devicetree , Linux-Renesas , "open list:GPIO SUBSYSTEM" , Linux Kernel Mailing List , Biju Das , Daniel Palmer , Romain Perier , Thierry Reding , Jonathan Hunter , Robert Richter , Nobuhiro Iwamatsu , Andy Gross , Bjorn Andersson Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_NONE, T_SCC_BODY_TEXT_LINE autolearn=ham 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 Thu, Jul 7, 2022 at 8:24 PM wrote: > > From: Marc Zyngier > > The gpiolib is unique in the way it uses intermediate fwspecs > when feeding an interrupt specifier to the parent domain, as it > relies on the populate_parent_alloc_arg() callback to perform > a dynamic allocation. > > This is pretty inefficient (we free the structure almost immediately), > and the only reason this isn't a stack allocation is that our > ThunderX friend uses MSIs rather than a FW-constructed structure. > > Let's solve it by providing a new type composed of the union > of a struct irq_fwspec and a msi_info_t, which satisfies both > requirements. This allows us to use a stack allocation, and we > can move the handful of users to this new scheme. > > Also perform some additional cleanup, such as getting rid of the > stub versions of the irq_domain_translate_*cell helpers, which > are never used when CONFIG_IRQ_DOMAIN_HIERARCHY isn't selected. > > Tested on a Tegra186. > > Reviewed-by: Linus Walleij > Signed-off-by: Marc Zyngier > Cc: Daniel Palmer > Cc: Romain Perier > Cc: Bartosz Golaszewski > Cc: Thierry Reding > Cc: Jonathan Hunter > Cc: Robert Richter > Cc: Nobuhiro Iwamatsu > Cc: Andy Gross > Cc: Bjorn Andersson > --- Acked-by: Bartosz Golaszewski