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 45472C2BB43 for ; Tue, 16 Aug 2022 05:01:53 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233412AbiHPFBv (ORCPT ); Tue, 16 Aug 2022 01:01:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:40986 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234734AbiHPFB1 (ORCPT ); Tue, 16 Aug 2022 01:01:27 -0400 Received: from mail-yw1-x1133.google.com (mail-yw1-x1133.google.com [IPv6:2607:f8b0:4864:20::1133]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 811115005F for ; Mon, 15 Aug 2022 13:56:44 -0700 (PDT) Received: by mail-yw1-x1133.google.com with SMTP id 00721157ae682-3246910dac3so102820637b3.12 for ; Mon, 15 Aug 2022 13:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=D0fn3micXKWrfIVT3rhbLog8MKgivLXDeSRBFlVQCe0=; b=pWNCA5tjhz3ifbg/zoi8mxeHNbQqyS6Wr+tkXqszwau/3juKJt1cJiDeWd/xTUYikf 3m+lUs8TRS/ONqZP2kr37pSkam/ltj8dFUHNbQSVUtOocrZd8kNivuozAsPDZGUebja5 8qoXrSub6bi/48WY6kMdn5wD62DzaKBuNTtBjPgC1vqE2ofoH7+pemKiSTDhtCXK+BKg tM0mwmFWdjDKI5x8PolzvWsp9Wa9f7ueMXN26rQ8TanPpj13nakHNrDAbc0WTCILPcKm sITU3U2AXFoq3SQH3e7W+zw/P6tvdNfqQuIWIBXSOdodHIwUTxZT8vAAFSIly2OhmtPn X4/w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=D0fn3micXKWrfIVT3rhbLog8MKgivLXDeSRBFlVQCe0=; b=HJvanz6DiyOvrPVkCPvu+Db9QcUggbAtqnFtjpcnT0AEqOmmHAB7dz/EUK8aRh/3W9 39jzgjZhZSOu2pxUdQZMa7irN4zLVUmQFVLkCzXinXi+Ezoh/4tZ5xoQj1NDOETBfFWc eXSzYTQmhrONlV+EXQ/mezvYKLOwbE+lPi/8VaqrEMk0JAwhIXszVYqjcmxRQYdojQwf ykn3d8vjVlSaxz9XDEr4Z+vbBk3OcxaQzN1cf+JUFxpahFtpT9KpP42G0x36FKz5OuMr WVdWJpPc58VE00uOGJZjTvEpYvEdHQ5RzyPJY2LtilVeQYpUAk1BymHuH2/Oj0wUCHWT KRgQ== X-Gm-Message-State: ACgBeo3fLFt9tLwOKoNuyQFNtmuUK0RmK338zq6+12cVHOs0wnHMZG+W BDljO4poTUiZNE30I62+0p4CxFLdO5wOQv7dEXnVQA== X-Google-Smtp-Source: AA6agR4LEloPmUVOkPnMV81xQJEVCPf91bSwXVvWmCOFrRCoq8LfZMc0EKGNipgQdo+jv9Jrr6eZZKs9QGFjnp+Twkw= X-Received: by 2002:a0d:efc1:0:b0:32a:8e40:cd70 with SMTP id y184-20020a0defc1000000b0032a8e40cd70mr14737568ywe.83.1660597003258; Mon, 15 Aug 2022 13:56:43 -0700 (PDT) MIME-Version: 1.0 References: <20220810060040.321697-1-saravanak@google.com> <3601760.iIbC2pHGDl@steina-w> In-Reply-To: From: Saravana Kannan Date: Mon, 15 Aug 2022 13:56:07 -0700 Message-ID: Subject: Re: [PATCH v1 0/9] fw_devlink improvements To: Alexander Stein Cc: Greg Kroah-Hartman , "Rafael J. Wysocki" , Linus Walleij , Bartosz Golaszewski , Rob Herring , Frank Rowand , Geert Uytterhoeven , Magnus Damm , Andy Shevchenko , Daniel Scally , Heikki Krogerus , Sakari Ailus , Len Brown , Abel Vesa , Tony Lindgren , Sudeep Holla , Geert Uytterhoeven , John Stultz , Doug Anderson , Guenter Roeck , kernel-team@android.com, linux-kernel@vger.kernel.org, linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-acpi@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org On Mon, Aug 15, 2022 at 12:17 PM Saravana Kannan wrote: > > On Mon, Aug 15, 2022 at 5:39 AM Alexander Stein > wrote: > > > > Hello Saravana, > > > > Am Mittwoch, 10. August 2022, 08:00:29 CEST schrieb Saravana Kannan: > > > Alexander, > > > > > > This should fix your issue where the power domain device not having a > > > compatible property. Can you give it a shot please? > > > > thanks for the update. Unfortunately this does not work: > > > > > [ 0.774838] PM: Added domain provider from /soc@0/bus@30000000/ > > gpc@303a0000/pgc/power-domain@0 > > > [ 0.775100] imx-pgc imx-pgc-domain.1: __genpd_dev_pm_attach() failed to > > find PM domain: -2 > > > [ 0.775324] PM: Added domain provider from /soc@0/bus@30000000/ > > gpc@303a0000/pgc/power-domain@2 > > > [ 0.775601] PM: Added domain provider from /soc@0/bus@30000000/ > > gpc@303a0000/pgc/power-domain@3 > > > [ 0.775842] PM: Added domain provider from /soc@0/bus@30000000/ > > gpc@303a0000/pgc/power-domain@4 > > > [ 0.776642] PM: Added domain provider from /soc@0/bus@30000000/ > > gpc@303a0000/pgc/power-domain@7 > > > [ 0.776897] PM: Added domain provider from /soc@0/bus@30000000/ > > gpc@303a0000/pgc/power-domain@8 > > > [ 0.777158] PM: Added domain provider from /soc@0/bus@30000000/ > > gpc@303a0000/pgc/power-domain@9 > > > [ 0.777405] PM: Added domain provider from /soc@0/bus@30000000/ > > gpc@303a0000/pgc/power-domain@a > > > [ 0.779342] genpd genpd:0:38320000.blk-ctrl: __genpd_dev_pm_attach() > > failed to find PM domain: -2 > > > [ 0.779422] imx8m-blk-ctrl 38320000.blk-ctrl: error -ENODEV: failed to > > attach power domain "bus" > > > [ 0.848785] etnaviv-gpu 38000000.gpu: __genpd_dev_pm_attach() failed to > > find PM domain: -2 > > > [ 1.114220] pfuze100-regulator 0-0008: Full layer: 2, Metal layer: 1 > > > [ 1.122267] pfuze100-regulator 0-0008: FAB: 0, FIN: 0 > > > [ 1.132970] pfuze100-regulator 0-0008: pfuze100 found. > > > [ 1.157011] imx-gpcv2 303a0000.gpc: Failed to create device link with > > 0-0008 > > > [ 1.164094] imx-gpcv2 303a0000.gpc: Failed to create device link with > > 0-0008 > > > > The required power-supply for the power domains is still not yet available. > > Does this series require some other patches as well? > > Ah sorry, yeah, this needs additional patches. The one I gave in the > other thread when I debugged this and I also noticed another issue. > Here's the combined diff of what's needed. Can you add this on top of > the series and test it? > > diff --git a/drivers/irqchip/irq-imx-gpcv2.c b/drivers/irqchip/irq-imx-gpcv2.c > index b9c22f764b4d..8a0e82067924 100644 > --- a/drivers/irqchip/irq-imx-gpcv2.c > +++ b/drivers/irqchip/irq-imx-gpcv2.c > @@ -283,6 +283,7 @@ static int __init imx_gpcv2_irqchip_init(struct > device_node *node, > * later the GPC power domain driver will not be skipped. > */ > of_node_clear_flag(node, OF_POPULATED); > + fwnode_dev_initialized(domain->fwnode, false); > return 0; > } > > diff --git a/drivers/soc/imx/gpcv2.c b/drivers/soc/imx/gpcv2.c > index 6383a4edc360..181fbfe5bd4d 100644 > --- a/drivers/soc/imx/gpcv2.c > +++ b/drivers/soc/imx/gpcv2.c > @@ -1513,6 +1513,7 @@ static int imx_gpcv2_probe(struct platform_device *pdev) > > pd_pdev->dev.parent = dev; > pd_pdev->dev.of_node = np; > + pd_pdev->dev.fwnode = of_fwnode_handle(np); > > ret = platform_device_add(pd_pdev); > if (ret) { > > With this patch, I'd really expect the power domain dependency to be > handled correctly. > > > Whats worse, starting with commit 9/9 [of: property: Simplify > > of_link_to_phandle()], other drivers fail to probe waiting for pinctrl to be > > available. > > Heh, Patch 9/9 and all its other dependencies in this series was to > fix your use case. Ironic that it's causing you more issues. > > > > $ cat /sys/kernel/debug/devices_deferred > > > gpio-leds platform: wait for supplier gpioledgrp > > > extcon-usbotg0 platform: wait for supplier usb0congrp > > > gpio-keys platform: wait for supplier gpiobuttongrp > > > regulator-otg-vbus platform: wait for supplier reggotgvbusgrp > > > regulator-vdd-arm platform: wait for supplier dvfsgrp > > > > Apparently for some reason they are not probed again, once the pinctrl driver > > probed. > > I'm hoping that this is just some issue due to the missing patch > above, but doesn't sound like it if you say that the pinctrl ended up > probing eventually. > > So when device_links_driver_bound() calls > __fw_devlink_pickup_dangling_consumers(), it should have picked up the > consumers of node like gpiobuttongrp and moved it to the pinctrl > device. And right after that we call __fw_devlink_link_to_consumers() > that would have created the device links. And then right after that, > we go through all the consumers and add them to the deferred probe > list. After that deferred probe should have run... either because it's > enabled at late_initcall() or because a new device probed > successfully. > > Can you check which one of my expectations isn't true in your case? Actually I have a hypothesis on what might be happening. It could be a case of the consumer device getting added after the supplier has been initialized. If the patch above doesn't fix everything, can you add this diff on top of the patch above and see if that fixes everything? If it fixes the pinctrl issue, can you check my hypothesis be checking in what order the devices get added and get probed? diff --git a/drivers/base/core.c b/drivers/base/core.c index 2f012e826986..866755d8ad95 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -2068,7 +2068,11 @@ static int fw_devlink_create_devlink(struct device *con, device_links_write_unlock(); } - sup_dev = get_dev_from_fwnode(sup_handle); + if (sup_handle->flags & FWNODE_FLAG_NOT_DEVICE) + sup_dev = fwnode_get_next_parent_dev(sup_handle); + else + sup_dev = get_dev_from_fwnode(sup_handle); + if (sup_dev) { /* * If it's one of those drivers that don't actually bind to Thanks, Saravana