Message ID | 20221111113732.461881-1-thierry.reding@gmail.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel-owner@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a5d:6687:0:0:0:0:0 with SMTP id l7csp690927wru; Fri, 11 Nov 2022 03:45:44 -0800 (PST) X-Google-Smtp-Source: AA0mqf5GIldao/zi8G2OT+yp8lpT6eqTXmplRHfT4xeBCnWZnF8js6lkxX1KpGeyNEyMfiM+Idrd X-Received: by 2002:a17:906:2cd6:b0:78d:20f7:1294 with SMTP id r22-20020a1709062cd600b0078d20f71294mr1660722ejr.442.1668167144415; Fri, 11 Nov 2022 03:45:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668167144; cv=none; d=google.com; s=arc-20160816; b=XUNaIucHoPE/wt9YrrxOPe384beGzC2cKEgnBfs01S0GBGErhUZHOvL914WMXzO0tG aHu5QYwdd5+gA3H024YPpfeB5G67AxFTUH7NHMmWu/tWODI1R474h+Y7fU0H3ry64Nlq aAeveZ3ObguUcu2HZYE355ys1cHEgkhe4gw20+L6cedeDF48jc5foROnCkIF+onzb0Gq 6OnpaeBwW7RIHA/MS9H8sAd7pDP+vjTAH3QlcQ1LMYqUdGeqPG58F2i5xXtOrLIOvjef pUsN+FlWcVjc8BX6zJ9LueuHHTonaDYfO8AYPJrqGa00vD/nyJl/nNnM1xky8TwPGN5N TfLA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from:dkim-signature; bh=kcYkB/mxztaLgFeEdGXiapfCgu8NPHMQKOD54+dU1Xg=; b=YyGzdWoJIr0l1VpqgWSEKRSLMyJ0AcQmXrsyTQNls5pmLRp//VXTlI2q3+aiKImfvr tfsrHHbzjI2akLZGGvhYWISu4QrV5G09tZ2cWg/icVafb5P6WOzALrYpNalzkoZ17Bof WISk+U6idKjxHpx/Raopwf1L3ux7RUETLxK0TQBotoVUB8Csi9yh9OwFVOVGYRWZI8VI fWKxHkZomAutmM8Q2p6FigTVzFhTnLsU/9my5qzdxUXBtRoqNw/ky5XtE0AIFxV4ail/ j2EX68d34ydkHxsvEKBVxfsxbKrg3CaiW1cPT7CpYBkkl5EXjWoODo9/NsFNVbG1q+kL vaCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20210112 header.b=Ynrf4dU5; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id go14-20020a1709070d8e00b007ae63fe980dsi2102446ejc.931.2022.11.11.03.45.18; Fri, 11 Nov 2022 03:45:44 -0800 (PST) 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=@gmail.com header.s=20210112 header.b=Ynrf4dU5; 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=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233423AbiKKLjZ (ORCPT <rfc822;winker.wchi@gmail.com> + 99 others); Fri, 11 Nov 2022 06:39:25 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:44152 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233446AbiKKLjI (ORCPT <rfc822;linux-kernel@vger.kernel.org>); Fri, 11 Nov 2022 06:39:08 -0500 Received: from mail-wr1-x42e.google.com (mail-wr1-x42e.google.com [IPv6:2a00:1450:4864:20::42e]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id A77488D18C; Fri, 11 Nov 2022 03:37:38 -0800 (PST) Received: by mail-wr1-x42e.google.com with SMTP id k8so6141856wrh.1; Fri, 11 Nov 2022 03:37:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=kcYkB/mxztaLgFeEdGXiapfCgu8NPHMQKOD54+dU1Xg=; b=Ynrf4dU5EOo5yHCKTcZ3ChryXeMxonMaIZ96DCkpPoDic+1exkeZWdnFCtr1JclsZE RmQ2zSjtW/yPIFCuTmvH3lBv3XHwZkT3hds4aiiYsbz8Kivx9QddzOgBgsZBws2JhXbu UI3F5uBkSurqh4pmGlEyqCTvVeZ2P/Kije5JtyBqL0IQujI/SetdLHRQga0Hr19zQ/Av CODd0CIyAIK4ekmBQtxRhwSgS+vLGXLMV8TGGDNPJiF7ae5IyDl2zLP6StJcCyqQN59J XijfvMnvKjWMqxO1aV8224i24H/PhsEkB2/WIP8WaxpM+v1jpfd5FiBmpEdJqBsV7PnV dOOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=kcYkB/mxztaLgFeEdGXiapfCgu8NPHMQKOD54+dU1Xg=; b=Tx9qYJC9rLV/eW5O2OgudPAjLJLvKkgkO4KB9Cd9ZnmpAHioCZYlyS8lf/Y7Fw/dEf I9bwe2SN2y3sfV9iE5IS9h8ZpJXNp3dkhn/QxnIA2M//W+j92RMVKDBBV7pTshekhlHs IN+sX1K6/y7AEy0aX4FaxNFT8DmtA3bxghToMZcnh41HakcUON0iIih/k1PQF9+Yjnis d0eIm29aIRXigDm3dF4JncIDRlTJLSIqCSPYevNfMSZEWm8s2vd/KiLgbDn6CTeXuN70 2hFunaIAwe8SHfQxXowzJitKuZOhm+s8bK/8j/sDNguMMwcgeoiJWo/NSPQJ2WKVHBrP mPQw== X-Gm-Message-State: ANoB5pmvc7BhI17MgEnAP24Kw7XEOh4ku2r/w49nRLKXihcUwMdYfX74 zjRLMtaU/A0Ew+lEy/nsUzbCSLvwcEw= X-Received: by 2002:adf:e546:0:b0:236:7083:21d5 with SMTP id z6-20020adfe546000000b00236708321d5mr932526wrm.126.1668166656750; Fri, 11 Nov 2022 03:37:36 -0800 (PST) Received: from localhost (p200300e41f201d00f22f74fffe1f3a53.dip0.t-ipconnect.de. [2003:e4:1f20:1d00:f22f:74ff:fe1f:3a53]) by smtp.gmail.com with ESMTPSA id e12-20020adffd0c000000b00236576c8eddsm1728349wrr.12.2022.11.11.03.37.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Nov 2022 03:37:36 -0800 (PST) From: Thierry Reding <thierry.reding@gmail.com> To: Bartosz Golaszewski <brgl@bgdev.pl>, Linus Walleij <linus.walleij@linaro.org> Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>, Dmitry Torokhov <dmitry.torokhov@gmail.com>, linux-gpio@vger.kernel.org, linux-kernel@vger.kernel.org, Marek Szyprowski <m.szyprowski@samsung.com> Subject: [PATCH] gpiolib: of: Use correct fwnode for DT-probed chips Date: Fri, 11 Nov 2022 12:37:32 +0100 Message-Id: <20221111113732.461881-1-thierry.reding@gmail.com> X-Mailer: git-send-email 2.38.1 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS 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: <linux-kernel.vger.kernel.org> X-Mailing-List: linux-kernel@vger.kernel.org X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1749200031390276775?= X-GMAIL-MSGID: =?utf-8?q?1749200031390276775?= |
Series |
gpiolib: of: Use correct fwnode for DT-probed chips
|
|
Commit Message
Thierry Reding
Nov. 11, 2022, 11:37 a.m. UTC
From: Thierry Reding <treding@nvidia.com> The OF node store in chip->fwnode is used to explicitly override the FW node for a GPIO chip. For chips that use the default FW node (i.e. that of their parent device), this will be NULL and cause the chip not to be fully registered. Instead, use the GPIO device's FW node, which is set to either the node of the parent device or the explicit override in chip->fwnode. Fixes: 8afe82550240 ("gpiolib: of: Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode") Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Signed-off-by: Thierry Reding <treding@nvidia.com> --- drivers/gpio/gpiolib-of.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Comments
On Fri, Nov 11, 2022 at 12:37:32PM +0100, Thierry Reding wrote: > From: Thierry Reding <treding@nvidia.com> > > The OF node store in chip->fwnode is used to explicitly override the FW > node for a GPIO chip. For chips that use the default FW node (i.e. that > of their parent device), this will be NULL and cause the chip not to be > fully registered. > > Instead, use the GPIO device's FW node, which is set to either the node > of the parent device or the explicit override in chip->fwnode. Thank you! Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> P.S. It's good we have this report, which means I have to reconsider the followup I'm cooking. In any case I will send it after v6.2-rc1 for broader testing. > Fixes: 8afe82550240 ("gpiolib: of: Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode") > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> > Signed-off-by: Thierry Reding <treding@nvidia.com> > --- > drivers/gpio/gpiolib-of.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c > index 4be3c21aa718..55c3712592db 100644 > --- a/drivers/gpio/gpiolib-of.c > +++ b/drivers/gpio/gpiolib-of.c > @@ -1067,7 +1067,7 @@ int of_gpiochip_add(struct gpio_chip *chip) > struct device_node *np; > int ret; > > - np = to_of_node(chip->fwnode); > + np = to_of_node(dev_fwnode(&chip->gpiodev->dev)); > if (!np) > return 0; > > -- > 2.38.1 >
On Fri, Nov 11, 2022 at 12:37 PM Thierry Reding <thierry.reding@gmail.com> wrote: > From: Thierry Reding <treding@nvidia.com> > > The OF node store in chip->fwnode is used to explicitly override the FW > node for a GPIO chip. For chips that use the default FW node (i.e. that > of their parent device), this will be NULL and cause the chip not to be > fully registered. > > Instead, use the GPIO device's FW node, which is set to either the node > of the parent device or the explicit override in chip->fwnode. > > Fixes: 8afe82550240 ("gpiolib: of: Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode") > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> > Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Linus Walleij <linus.walleij@linaro.org> Yours, Linus Walleij
On Fri, Nov 11, 2022 at 01:45:03PM +0200, Andy Shevchenko wrote: > On Fri, Nov 11, 2022 at 12:37:32PM +0100, Thierry Reding wrote: > > From: Thierry Reding <treding@nvidia.com> > > > > The OF node store in chip->fwnode is used to explicitly override the FW > > node for a GPIO chip. For chips that use the default FW node (i.e. that > > of their parent device), this will be NULL and cause the chip not to be > > fully registered. > > > > Instead, use the GPIO device's FW node, which is set to either the node > > of the parent device or the explicit override in chip->fwnode. > > Thank you! > > Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> > > P.S. > It's good we have this report, which means I have to reconsider the > followup I'm cooking. In any case I will send it after v6.2-rc1 for > broader testing. Feel free to add me on Cc if you need the patches tested on OF systems. Thierry
On 11. 11. 2022. 12:37, Thierry Reding wrote: > From: Thierry Reding <treding@nvidia.com> > > The OF node store in chip->fwnode is used to explicitly override the FW > node for a GPIO chip. For chips that use the default FW node (i.e. that > of their parent device), this will be NULL and cause the chip not to be > fully registered. > > Instead, use the GPIO device's FW node, which is set to either the node > of the parent device or the explicit override in chip->fwnode. > > Fixes: 8afe82550240 ("gpiolib: of: Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode") > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> > Signed-off-by: Thierry Reding <treding@nvidia.com> Hi, I can confirm this fixes the blamed commit on Qualcomm IPQ8074. Tested-by: Robert Marko <robimarko@gmail.com> > --- > drivers/gpio/gpiolib-of.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c > index 4be3c21aa718..55c3712592db 100644 > --- a/drivers/gpio/gpiolib-of.c > +++ b/drivers/gpio/gpiolib-of.c > @@ -1067,7 +1067,7 @@ int of_gpiochip_add(struct gpio_chip *chip) > struct device_node *np; > int ret; > > - np = to_of_node(chip->fwnode); > + np = to_of_node(dev_fwnode(&chip->gpiodev->dev)); > if (!np) > return 0; >
On Fri, Nov 11, 2022 at 12:37:32PM +0100, Thierry Reding wrote: > From: Thierry Reding <treding@nvidia.com> > > The OF node store in chip->fwnode is used to explicitly override the FW > node for a GPIO chip. For chips that use the default FW node (i.e. that > of their parent device), this will be NULL and cause the chip not to be > fully registered. > > Instead, use the GPIO device's FW node, which is set to either the node > of the parent device or the explicit override in chip->fwnode. > > Fixes: 8afe82550240 ("gpiolib: of: Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode") > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> > Signed-off-by: Thierry Reding <treding@nvidia.com> Tested-by: Andrew Halaney <ahalaney@redhat.com> This fixes issues I ran into today on my sa8540p-ride board. Thanks, Andrew > --- > drivers/gpio/gpiolib-of.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c > index 4be3c21aa718..55c3712592db 100644 > --- a/drivers/gpio/gpiolib-of.c > +++ b/drivers/gpio/gpiolib-of.c > @@ -1067,7 +1067,7 @@ int of_gpiochip_add(struct gpio_chip *chip) > struct device_node *np; > int ret; > > - np = to_of_node(chip->fwnode); > + np = to_of_node(dev_fwnode(&chip->gpiodev->dev)); > if (!np) > return 0; > > -- > 2.38.1 >
On Fri, Nov 11, 2022 at 12:37:32PM +0100, Thierry Reding wrote: > From: Thierry Reding <treding@nvidia.com> > > The OF node store in chip->fwnode is used to explicitly override the FW > node for a GPIO chip. For chips that use the default FW node (i.e. that > of their parent device), this will be NULL and cause the chip not to be > fully registered. > > Instead, use the GPIO device's FW node, which is set to either the node > of the parent device or the explicit override in chip->fwnode. > > Fixes: 8afe82550240 ("gpiolib: of: Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode") > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> > Signed-off-by: Thierry Reding <treding@nvidia.com> Reviewed-by: Brian Masney <bmasney@redhat.com> Tested-by: Brian Masney <bmasney@redhat.com> I separately sent a similar type of patch to fix the same issue today: https://lore.kernel.org/linux-arm-msm/20221114202943.2389489-1-bmasney@redhat.com/T/#u I'm still not sure what caused this breakage in linux-next. Brian
Hi Thierry, On Fri, Nov 11, 2022 at 12:40 PM Thierry Reding <thierry.reding@gmail.com> wrote: > From: Thierry Reding <treding@nvidia.com> > > The OF node store in chip->fwnode is used to explicitly override the FW > node for a GPIO chip. For chips that use the default FW node (i.e. that > of their parent device), this will be NULL and cause the chip not to be > fully registered. > > Instead, use the GPIO device's FW node, which is set to either the node > of the parent device or the explicit override in chip->fwnode. > > Fixes: 8afe82550240 ("gpiolib: of: Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode") Thank you, I bisected boot failures on Renesas platforms to that commit, and then found your patch. > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> > Signed-off-by: Thierry Reding <treding@nvidia.com> Tested-by: Geert Uytterhoeven <geert+renesas@glider.be> > --- > drivers/gpio/gpiolib-of.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c > index 4be3c21aa718..55c3712592db 100644 > --- a/drivers/gpio/gpiolib-of.c > +++ b/drivers/gpio/gpiolib-of.c > @@ -1067,7 +1067,7 @@ int of_gpiochip_add(struct gpio_chip *chip) > struct device_node *np; > int ret; > > - np = to_of_node(chip->fwnode); > + np = to_of_node(dev_fwnode(&chip->gpiodev->dev)); > if (!np) > return 0; > Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
On 2022-11-14 16:15:25, Brian Masney wrote: > On Fri, Nov 11, 2022 at 12:37:32PM +0100, Thierry Reding wrote: > > From: Thierry Reding <treding@nvidia.com> > > > > The OF node store in chip->fwnode is used to explicitly override the FW > > node for a GPIO chip. For chips that use the default FW node (i.e. that > > of their parent device), this will be NULL and cause the chip not to be > > fully registered. > > > > Instead, use the GPIO device's FW node, which is set to either the node > > of the parent device or the explicit override in chip->fwnode. > > > > Fixes: 8afe82550240 ("gpiolib: of: Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode") > > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> > > Signed-off-by: Thierry Reding <treding@nvidia.com> > > Reviewed-by: Brian Masney <bmasney@redhat.com> > Tested-by: Brian Masney <bmasney@redhat.com> > > I separately sent a similar type of patch to fix the same issue today: > https://lore.kernel.org/linux-arm-msm/20221114202943.2389489-1-bmasney@redhat.com/T/#u For completeness, your linked patch fixes a synchronous external abort on multiple Qualcomm platforms pointed out in [1]. This patch however does not, are you sure they fix the exact same issue? [1]: https://lore.kernel.org/linux-arm-msm/20221115110800.35gl3j43lmbxm3jb@SoMainline.org/ - Marijn
On Tue, Nov 15, 2022 at 12:18:00PM +0100, Marijn Suijten wrote: > On 2022-11-14 16:15:25, Brian Masney wrote: > > On Fri, Nov 11, 2022 at 12:37:32PM +0100, Thierry Reding wrote: > > > From: Thierry Reding <treding@nvidia.com> > > > > > > The OF node store in chip->fwnode is used to explicitly override the FW > > > node for a GPIO chip. For chips that use the default FW node (i.e. that > > > of their parent device), this will be NULL and cause the chip not to be > > > fully registered. > > > > > > Instead, use the GPIO device's FW node, which is set to either the node > > > of the parent device or the explicit override in chip->fwnode. > > > > > > Fixes: 8afe82550240 ("gpiolib: of: Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode") > > > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> > > > Signed-off-by: Thierry Reding <treding@nvidia.com> > > > > Reviewed-by: Brian Masney <bmasney@redhat.com> > > Tested-by: Brian Masney <bmasney@redhat.com> > > > > I separately sent a similar type of patch to fix the same issue today: > > https://lore.kernel.org/linux-arm-msm/20221114202943.2389489-1-bmasney@redhat.com/T/#u > > For completeness, your linked patch fixes a synchronous external abort > on multiple Qualcomm platforms pointed out in [1]. This patch however > does not, are you sure they fix the exact same issue? > > [1]: https://lore.kernel.org/linux-arm-msm/20221115110800.35gl3j43lmbxm3jb@SoMainline.org/ Thierry's patch fixes the issue that I encountered in of_gpiochip_match_node_and_xlate() on the Qualcomm sa8540p automotive board. I don't get the stack dump that you encountered. I am having issues with probe deferrals on UFS when trying to acquire the reset-gpio. The patch I posted feels hacky (hence the RFC) but if the maintainers agree with it then I can clean up the commit message and post a v2. Brian
On Fri, Nov 11, 2022 at 12:37 PM Thierry Reding <thierry.reding@gmail.com> wrote: > > From: Thierry Reding <treding@nvidia.com> > > The OF node store in chip->fwnode is used to explicitly override the FW > node for a GPIO chip. For chips that use the default FW node (i.e. that > of their parent device), this will be NULL and cause the chip not to be > fully registered. > > Instead, use the GPIO device's FW node, which is set to either the node > of the parent device or the explicit override in chip->fwnode. > > Fixes: 8afe82550240 ("gpiolib: of: Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode") > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> > Signed-off-by: Thierry Reding <treding@nvidia.com> > --- > drivers/gpio/gpiolib-of.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c > index 4be3c21aa718..55c3712592db 100644 > --- a/drivers/gpio/gpiolib-of.c > +++ b/drivers/gpio/gpiolib-of.c > @@ -1067,7 +1067,7 @@ int of_gpiochip_add(struct gpio_chip *chip) > struct device_node *np; > int ret; > > - np = to_of_node(chip->fwnode); > + np = to_of_node(dev_fwnode(&chip->gpiodev->dev)); > if (!np) > return 0; > > -- > 2.38.1 > Applied, thanks! Bart
On Tue, Nov 15, 2022 at 12:18:00PM +0100, Marijn Suijten wrote: > On 2022-11-14 16:15:25, Brian Masney wrote: > > On Fri, Nov 11, 2022 at 12:37:32PM +0100, Thierry Reding wrote: > > > From: Thierry Reding <treding@nvidia.com> > > > > > > The OF node store in chip->fwnode is used to explicitly override the FW > > > node for a GPIO chip. For chips that use the default FW node (i.e. that > > > of their parent device), this will be NULL and cause the chip not to be > > > fully registered. > > > > > > Instead, use the GPIO device's FW node, which is set to either the node > > > of the parent device or the explicit override in chip->fwnode. > > > > > > Fixes: 8afe82550240 ("gpiolib: of: Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode") > > > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> > > > Signed-off-by: Thierry Reding <treding@nvidia.com> > > > > Reviewed-by: Brian Masney <bmasney@redhat.com> > > Tested-by: Brian Masney <bmasney@redhat.com> > > > > I separately sent a similar type of patch to fix the same issue today: > > https://lore.kernel.org/linux-arm-msm/20221114202943.2389489-1-bmasney@redhat.com/T/#u > > For completeness, your linked patch fixes a synchronous external abort > on multiple Qualcomm platforms pointed out in [1]. This patch however > does not, are you sure they fix the exact same issue? > > [1]: https://lore.kernel.org/linux-arm-msm/20221115110800.35gl3j43lmbxm3jb@SoMainline.org/ Can you check if the below fixes the MSM issue that you're seeing (applied on top of my earlier patch, though with Brian's reverted temporarily)? Thanks, Thierry --- >8 --- diff --git a/drivers/gpio/gpiolib.c b/drivers/gpio/gpiolib.c index 11fb7ec883e9..d692ad5c5a27 100644 --- a/drivers/gpio/gpiolib.c +++ b/drivers/gpio/gpiolib.c @@ -447,10 +447,11 @@ static unsigned long *gpiochip_allocate_mask(struct gpio_chip *gc) static unsigned int gpiochip_count_reserved_ranges(struct gpio_chip *gc) { + struct fwnode_handle *fwnode = dev_fwnode(&gc->gpiodev->dev); int size; /* Format is "start, count, ..." */ - size = fwnode_property_count_u32(gc->fwnode, "gpio-reserved-ranges"); + size = fwnode_property_count_u32(fwnode, "gpio-reserved-ranges"); if (size > 0 && size % 2 == 0) return size; @@ -471,6 +472,7 @@ static int gpiochip_alloc_valid_mask(struct gpio_chip *gc) static int gpiochip_apply_reserved_ranges(struct gpio_chip *gc) { + struct fwnode_handle *fwnode = dev_fwnode(&gc->gpiodev->dev); unsigned int size; u32 *ranges; int ret; @@ -483,7 +485,7 @@ static int gpiochip_apply_reserved_ranges(struct gpio_chip *gc) if (!ranges) return -ENOMEM; - ret = fwnode_property_read_u32_array(gc->fwnode, "gpio-reserved-ranges", ranges, size); + ret = fwnode_property_read_u32_array(fwnode, "gpio-reserved-ranges", ranges, size); if (ret) { kfree(ranges); return ret; --- >8 ---
On Wed, Nov 16, 2022 at 11:26:34AM +0100, Thierry Reding wrote: > On Tue, Nov 15, 2022 at 12:18:00PM +0100, Marijn Suijten wrote: > > On 2022-11-14 16:15:25, Brian Masney wrote: > > > On Fri, Nov 11, 2022 at 12:37:32PM +0100, Thierry Reding wrote: > > > > From: Thierry Reding <treding@nvidia.com> > > > > > > > > The OF node store in chip->fwnode is used to explicitly override the FW > > > > node for a GPIO chip. For chips that use the default FW node (i.e. that > > > > of their parent device), this will be NULL and cause the chip not to be > > > > fully registered. > > > > > > > > Instead, use the GPIO device's FW node, which is set to either the node > > > > of the parent device or the explicit override in chip->fwnode. > > > > > > > > Fixes: 8afe82550240 ("gpiolib: of: Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode") > > > > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> > > > > Signed-off-by: Thierry Reding <treding@nvidia.com> > > > > > > Reviewed-by: Brian Masney <bmasney@redhat.com> > > > Tested-by: Brian Masney <bmasney@redhat.com> > > > > > > I separately sent a similar type of patch to fix the same issue today: > > > https://lore.kernel.org/linux-arm-msm/20221114202943.2389489-1-bmasney@redhat.com/T/#u > > > > For completeness, your linked patch fixes a synchronous external abort > > on multiple Qualcomm platforms pointed out in [1]. This patch however > > does not, are you sure they fix the exact same issue? Yes, they fix the same issue. > > [1]: https://lore.kernel.org/linux-arm-msm/20221115110800.35gl3j43lmbxm3jb@SoMainline.org/ > > Can you check if the below fixes the MSM issue that you're seeing > (applied on top of my earlier patch, though with Brian's reverted > temporarily)? I don't know why we would need this. Brian's patch (already applied into GPIO tree) is correct, no? (Moreover, it makes yours unneeded, but I'm fine with having it anyway.)
On Wed, Nov 16, 2022 at 12:38:24PM +0200, Andy Shevchenko wrote: > On Wed, Nov 16, 2022 at 11:26:34AM +0100, Thierry Reding wrote: > > On Tue, Nov 15, 2022 at 12:18:00PM +0100, Marijn Suijten wrote: > > > On 2022-11-14 16:15:25, Brian Masney wrote: > > > > On Fri, Nov 11, 2022 at 12:37:32PM +0100, Thierry Reding wrote: > > > > > From: Thierry Reding <treding@nvidia.com> > > > > > > > > > > The OF node store in chip->fwnode is used to explicitly override the FW > > > > > node for a GPIO chip. For chips that use the default FW node (i.e. that > > > > > of their parent device), this will be NULL and cause the chip not to be > > > > > fully registered. > > > > > > > > > > Instead, use the GPIO device's FW node, which is set to either the node > > > > > of the parent device or the explicit override in chip->fwnode. > > > > > > > > > > Fixes: 8afe82550240 ("gpiolib: of: Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode") > > > > > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> > > > > > Signed-off-by: Thierry Reding <treding@nvidia.com> > > > > > > > > Reviewed-by: Brian Masney <bmasney@redhat.com> > > > > Tested-by: Brian Masney <bmasney@redhat.com> > > > > > > > > I separately sent a similar type of patch to fix the same issue today: > > > > https://lore.kernel.org/linux-arm-msm/20221114202943.2389489-1-bmasney@redhat.com/T/#u > > > > > > For completeness, your linked patch fixes a synchronous external abort > > > on multiple Qualcomm platforms pointed out in [1]. This patch however > > > does not, are you sure they fix the exact same issue? > > Yes, they fix the same issue. > > > > [1]: https://lore.kernel.org/linux-arm-msm/20221115110800.35gl3j43lmbxm3jb@SoMainline.org/ > > > > Can you check if the below fixes the MSM issue that you're seeing > > (applied on top of my earlier patch, though with Brian's reverted > > temporarily)? > > I don't know why we would need this. Brian's patch (already applied into > GPIO tree) is correct, no? (Moreover, it makes yours unneeded, but I'm fine > with having it anyway.) I've explained this in the reply to Brian's patch, but I don't think we want to use gc->fwnode other than initially to override the fwnode that the GPIO chip uses. It might even be worth turning it into a parameter to gpiochip_add() to avoid the ambiguity we have right now where we store the same fwnode in two different places and end up using either depending on whoever wrote the patch and what mood they were in. There really should only be one place to store this pointer to avoid this sort of ambiguity. Thierry
On 2022-11-16 11:26:34, Thierry Reding wrote: > On Tue, Nov 15, 2022 at 12:18:00PM +0100, Marijn Suijten wrote: > > On 2022-11-14 16:15:25, Brian Masney wrote: > > > On Fri, Nov 11, 2022 at 12:37:32PM +0100, Thierry Reding wrote: > > > > From: Thierry Reding <treding@nvidia.com> > > > > > > > > The OF node store in chip->fwnode is used to explicitly override the FW > > > > node for a GPIO chip. For chips that use the default FW node (i.e. that > > > > of their parent device), this will be NULL and cause the chip not to be > > > > fully registered. > > > > > > > > Instead, use the GPIO device's FW node, which is set to either the node > > > > of the parent device or the explicit override in chip->fwnode. > > > > > > > > Fixes: 8afe82550240 ("gpiolib: of: Prepare of_gpiochip_add() / of_gpiochip_remove() for fwnode") > > > > Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> > > > > Signed-off-by: Thierry Reding <treding@nvidia.com> > > > > > > Reviewed-by: Brian Masney <bmasney@redhat.com> > > > Tested-by: Brian Masney <bmasney@redhat.com> > > > > > > I separately sent a similar type of patch to fix the same issue today: > > > https://lore.kernel.org/linux-arm-msm/20221114202943.2389489-1-bmasney@redhat.com/T/#u > > > > For completeness, your linked patch fixes a synchronous external abort > > on multiple Qualcomm platforms pointed out in [1]. This patch however > > does not, are you sure they fix the exact same issue? > > > > [1]: https://lore.kernel.org/linux-arm-msm/20221115110800.35gl3j43lmbxm3jb@SoMainline.org/ > > Can you check if the below fixes the MSM issue that you're seeing > (applied on top of my earlier patch, though with Brian's reverted > temporarily)? Yes that solves it too, thanks! - Marijn
diff --git a/drivers/gpio/gpiolib-of.c b/drivers/gpio/gpiolib-of.c index 4be3c21aa718..55c3712592db 100644 --- a/drivers/gpio/gpiolib-of.c +++ b/drivers/gpio/gpiolib-of.c @@ -1067,7 +1067,7 @@ int of_gpiochip_add(struct gpio_chip *chip) struct device_node *np; int ret; - np = to_of_node(chip->fwnode); + np = to_of_node(dev_fwnode(&chip->gpiodev->dev)); if (!np) return 0;