Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp637048imw; Wed, 13 Jul 2022 05:26:58 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tIrjm9n+AG8BX8YyB2m3zTfQZJURH3ylPEKbqkiNC56jzITHsb6o8ajrxx+HdS3gt0gRV5 X-Received: by 2002:a17:902:cece:b0:16c:3683:8835 with SMTP id d14-20020a170902cece00b0016c36838835mr3191637plg.104.1657715218193; Wed, 13 Jul 2022 05:26:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657715218; cv=none; d=google.com; s=arc-20160816; b=MFtSFq3YaJWHdOn1HozWqu2cvq5Q/hwvSU/TiYVBbqXJZv8MfhoZ5Gi9Y1RPrh57Ly yOu45LKZ9mrgzkUujqvpej/OTUPkEaAhF6A7MIS8yrIpcSFodh/po5f0rFXxIAwLKAoE Rdn9rMiJXcs7DSFY7f3JLpcZwmjeY8WxF47Bd5KxtJnFxITKfXF33ONzVC8rkDxs22OJ UoQ5qMu0mvNdELx2KFDoyigRxFWgFvVhaPUIJ0dKdI6hsUo4o1oYlI+TrLLy6mJTpGtg vceMXNRpgEB121cxDaHyHiBJmSLYpokYbDTemElRhWXp/xCVZ70NRPU3Odqu2gQ22HaI UokA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:message-id:user-agent :references:in-reply-to:subject:cc:to:from:date:mime-version :dkim-signature; bh=Zi6RMCA/JdRJmsLw5kyMyerOSPDCIxC2fT5tJuJwyes=; b=is8S9NjiCqaGDwp0o886pNLZCUF7leFqlR2AQP7WgFfJPNFTTOF1pBOE+dsnB++scc IwakAYv8Qb8C4hhk8KpkNvVY0ncFcI7VPcoMl4WIGJJREmdRu+cOipXnBH+NR4QSpEWq 1WpPSou3k9EbLXjxPw2tcbWMcuGEbyAeLmymOLMLSztEXV9XKhzbaXdy6CoaaP2ndlqQ MK08pETBkFOVpSl+adcHnln5e4cu9LuBE4y16YQDnNQJHzUYktJs3ar3U96A36e/zJgs THnXv6jRdXR4pYGaLYhjiaj5Q50XVYIG3c43Q5qJ+MrYzNvk7pqaRDDuCiZJL6YvmZ3c nAqA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=RMIk7Ni6; 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=kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id h16-20020a170902f71000b0016a5e81c31fsi16638416plo.525.2022.07.13.05.26.45; Wed, 13 Jul 2022 05:26:58 -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=@kernel.org header.s=k20201202 header.b=RMIk7Ni6; 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=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236014AbiGMLrm (ORCPT + 99 others); Wed, 13 Jul 2022 07:47:42 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:39588 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230270AbiGMLrk (ORCPT ); Wed, 13 Jul 2022 07:47:40 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id E8B6810292A; Wed, 13 Jul 2022 04:47:39 -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 ams.source.kernel.org (Postfix) with ESMTPS id D9465B81E41; Wed, 13 Jul 2022 11:47:37 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 4C82AC34114; Wed, 13 Jul 2022 11:47:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657712856; bh=H8yyXEjn4YC4H+2gvA5SkNb8NVzX5EfAtKup6jSajrc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=RMIk7Ni6nJuva8yeare1eE6EoMopz60CUWTkK8tNUxLT+S/+fWzDx4nEOZhNqpqjc 5Ju1TbIWKwsG6JJOxBRjxMGBnKeSHbca7/foqbcX+pi1wIQFgwj6ZD8rmlS2NJEfki xf/SyKhSa1UXENoNxRf8PsXa+D7P+tj1ykbr0ojxHNoC1TCPppR8s1gFrKSPhthfNo 0Uegi6wV+2F44If+IC/mLIFGGk5dghZCPVDQauX/2TFB9W2FCos8mZROC3BmEYLCkd xQ1oQ/fpqecnECxNHmZOjY0JR2WlNDvW0NtYcwpa5xSZUtV5TZVOh7gjUPwmzwH+t3 F6KT4xuf2ntww== Received: from disco-boy.misterjones.org ([51.254.78.96] helo=www.loen.fr) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1oBaq5-007CkN-VZ; Wed, 13 Jul 2022 12:47:34 +0100 MIME-Version: 1.0 Date: Wed, 13 Jul 2022 12:47:33 +0100 From: Marc Zyngier To: Robert Marko Cc: Manivannan Sadhasivam , Bjorn Andersson , Andy Gross , Linus Walleij , linux-arm-msm , linux-gpio@vger.kernel.org, open list Subject: Re: [PATCH] pinctrl: qcom: spmi-gpio: make the irqchip immutable In-Reply-To: References: <20220624195112.894916-1-robimarko@gmail.com> <87edyq1ujr.wl-maz@kernel.org> <20220712124445.GC21746@workstation> <87czea1i2f.wl-maz@kernel.org> User-Agent: Roundcube Webmail/1.4.13 Message-ID: X-Sender: maz@kernel.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-SA-Exim-Connect-IP: 51.254.78.96 X-SA-Exim-Rcpt-To: robimarko@gmail.com, manivannan.sadhasivam@linaro.org, bjorn.andersson@linaro.org, agross@kernel.org, linus.walleij@linaro.org, linux-arm-msm@vger.kernel.org, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,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 2022-07-13 12:08, Robert Marko wrote: > On Tue, 12 Jul 2022 at 17:12, Marc Zyngier wrote: >> >> On Tue, 12 Jul 2022 13:44:45 +0100, >> Manivannan Sadhasivam wrote: >> > >> > On Tue, Jul 12, 2022 at 11:42:32AM +0100, Marc Zyngier wrote: >> > > On Fri, 24 Jun 2022 20:51:12 +0100, >> > > Robert Marko wrote: >> > > > >> > > > Commit 6c846d026d49 ("gpio: Don't fiddle with irqchips marked as >> > > > immutable") added a warning to indicate if the gpiolib is altering the >> > > > internals of irqchips. >> > > > >> > > > Following this change the following warning is now observed for the SPMI >> > > > PMIC pinctrl driver: >> > > > gpio gpiochip1: (200f000.spmi:pmic@0:gpio@c000): not an immutable chip, please consider fixing it! >> > > > >> > > > Fix this by making the irqchip in the SPMI PMIC pinctrl driver immutable. >> > > > >> > > > Signed-off-by: Robert Marko >> > > > --- >> > > > drivers/pinctrl/qcom/pinctrl-spmi-gpio.c | 22 ++++++++++++---------- >> > > > 1 file changed, 12 insertions(+), 10 deletions(-) >> > > > >> > > > diff --git a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c >> > > > index c3255b0bece4..406ee0933d0b 100644 >> > > > --- a/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c >> > > > +++ b/drivers/pinctrl/qcom/pinctrl-spmi-gpio.c >> > > > @@ -171,7 +171,6 @@ struct pmic_gpio_state { >> > > > struct regmap *map; >> > > > struct pinctrl_dev *ctrl; >> > > > struct gpio_chip chip; >> > > > - struct irq_chip irq; >> > > > u8 usid; >> > > > u8 pid_base; >> > > > }; >> > > > @@ -988,6 +987,17 @@ static void *pmic_gpio_populate_parent_fwspec(struct gpio_chip *chip, >> > > > return fwspec; >> > > > } >> > > > >> > > > +static const struct irq_chip spmi_gpio_irq_chip = { >> > > > + .name = "spmi-gpio", >> > > > + .irq_ack = irq_chip_ack_parent, >> > > > + .irq_mask = irq_chip_mask_parent, >> > > > + .irq_unmask = irq_chip_unmask_parent, >> > > >> > > No, this is wrong. Please look at the documentation to see how you >> > > must now directly call into the gpiolib helpers for these two >> > > callbacks. >> > > >> > >> > IIUC, you are referring to gpiochip_disable_irq() and >> > gpiochip_enable_irq() APIs. >> >> I am indeed. >> >> > These APIs are supposed to let the gpiolib know about that the IRQ >> > usage of these GPIOs. But for the case of hierarchial IRQ domain, >> > isn't the parent is going to do that? >> >> Why would it? The parent has no clue about what sits above it. In a >> hierarchical configuration, each level is responsible for its own >> level, and the GPIO layer should be responsible for its own >> management. >> >> > Please correct me if I'm wrong. >> >> I'm afraid you are, and this patch is a fairly obvious change in >> behaviour, as the callbacks you mention above are not called anymore, >> while they were before. >> >> If they are not necessary (for reasons I can't fathom), then this >> should be clearly explained. > > Hi Marc, > I will look at IRQ GPIO docs, but in this case, then we have more > conversions that > are not correct. Then please point them out. M. -- Jazz is not dead. It just smells funny...