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 0E170C433EF for ; Tue, 24 May 2022 09:29:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S235573AbiEXJ3k (ORCPT ); Tue, 24 May 2022 05:29:40 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37648 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234728AbiEXJ3j (ORCPT ); Tue, 24 May 2022 05:29:39 -0400 Received: from mail-yb1-xb31.google.com (mail-yb1-xb31.google.com [IPv6:2607:f8b0:4864:20::b31]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 841C23336E for ; Tue, 24 May 2022 02:29:38 -0700 (PDT) Received: by mail-yb1-xb31.google.com with SMTP id q184so985691ybg.11 for ; Tue, 24 May 2022 02:29:38 -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=HVD805PIWF+vPNoBSV15VHHtEetrJAxgrnMmdyS5kRQ=; b=S0mvoueLkkCMEb0khGrKphavMKc90PQbW1hZrqOzWs1cit1wqnOgBEbOhwC2Gm1gcj kIHM1+IQNCQTcaoja5VpEYpV4co8AzCNNu+83KAIk53kLqOmI2hfP1Ar9xXxIieD16Om xjzFu5740eVTIKeVCbdUJGmwGM0Rkl5LQ+ZYKyjPu4YPaP+cGshdi94MjFCF/XNepcPw oYZJyyObKJcD+Yod/TT0w5hVunqVNuqN1+xGJPHLYopcydm+GoghNABwOFA16ah6fLCU dQB3qPEbBbhUjnXIz4bp3atdEuAhPeAjinnOqRPhWOrHjmxFQ8/GB4oqJh3UN8Mnv3dI /e3Q== 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=HVD805PIWF+vPNoBSV15VHHtEetrJAxgrnMmdyS5kRQ=; b=yRrRqru/MNPC2uUnwjFFQ4/1ORkME5h3El25PVEKqI0N02J1yikWKtloUX0OIygvuG qD2IT5bN/+/3GoPWNJeZ6/5S2O6oqlyYtFFT0o+f26NI4KXAxK5PCNg3U2pAJgPulp58 TEoWk04sNduXPHzDZqaIW8odLlDiokvI3+1IbbeQv4UvL5oYdp4KXGMUcJAhBJwMYoCE BokjiIlohAA/f/+5krBiXRiAxT7qJk2IvYUnV50cRKsCNxpr6BW2UChSEO/FrjRV/Sjv NESSZxTdj2Ciy8a1h0bJHpNzXKbYo9AuYce1KZ0zFQxz7YpNjBVdVC/rKroKM4m06brD w3rQ== X-Gm-Message-State: AOAM532nxM3M/KZUPChrJ+Ggx0L0I8d8q1tmt88pMA9kKj8fIHbKRtFc OErZnJh8K35voViQ+OG5mSF2ZHLPCRziPYNW4Kpd9Q== X-Google-Smtp-Source: ABdhPJwSufTp3IMXxz6Jk+46mDzRwOrdHVqjcyhgQZKrft4yGeS0BqvUhfbsZIAkn9moT48nyJeOgOP8pXv2k6Y8YBs= X-Received: by 2002:a05:6902:704:b0:64d:f270:22b0 with SMTP id k4-20020a056902070400b0064df27022b0mr25054247ybt.626.1653384577755; Tue, 24 May 2022 02:29:37 -0700 (PDT) MIME-Version: 1.0 References: <20220523174238.28942-1-prabhakar.mahadev-lad.rj@bp.renesas.com> <20220523174238.28942-4-prabhakar.mahadev-lad.rj@bp.renesas.com> In-Reply-To: From: Linus Walleij Date: Tue, 24 May 2022 11:29:26 +0200 Message-ID: Subject: Re: [PATCH v5 3/5] gpio: gpiolib: Allow free() callback to be overridden To: "Lad, Prabhakar" Cc: Lad Prabhakar , Marc Zyngier , 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" Precedence: bulk List-ID: X-Mailing-List: linux-tegra@vger.kernel.org On Tue, May 24, 2022 at 11:07 AM Lad, Prabhakar wrote: > On Tue, May 24, 2022 at 9:54 AM Linus Walleij wrote: > > > > On Mon, May 23, 2022 at 7:43 PM Lad Prabhakar > > wrote: > > > > > Allow free() callback to be overridden from irq_domain_ops for > > > hierarchical chips. > > > > > > This allows drivers to free up resources which are allocated during > > > child_to_parent_hwirq()/populate_parent_alloc_arg() callbacks. > > > > > > On Renesas RZ/G2L platform a bitmap is maintained for TINT slots, a slot > > > is allocated in child_to_parent_hwirq() callback which is freed up in free > > > callback hence this override. > > > > > > Signed-off-by: Lad Prabhakar > > > Reviewed-by: Geert Uytterhoeven > > > > So that function today looks like this: > > > > static void gpiochip_hierarchy_setup_domain_ops(struct irq_domain_ops *ops) > > { > > ops->activate = gpiochip_irq_domain_activate; > > ops->deactivate = gpiochip_irq_domain_deactivate; > > ops->alloc = gpiochip_hierarchy_irq_domain_alloc; > > ops->free = irq_domain_free_irqs_common; > > > > /* > > * We only allow overriding the translate() function for > > * hierarchical chips, and this should only be done if the user > > * really need something other than 1:1 translation. > > */ > > if (!ops->translate) > > ops->translate = gpiochip_hierarchy_irq_domain_translate; > > } > > > > (...) > > - ops->free = irq_domain_free_irqs_common; > > (...) > > > + if (!ops->free) > > > + ops->free = irq_domain_free_irqs_common; > > > > Marc Z is working on cleaning up the way that gpiolib is (ab)using > > irqchips. We definitely need his ACK if we do things like this. > > This doesn't look like one of the big offenders to me, but I want > > to make sure we don't create new problems while Marc is trying > > to solve the old ones. > > > Agreed, I had a discussion with Marc on v3 series [0]. Hm yeah I guess I am just stepping on Marc's toes with all my mails :( I'll try to just wait for Marc's Reviewed-by instead and not add to the noise, I'm probably just wrong. Yours, Linus Walleij