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 4F30CC636D3 for ; Tue, 31 Jan 2023 01:20:46 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230240AbjAaBUp (ORCPT ); Mon, 30 Jan 2023 20:20:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45746 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230221AbjAaBUo (ORCPT ); Mon, 30 Jan 2023 20:20:44 -0500 Received: from mail-pf1-x433.google.com (mail-pf1-x433.google.com [IPv6:2607:f8b0:4864:20::433]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 88E4911145 for ; Mon, 30 Jan 2023 17:20:42 -0800 (PST) Received: by mail-pf1-x433.google.com with SMTP id j20so2535544pfj.0 for ; Mon, 30 Jan 2023 17:20:42 -0800 (PST) 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:subject:date:message-id:reply-to; bh=WlKnm9SlBY6a95G31ugIPx75GFY5lk/gBJScYr6B/MA=; b=D9rmez0+kSKL3ccFg9a8F7AC1nKa00vADDYdszu9EH8DheWWLli6rK5KQG+m5BDTun lBN3WiydFkh0tenV2406XKnQtMRh6xc6n2fE0ebr1WQaK0U9SEeflAszPpkaoEczXCPa XnJ1zqvgyNwoi6VrgYqpbxCLOgDdxcvws0ZfwlT70OkOSwwYd8pazHEn/kuiJtYM22J7 kOf9lJua0c/fv0pyYlG9F4HJa3jGoahD9mRdj1+isxbekM65F/g6qDG8KyLMcWDQWG6+ R8T2lbX2UzZVK83BTDKWSVk4xIjaABA2PMQlvA9tQVzbLSueVsWJKDQjFrANX9n7Nu8n auYg== 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:subject:date:message-id :reply-to; bh=WlKnm9SlBY6a95G31ugIPx75GFY5lk/gBJScYr6B/MA=; b=ZgNP2BMv0J6yteWOEuMhTtyG1W8P4Wt+zPyuD2LhdhyFFVPQV1TNuZKz7uuDXAMT/J yhCegMfz6mSz18SIx1aISqV/MSH1AcIZM5IopfcU2ir5DiBpRimP8fonuR24D2VAWNDH WQ93ecGMUOHOqbVzKloqWEV3XY4An8lG8fwXJrz+TMPdwKE3s3WPdc/eEKy5RL0Dqzxj OikwriYSqI6b0yWaLf6aenq5ZaQi4WfSvl+JcnZlxWXH6oYXqodoUWLVQCIjYj9STYAr OjnoCEYGfGFuHClygw8dHHIQrTcVfm1BNQ+gWyXwDpkbws+Usi7UxvMMAQLhaLghmBMg FOVw== X-Gm-Message-State: AO0yUKV3EeXpNHSzohmATiwNIUdZnofkG3LV7nzM0bBNznr52ksV2hvU yx8qTm7XeImh0daMCy4UCABXLiZB+IBbBR09IXSYyQ== X-Google-Smtp-Source: AK7set/OnrysWGmShNaN4ttMAIR9UncJ4m1eUuwNep1bR9GutY4sRTfWIiOaEY4ReHbIYjKOu7DJxRnva6K27yrlZqg= X-Received: by 2002:aa7:91d3:0:b0:592:61cc:5aeb with SMTP id z19-20020aa791d3000000b0059261cc5aebmr2113642pfa.59.1675128041704; Mon, 30 Jan 2023 17:20:41 -0800 (PST) MIME-Version: 1.0 References: <20230127001141.407071-1-saravanak@google.com> <20230130114839.379f08bd@xps-13> In-Reply-To: From: Saravana Kannan Date: Mon, 30 Jan 2023 17:20:05 -0800 Message-ID: Subject: Re: [PATCH v2 00/11] fw_devlink improvements To: Maxim Kiselev Cc: Miquel Raynal , Greg Kroah-Hartman , "Rafael J. Wysocki" , Sudeep Holla , Cristian Marussi , Linus Walleij , Bartosz Golaszewski , Thomas Gleixner , Marc Zyngier , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Rob Herring , Frank Rowand , Geert Uytterhoeven , Magnus Damm , Len Brown , Andy Shevchenko , Daniel Scally , Heikki Krogerus , Sakari Ailus , Tony Lindgren , Linux Kernel Functional Testing , Naresh Kamboju , Abel Vesa , Alexander Stein , Geert Uytterhoeven , John Stultz , Doug Anderson , Guenter Roeck , Dmitry Baryshkov , Maxim Kochetkov , Luca Weiss , Colin Foster , Martin Kepplinger , Jean-Philippe Brucker , kernel-team@android.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.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, Jan 30, 2023 at 4:09 AM Maxim Kiselev wrote: > > Hi Saravana & Miquel. > > Sorry for the long response. I finally got access to my test device > and tried this patch series. > > And unfortunately it didn't solve my issue. I'm still getting a > hanging f1070000.ethernet dependency > from the nvmem-cell mac@6 subnode. Thanks for testing the series. Btw, don't top post. It's frowned upon. Top post means your reply is on the top before the email you are replying to. See how my first line of reply in inline with your email I'm replying to? > > Here are related parts of my kernel log and device tree: > > > [ 2.713302] device: 'mtd-0': device_add > [ 2.719528] device: 'spi0': device_add > [ 2.724180] device: 'spi0.0': device_add > [ 2.728957] spi-nor spi0.0: mx66l51235f (65536 Kbytes) > [ 2.735338] 7 fixed-partitions partitions found on MTD device spi0.0 > [ 2.741978] device: > 'f1010600.spi:m25p80@0:partitions:partition@1': device_add > [ 2.749636] Creating 7 MTD partitions on "spi0.0": > [ 2.754564] 0x000000000000-0x000000080000 : "SPI.U_BOOT" > [ 2.759981] device: 'mtd0': device_add > [ 2.764323] device: 'mtd0': device_add > [ 2.768280] device: 'mtd0ro': device_add > [ 2.772624] 0x0000000a0000-0x0000000c0000 : "SPI.INV_INFO" > [ 2.778218] device: 'mtd1': device_add > [ 2.782549] device: 'mtd1': device_add > [ 2.786582] device: 'mtd1ro': device_add > ... > [ 5.426625] mvneta_bm f10c0000.bm: Buffer Manager for network > controller enabled > [ 5.492867] platform f1070000.ethernet: error -EPROBE_DEFER: > wait for supplier mac@6 > [ 5.528636] device: 'Fixed MDIO bus.0': device_add > [ 5.533726] device: 'fixed-0': device_add > [ 5.547564] device: 'f1072004.mdio-eth-mii': device_add > [ 5.616368] device: 'f1072004.mdio-eth-mii:00': device_add > [ 5.645127] device: 'f1072004.mdio-eth-mii:1e': device_add > [ 5.651530] devices_kset: Moving f1070000.ethernet to end of list > [ 5.657948] platform f1070000.ethernet: error -EPROBE_DEFER: > wait for supplier mac@6 > > spi@10600 { > m25p80@0 { > compatible = "mx66l51235l"; > > partitions { > compatible = "fixed-partitions"; > > partition@0 { > label = "SPI.U_BOOT"; > }; > partition@1 { > compatible = "nvmem-cells"; > label = "SPI.INV_INFO"; > macaddr: mac@6 { > reg = <0x6 0x6>; > }; > }; > ... > }; > }; > }; > > enet1: ethernet@70000 { > nvmem-cells = <&macaddr>; > nvmem-cell-names = "mac-address"; > phy-mode = "rgmii"; > phy = <&phy0>; > }; > > > Maybe I should provide some additional debug info? I took a look at it and I think I know the issue. But it'll be good if you can point me to the dts (not dtsi) file that corresponds to the board you are seeing this issue on so I can double check my guess by looking at the exact code/drivers. The main problem/mistake is the nvmem framework is using a "struct bus" instead of a "struct class" to keep a list of the nvmem devices. And we can't change it now because it'd affect the sysfs paths significantly and might break userspace ABI. Can you try the patch at the end of this email under these configurations and tell me which ones fail vs pass? I don't need logs for any pass/failures. 1. On top of this series 2. Without this series 3. On top of the series but with the call to fwnode_dev_initialized() deleted? 4. Without this series, but with the call to fwnode_dev_initialized() deleted? -Saravana Sorry about tabs to spaces conversion. Email client issue. diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index 321d7d63e068..23d94c0ecccf 100644 --- a/drivers/nvmem/core.c +++ b/drivers/nvmem/core.c @@ -752,6 +752,7 @@ static int nvmem_add_cells_from_of(struct nvmem_device *nvmem) struct nvmem_device *nvmem_register(const struct nvmem_config *config) { struct nvmem_device *nvmem; + struct fwnode_handle *fwnode; int rval; if (!config->dev) @@ -804,9 +805,18 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config) nvmem->keepout = config->keepout; nvmem->nkeepout = config->nkeepout; if (config->of_node) - nvmem->dev.of_node = config->of_node; + fwnode = of_fwnode_handle(config->of_node); else if (!config->no_of_node) - nvmem->dev.of_node = config->dev->of_node; + fwnode = of_fwnode_handle(config->dev->of_node); + device_set_node(&nvmem->dev, fwnode); + + /* + * If the fwnode doesn't have another device associated with it, mark + * the fwnode as initialized since no driver is going to bind to the + * nvmem. + */ + if (fwnode && !fwnode->dev) + fwnode_dev_initialized(fwnode, true); switch (config->id) { case NVMEM_DEVID_NONE: 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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id B465BC636D3 for ; Tue, 31 Jan 2023 01:22:04 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Cc:To:Subject:Message-ID:Date:From: In-Reply-To:References:MIME-Version:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=W9q1hh1+y472+PQQG0MBf0KTdm0phJxiGnwDZRuDoHU=; b=jdGeRmhLm5wz64 EbRPzygJ2koBYxMnXasHYNI31KjfMI2+XQDslmuVScpgyI7438UWJ4Ep1mS01zcc3nwRaCjiCDlls sk5S3IR4O+aY0veHjRprAnp44K84y03pTRXuPUCloAsHD9d2DPiuXbxWCyfjcIt+3ZRKD7uM7swOB mCWOrbR0H5uHVoA5i3pOdwJB29sgj41UEWplg4gBUmWgcUM5Td8sfzaJiq3G+KuObaQt+HAcWTzj5 w0NBPIo7B3mGPiGOdB+DrAYtL4V4eU5VcAWk9wLZn/xwkt2veoDYZSrB1MUQCYHxatl+ZW4LV9ZO6 b9DW8PYQtM5K376ZSlHQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pMfKM-005zEP-Dn; Tue, 31 Jan 2023 01:20:50 +0000 Received: from mail-pf1-x435.google.com ([2607:f8b0:4864:20::435]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pMfKH-005zDY-Od for linux-arm-kernel@lists.infradead.org; Tue, 31 Jan 2023 01:20:47 +0000 Received: by mail-pf1-x435.google.com with SMTP id 144so9131289pfv.11 for ; Mon, 30 Jan 2023 17:20:42 -0800 (PST) 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:subject:date:message-id:reply-to; bh=WlKnm9SlBY6a95G31ugIPx75GFY5lk/gBJScYr6B/MA=; b=D9rmez0+kSKL3ccFg9a8F7AC1nKa00vADDYdszu9EH8DheWWLli6rK5KQG+m5BDTun lBN3WiydFkh0tenV2406XKnQtMRh6xc6n2fE0ebr1WQaK0U9SEeflAszPpkaoEczXCPa XnJ1zqvgyNwoi6VrgYqpbxCLOgDdxcvws0ZfwlT70OkOSwwYd8pazHEn/kuiJtYM22J7 kOf9lJua0c/fv0pyYlG9F4HJa3jGoahD9mRdj1+isxbekM65F/g6qDG8KyLMcWDQWG6+ R8T2lbX2UzZVK83BTDKWSVk4xIjaABA2PMQlvA9tQVzbLSueVsWJKDQjFrANX9n7Nu8n auYg== 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:subject:date:message-id :reply-to; bh=WlKnm9SlBY6a95G31ugIPx75GFY5lk/gBJScYr6B/MA=; b=dWZ458yhD3U2LbAsBcAOB4StiAUUffgU6A9tAwCn05ynmA8q/eh2Pc03KDpLgKxITy L6DVXOyjRir/gZmJIJZS+sQ33VVsAU41TMLx3RzbHUR4Q7fZM8YBl5iUp8HBv39+gm1N OpIGTCvo6gMMyF//HhtaUdymdzVZaqTIzXaqaumSQj1IPG2jgl6KbYxQUTQZVr19aQBp uAo7gLrg3zCstSQ0OQD4sQNMsfqgAgoHQXWdmBtIFPh0v3HLzVXCRf4McwpNJ20sM/CL vX0SwSZ/JpKUszeCtEjjLVnDp0CIaB2IByK+7BsIwRlx0NyyKvXlKSnZZtLIQ46MaY9k G7LQ== X-Gm-Message-State: AO0yUKUWh1nKjv0gcdKvUSCn/eXhbCCDkJdFvd9/fH74dO8bPAU24z8o +7gY2mAtdP4+TPjWo70QgWNBkohERyCw9AV2C+JV0A== X-Google-Smtp-Source: AK7set/OnrysWGmShNaN4ttMAIR9UncJ4m1eUuwNep1bR9GutY4sRTfWIiOaEY4ReHbIYjKOu7DJxRnva6K27yrlZqg= X-Received: by 2002:aa7:91d3:0:b0:592:61cc:5aeb with SMTP id z19-20020aa791d3000000b0059261cc5aebmr2113642pfa.59.1675128041704; Mon, 30 Jan 2023 17:20:41 -0800 (PST) MIME-Version: 1.0 References: <20230127001141.407071-1-saravanak@google.com> <20230130114839.379f08bd@xps-13> In-Reply-To: From: Saravana Kannan Date: Mon, 30 Jan 2023 17:20:05 -0800 Message-ID: Subject: Re: [PATCH v2 00/11] fw_devlink improvements To: Maxim Kiselev Cc: Miquel Raynal , Greg Kroah-Hartman , "Rafael J. Wysocki" , Sudeep Holla , Cristian Marussi , Linus Walleij , Bartosz Golaszewski , Thomas Gleixner , Marc Zyngier , Shawn Guo , Sascha Hauer , Pengutronix Kernel Team , Fabio Estevam , NXP Linux Team , Rob Herring , Frank Rowand , Geert Uytterhoeven , Magnus Damm , Len Brown , Andy Shevchenko , Daniel Scally , Heikki Krogerus , Sakari Ailus , Tony Lindgren , Linux Kernel Functional Testing , Naresh Kamboju , Abel Vesa , Alexander Stein , Geert Uytterhoeven , John Stultz , Doug Anderson , Guenter Roeck , Dmitry Baryshkov , Maxim Kochetkov , Luca Weiss , Colin Foster , Martin Kepplinger , Jean-Philippe Brucker , kernel-team@android.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org, devicetree@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux-acpi@vger.kernel.org X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230130_172045_828561_0B7CA1A6 X-CRM114-Status: GOOD ( 31.61 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, Jan 30, 2023 at 4:09 AM Maxim Kiselev wrote: > > Hi Saravana & Miquel. > > Sorry for the long response. I finally got access to my test device > and tried this patch series. > > And unfortunately it didn't solve my issue. I'm still getting a > hanging f1070000.ethernet dependency > from the nvmem-cell mac@6 subnode. Thanks for testing the series. Btw, don't top post. It's frowned upon. Top post means your reply is on the top before the email you are replying to. See how my first line of reply in inline with your email I'm replying to? > > Here are related parts of my kernel log and device tree: > > > [ 2.713302] device: 'mtd-0': device_add > [ 2.719528] device: 'spi0': device_add > [ 2.724180] device: 'spi0.0': device_add > [ 2.728957] spi-nor spi0.0: mx66l51235f (65536 Kbytes) > [ 2.735338] 7 fixed-partitions partitions found on MTD device spi0.0 > [ 2.741978] device: > 'f1010600.spi:m25p80@0:partitions:partition@1': device_add > [ 2.749636] Creating 7 MTD partitions on "spi0.0": > [ 2.754564] 0x000000000000-0x000000080000 : "SPI.U_BOOT" > [ 2.759981] device: 'mtd0': device_add > [ 2.764323] device: 'mtd0': device_add > [ 2.768280] device: 'mtd0ro': device_add > [ 2.772624] 0x0000000a0000-0x0000000c0000 : "SPI.INV_INFO" > [ 2.778218] device: 'mtd1': device_add > [ 2.782549] device: 'mtd1': device_add > [ 2.786582] device: 'mtd1ro': device_add > ... > [ 5.426625] mvneta_bm f10c0000.bm: Buffer Manager for network > controller enabled > [ 5.492867] platform f1070000.ethernet: error -EPROBE_DEFER: > wait for supplier mac@6 > [ 5.528636] device: 'Fixed MDIO bus.0': device_add > [ 5.533726] device: 'fixed-0': device_add > [ 5.547564] device: 'f1072004.mdio-eth-mii': device_add > [ 5.616368] device: 'f1072004.mdio-eth-mii:00': device_add > [ 5.645127] device: 'f1072004.mdio-eth-mii:1e': device_add > [ 5.651530] devices_kset: Moving f1070000.ethernet to end of list > [ 5.657948] platform f1070000.ethernet: error -EPROBE_DEFER: > wait for supplier mac@6 > > spi@10600 { > m25p80@0 { > compatible = "mx66l51235l"; > > partitions { > compatible = "fixed-partitions"; > > partition@0 { > label = "SPI.U_BOOT"; > }; > partition@1 { > compatible = "nvmem-cells"; > label = "SPI.INV_INFO"; > macaddr: mac@6 { > reg = <0x6 0x6>; > }; > }; > ... > }; > }; > }; > > enet1: ethernet@70000 { > nvmem-cells = <&macaddr>; > nvmem-cell-names = "mac-address"; > phy-mode = "rgmii"; > phy = <&phy0>; > }; > > > Maybe I should provide some additional debug info? I took a look at it and I think I know the issue. But it'll be good if you can point me to the dts (not dtsi) file that corresponds to the board you are seeing this issue on so I can double check my guess by looking at the exact code/drivers. The main problem/mistake is the nvmem framework is using a "struct bus" instead of a "struct class" to keep a list of the nvmem devices. And we can't change it now because it'd affect the sysfs paths significantly and might break userspace ABI. Can you try the patch at the end of this email under these configurations and tell me which ones fail vs pass? I don't need logs for any pass/failures. 1. On top of this series 2. Without this series 3. On top of the series but with the call to fwnode_dev_initialized() deleted? 4. Without this series, but with the call to fwnode_dev_initialized() deleted? -Saravana Sorry about tabs to spaces conversion. Email client issue. diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index 321d7d63e068..23d94c0ecccf 100644 --- a/drivers/nvmem/core.c +++ b/drivers/nvmem/core.c @@ -752,6 +752,7 @@ static int nvmem_add_cells_from_of(struct nvmem_device *nvmem) struct nvmem_device *nvmem_register(const struct nvmem_config *config) { struct nvmem_device *nvmem; + struct fwnode_handle *fwnode; int rval; if (!config->dev) @@ -804,9 +805,18 @@ struct nvmem_device *nvmem_register(const struct nvmem_config *config) nvmem->keepout = config->keepout; nvmem->nkeepout = config->nkeepout; if (config->of_node) - nvmem->dev.of_node = config->of_node; + fwnode = of_fwnode_handle(config->of_node); else if (!config->no_of_node) - nvmem->dev.of_node = config->dev->of_node; + fwnode = of_fwnode_handle(config->dev->of_node); + device_set_node(&nvmem->dev, fwnode); + + /* + * If the fwnode doesn't have another device associated with it, mark + * the fwnode as initialized since no driver is going to bind to the + * nvmem. + */ + if (fwnode && !fwnode->dev) + fwnode_dev_initialized(fwnode, true); switch (config->id) { case NVMEM_DEVID_NONE: _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel