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 8E8F6C433EF for ; Wed, 6 Jul 2022 12:03:07 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233055AbiGFMDG (ORCPT ); Wed, 6 Jul 2022 08:03:06 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:37290 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233401AbiGFMDA (ORCPT ); Wed, 6 Jul 2022 08:03:00 -0400 Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D048729C81 for ; Wed, 6 Jul 2022 05:02:57 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id j7so20576411ybj.10 for ; Wed, 06 Jul 2022 05:02:57 -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=0gmjR92/ilIXmcsx4h/zr5BFgWECYWRbjj9sJUHVD5g=; b=N0QdBambMGMYoYTp/ybVCNWrXaoTghttU7dgzH1l1Y815ND8OXpTpu5QKKrePRio6K 7KRIAEGNTbZNiZMcIdV01pU5MrQKf6HbwibJdhvBWUGxTwsln5OQOxD1KyYopxUZJcPE mMQC3hncbvPCqEN5/TDUcHDFsNGPQrjNyEjWQLjKOkKp7AFoE/YneoshO+XADZxAckrp RqeX1dSD8GhOF6x1crOVz6mxaTuPjvplVjwE0a42z076XoJUpLWAIDKt2gdd0dWbw6vJ b+gii6IWb+yFYUGp21En+gqfoYPiDpaQ2MKBGmjaw9Mj62zCGnlxLSNNREnE97v4WciT HTKw== 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=0gmjR92/ilIXmcsx4h/zr5BFgWECYWRbjj9sJUHVD5g=; b=MVUtkrhD8JEV/DG0No3ISlEjyhN6JbziG+vevTThVd7eciHFcGnfQhhjf2q2L84JCR jWNgcfbfNKrXMJJXX3cbqcgUPP6DkCUhb1RHlF0CPgOFBBZej1FJa5fxnfXJKstAGXz8 OaVzIqFmlltwhPnqUpQYVz/jLbmHUZ5Jr7RNblbGwppE2MVQQELr79n2TJ9afwH+AOCA tOjIBEKZBbpScK/NN8TJBypsUGhxC2CETKrC43tnT+XYabgKojtFGaCTSQltkf2rClG8 d3wPk/w7ExfjlAHCDUbT4Z7S3qIS02iPwlvtkiA3462n1DFFP9NbnJA536SvGahWc8Ru bfnQ== X-Gm-Message-State: AJIora8o1HVw+5wp4J76nbheMEaEFmkLKKR3W2XI2LgXCSuRngChjpPi ejNoNyl/XCXLA7RQ5FFNhU0uCC9NgvP2adBKlxIE6A== X-Google-Smtp-Source: AGRyM1scIVOs0IANCeR4dGbkLq+Asjhy7uyA2rcSCG+/Hp/SD0OHvYykzYTKpepZq4LxW7fE9lvCJ2AbK8AjUePoonI= X-Received: by 2002:a05:6902:1241:b0:66e:a6f1:83f3 with SMTP id t1-20020a056902124100b0066ea6f183f3mr859140ybu.492.1657108977088; Wed, 06 Jul 2022 05:02:57 -0700 (PDT) MIME-Version: 1.0 References: <20220703111057.23246-1-aidanmacdonald.0x0@gmail.com> <20220703111057.23246-4-aidanmacdonald.0x0@gmail.com> In-Reply-To: From: Linus Walleij Date: Wed, 6 Jul 2022 14:02:43 +0200 Message-ID: Subject: Re: [PATCH 3/3] gpio: regmap: Support a custom ->to_irq() hook To: Aidan MacDonald Cc: michael@walle.cc, brgl@bgdev.pl, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-gpio@vger.kernel.org On Tue, Jul 5, 2022 at 1:08 PM Aidan MacDonald wrote: > Linus Walleij writes: > I'm not trying to argue that hierarchical IRQ domains are always a bad > thing -- I'm just pointing out they're not always useful or necessary. > All your points make sense when the GPIO controller is a large distinct > block with potentially many GPIOs. When we're dealing with an MFD device > with just a few GPIOs, maybe even just one, having a separate IRQ domain > makes less sense; the added structure is generally not useful. Do you mean your driver does this: MFD main device MFD irqchip | +-> MFD gpiochip No irqchip here, so .to_irq() just refers ^ to that one up there IIUC you mean that if I want to use the irqchip directly then I have to refer to the MFD irqchip, I just cannot refer to the gpiochip subnode because that one does not have an irqchip. // Getting GPIO from gpiochip and irq from MFD device // for the same GPIO line gpios = <&gpio 3 GPIO_ACTIVE_LOW>; irqs = <&mfd 114 IRQ_EDGE_RISING>; Then for a Linux driver this can be papered over by using the .to_irq() callback and just defining gpios. This isn't very good, if you created a separate gpiochip then you should have a separate (hierarchical) irqchip associated with that gpiochip as well. // Getting GPIO and irq from the same gpiochip node gpios = <&gpio 3 GPIO_ACTIVE_LOW>; irqs = <&gpio 3 IRQ_EDGE_RISING>; I made this mistake with the ab8500 driver and I would not do it like this today. I would use hierarchical gpio irqchip. And I should go and fix it. (Is on my TODO.) > Looking at other GPIO drivers using a hierarchical IRQ domain, they > include their own IRQ chips with specialized ops. In my case I don't > need any of that (and it'd be the same with other MFD devices) so it > looks like using an IRQ domain would mean I'd have to create a fake > IRQ chip and domain just to translate between two number spaces. > > Is that really better than simply using ->to_irq()? To be honest most irqchips are "fake", what they mostly do is figure out which of a few internal sources that fired the irq, so it models the different things connected to a single IRQ line. So yeah, I think the hierarchical irqchip is worth it, especially if that means the offset of the irqs and gpios become the same. Maybe we can add more helpers in the core to make it dirt simple though? It would help others with the same problem. Yours, Linus Walleij