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 9874EC63797 for ; Tue, 31 Jan 2023 01:20:47 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230257AbjAaBUp (ORCPT ); Mon, 30 Jan 2023 20:20:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45742 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229489AbjAaBUn (ORCPT ); Mon, 30 Jan 2023 20:20:43 -0500 Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 861AE10ABA for ; Mon, 30 Jan 2023 17:20:42 -0800 (PST) Received: by mail-pf1-x42f.google.com with SMTP id u5so8816218pfm.10 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=mYQlWEhmBm5aPXkkQKSGxe6Uh4IfzjhCZ4Euj8qar/OSy1nRI8QV1Rv+J4IZrnHw6c sASQUZ5OT8e+E9f4Gxd24pX8TTdlomJWYQIdcGK+YzvWKubzcv8/leRV6HpK2pVYaYkW V4bW3I92quHRAwOgMvYLopHbCnYDlp+5jJK849iXVecJ68MeounW9Rztfxbx5wZ0NZJx 3K5OZT3+dY2ysyecMceAFkmDgvnrR5TEmc0K3vx3Lgwrg7Lo8QIdeP15SRwfdH+xaz57 3KOOpCAg+eNYJrhT9t9+5YE2utd+naoIsPAsDbmKw3zR1ktVkwWeZo7zOjbSBP9svWNB kAXA== X-Gm-Message-State: AO0yUKWZJUvwtZxOijMja1VyLOonR7HLyZg33SDc71NKXYt33bNvx982 CbciNDigEGmJapZvcYw030OudK8X1GfbDfGc/Djc6Q== 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-kernel@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: