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 820FDC61DA4 for ; Thu, 2 Feb 2023 17:36:30 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231237AbjBBRg3 (ORCPT ); Thu, 2 Feb 2023 12:36:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56906 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230373AbjBBRg3 (ORCPT ); Thu, 2 Feb 2023 12:36:29 -0500 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 9CDB329409; Thu, 2 Feb 2023 09:36:27 -0800 (PST) Received: by mail-ed1-x535.google.com with SMTP id z11so2807171ede.1; Thu, 02 Feb 2023 09:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=/HioFfeJdcxYRSIePrk0xPeneN7bTewVzuuGNUxyF+Q=; b=DgYe/MckqiMlJv5lX6qtOy2RdSlf9HWoVcWPf1C5A9ll+SRh7voCyz+NA64bhzh+6/ s6mvdEEKfye26uhEJ23ipwJr8a1qpBHq2v8E1UNx3Kjua7yEJBM1lVMSWb7l5t4afwPX NC8Ngx0j3yd+p+rWO5aBYsOU6K0KVHnSRrS4OC8T+e1TqldTsGc0awMKVV7I7kIlqXM1 UZDPQrrR0l2mmgiBijgpcJMKDpPzpRpNQ/Dx9ap2wWz77ECUrTvDzHZH/LuGcXempTwQ VIYpEcFp/DDcRU0BBLCdKwGsD1XFx66gOy31SAxiBmBrOEU453nRjdZ0cq+Rjhp6xSQo KKXA== 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=/HioFfeJdcxYRSIePrk0xPeneN7bTewVzuuGNUxyF+Q=; b=WhSXP/43cKwX0nUlJqBKfSMw+iqaujkxI91k92siMj8913saLcyqmyhV/4VrmyYTdv 30Z/H/pUQ0ocsZQ3Sg8iTTeEhUnzRuLhafAF+9PiM4y7G1C7RsLOm8AGJa6hUehdz3p2 shuYdtSyP8kp35tRqz5CT8vkgj4fv3j3fIqwxIzFIkNV5N+t0KosZkg9EVmG2/yjiZbP HtzuERZ/WCqJYztUfItyeXU660Dg4YpHUBhq6ifv1mlDGPFf09ndp8KQJPdpIydMiHLt YfeZhwREDBDE+GYRyFP1OZvrNWPQtOy0tT6J4/ke/leRTnetahbeM1rzLKLXYemw571f ackQ== X-Gm-Message-State: AO0yUKW5vYz33GDrWCc4zCm7MXqAaVPcz1Q5ptiSUiCuFVCHdW7INO9D lX3k/ER9JXhOBWmQH80SNCgFfQl3np3xSHP+1lk= X-Google-Smtp-Source: AK7set8kMxHBzefcTNVdGk+Fp2hvQCwE7N//UbyQQXSrTxuXqDeQbZXJhcbZfUDVjj6ajWFyZn1lL6NGFTaLwf83qvw= X-Received: by 2002:a05:6402:339:b0:49c:ea59:46b with SMTP id q25-20020a056402033900b0049cea59046bmr2368486edw.54.1675359386002; Thu, 02 Feb 2023 09:36:26 -0800 (PST) MIME-Version: 1.0 References: <20230127001141.407071-1-saravanak@google.com> <20230130085542.38546-1-naresh.kamboju@linaro.org> <20230131101813.goaoy32qvrowvyyb@bogus> In-Reply-To: <20230131101813.goaoy32qvrowvyyb@bogus> From: Maxim Kiselev Date: Thu, 2 Feb 2023 20:36:14 +0300 Message-ID: Subject: Re: [PATCH v2 00/11] fw_devlink improvements To: Sudeep Holla Cc: Saravana Kannan , Naresh Kamboju , abel.vesa@linaro.org, alexander.stein@ew.tq-group.com, andriy.shevchenko@linux.intel.com, brgl@bgdev.pl, colin.foster@in-advantage.com, cristian.marussi@arm.com, devicetree@vger.kernel.org, dianders@chromium.org, djrscally@gmail.com, dmitry.baryshkov@linaro.org, festevam@gmail.com, fido_max@inbox.ru, frowand.list@gmail.com, geert+renesas@glider.be, geert@linux-m68k.org, gregkh@linuxfoundation.org, heikki.krogerus@linux.intel.com, jpb@kernel.org, jstultz@google.com, kernel-team@android.com, kernel@pengutronix.de, lenb@kernel.org, linus.walleij@linaro.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org, linux-imx@nxp.com, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux@roeck-us.net, lkft@linaro.org, luca.weiss@fairphone.com, magnus.damm@gmail.com, martin.kepplinger@puri.sm, maz@kernel.org, miquel.raynal@bootlin.com, rafael@kernel.org, robh+dt@kernel.org, s.hauer@pengutronix.de, sakari.ailus@linux.intel.com, shawnguo@kernel.org, tglx@linutronix.de, tony@atomide.com Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org Hi Saravana, > 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 I did these tests and here is the results: 1. On top of this series - Not works 2. Without this series - Works 3. On top of the series with the fwnode_dev_initialized() deleted - Not works 4. Without this series, with the fwnode_dev_initialized() deleted - Works So your nvmem/core.c patch helps only when it is applied without the series. But despite the fact that this helps to avoid getting stuck at probing my ethernet device, there is still regression. When the ethernet module is loaded it takes a lot of time to drop dependency from the nvmem-cell with mac address. Please look at the kernel logs below. The first log corresponds to kernel with your nvmem/core.c patch: [ 0.036462] ethernet@70000 Linked as a fwnode consumer to clock-gating-control@1821c [ 0.036572] ethernet@70000 Linked as a fwnode consumer to partition@1 [ 0.045596] device: 'f1070000.ethernet': device_add [ 0.045854] ethernet@70000 Dropping the fwnode link to clock-gating-control@1821c [ 0.114990] device: 'platform:f1010600.spi:m25p80@0:partitions:partition@1--platform:f1070000.ethernet': device_add [ 0.115266] devices_kset: Moving f1070000.ethernet to end of list [ 0.115308] platform f1070000.ethernet: Linked as a consumer to f1010600.spi:m25p80@0:partitions:partition@1 [ 0.115345] ethernet@70000 Dropping the fwnode link to partition@1 [ 1.968232] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 2.088696] devices_kset: Moving f1070000.ethernet to end of list [ 2.088988] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 2.152411] devices_kset: Moving f1070000.ethernet to end of list [ 2.152735] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 2.153870] devices_kset: Moving f1070000.ethernet to end of list [ 2.154152] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 2.644950] devices_kset: Moving f1070000.ethernet to end of list [ 2.645282] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 3.169218] devices_kset: Moving f1070000.ethernet to end of list [ 3.169506] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 3.170444] devices_kset: Moving f1070000.ethernet to end of list [ 3.170721] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 3.419068] devices_kset: Moving f1070000.ethernet to end of list [ 3.419359] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 3.521275] devices_kset: Moving f1070000.ethernet to end of list [ 3.521564] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 3.639196] devices_kset: Moving f1070000.ethernet to end of list [ 3.639532] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 13.960144] platform f1070000.ethernet: Relaxing link with f1010600.spi:m25p80@0:partitions:partition@1 [ 13.960260] devices_kset: Moving f1070000.ethernet to end of list [ 13.971735] device: 'eth0': device_add [ 13.974140] mvneta f1070000.ethernet eth0: Using device tree mac address de:fa:ce:db:ab:e1 [ 13.974275] mvneta f1070000.ethernet: Dropping the link to f1010600.spi:m25p80@0:partitions:partition@1 [ 13.974318] device: 'platform:f1010600.spi:m25p80@0:partitions:partition@1--platform:f1070000.ethernet': device_unregister It took around 13 seconds to obtain a mac from nvmem-cell and bring up f1070000.ethernet And here is the second log which corresponds to kernel without your nvmem/core.c patch but also with reverted change 'bcdf0315': [ 0.036285] ethernet@70000 Linked as a fwnode consumer to clock-gating-control@1821c [ 0.036395] ethernet@70000 Linked as a fwnode consumer to partition@1 [ 0.045416] device: 'f1070000.ethernet': device_add [ 0.045674] ethernet@70000 Dropping the fwnode link to clock-gating-control@1821c [ 0.116136] ethernet@70000 Dropping the fwnode link to partition@1 [ 1.977060] device: 'eth0': device_add [ 1.979145] mvneta f1070000.ethernet eth0: Using device tree mac address de:fa:ce:db:ab:e1 It took around 1.5 second to obtain a mac from nvmem-cell P.S. Your nvmem patch definitely helps to avoid a device probe stuck but look like it is not best way to solve a problem which we discussed in the MTD thread. P.P.S. Also I don't know why your nvmem-cell patch doesn't help when it was applied on top of this series. Maybe I missed something. 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 5824FC61DA4 for ; Thu, 2 Feb 2023 17:37:25 +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=rHxlYl4H3gRxUYjlszzjtvfb2mRGgVEXlxeSoeHlBu4=; b=TRLeIgeIRZg0Tm yXFMw5G8hLENQuEs6sRF8J5xDXOoiD/dtt+q7k6s959Ma1aXZJ9A8OfZX6o+5P/oIrdU4WnmcmPc5 FQYstf++HW1PK9xOpqmtTGnfvsmbdEE+uCV5a7m5olxTxdcAkDbOUtaRb+QYAETQhuSwLocds94In 5j+veGC6ss+OvXF5R8s1foDi9FqSmNeYv3Np59XNbWHD3J0pXsjReAhNJbu9dcGsHgssrOp918cZt DoL1xpSj0CTYok8ycD2G0iCU0vzyZcmTXk+/y8E80nKZ6b3Q9WOeFzy2W6hTPr1PpMxfo8SiGXMnG dHDYGCm8JniUTRBor2Og==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1pNdVh-00Gpjh-Bj; Thu, 02 Feb 2023 17:36:33 +0000 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1pNdVd-00Gpha-OD for linux-arm-kernel@lists.infradead.org; Thu, 02 Feb 2023 17:36:31 +0000 Received: by mail-ed1-x535.google.com with SMTP id m8so2766684edd.10 for ; Thu, 02 Feb 2023 09:36:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.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=/HioFfeJdcxYRSIePrk0xPeneN7bTewVzuuGNUxyF+Q=; b=DgYe/MckqiMlJv5lX6qtOy2RdSlf9HWoVcWPf1C5A9ll+SRh7voCyz+NA64bhzh+6/ s6mvdEEKfye26uhEJ23ipwJr8a1qpBHq2v8E1UNx3Kjua7yEJBM1lVMSWb7l5t4afwPX NC8Ngx0j3yd+p+rWO5aBYsOU6K0KVHnSRrS4OC8T+e1TqldTsGc0awMKVV7I7kIlqXM1 UZDPQrrR0l2mmgiBijgpcJMKDpPzpRpNQ/Dx9ap2wWz77ECUrTvDzHZH/LuGcXempTwQ VIYpEcFp/DDcRU0BBLCdKwGsD1XFx66gOy31SAxiBmBrOEU453nRjdZ0cq+Rjhp6xSQo KKXA== 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=/HioFfeJdcxYRSIePrk0xPeneN7bTewVzuuGNUxyF+Q=; b=EqHT6itpXtp0ABk1ngmQ1KGGXifCIoAb8QqqeG6LE5YgONc/hYSFyUSzz/7d7U9Ulh g22vldrSxsUqMOowZXpw7Cb1Kjnp4aZYrYS0FCGRVtCViUQQDa8u0Lufta9aihdrIBTz +/9URwu+vzFjmk3Qh8TBu7e9zsfSgbbARgPiO/mY9f5mPvrxfmbAdoztlzXtEIfyYX/a ddSrMWbV9XKumgYRwqmAZfnZfr3gzqzt/viV4NQQLqmXEzuqb+9/zD3s/IF5be6TlX4C 5wg1C+n17cJP2nvLOcF05z9eEYvNd2LZQgAxob1PUJlS9BMLEdZPoxecRlDIIp/CiJSH 63XQ== X-Gm-Message-State: AO0yUKVWYANlj1/jGmMcG0pkWq6EWbYn/NPjipileVnHNdm8XUnrZdJ2 I0AfjZ9b8mp5Ms1DAHoLnbPSH/cC2V20mV6duNE= X-Google-Smtp-Source: AK7set8kMxHBzefcTNVdGk+Fp2hvQCwE7N//UbyQQXSrTxuXqDeQbZXJhcbZfUDVjj6ajWFyZn1lL6NGFTaLwf83qvw= X-Received: by 2002:a05:6402:339:b0:49c:ea59:46b with SMTP id q25-20020a056402033900b0049cea59046bmr2368486edw.54.1675359386002; Thu, 02 Feb 2023 09:36:26 -0800 (PST) MIME-Version: 1.0 References: <20230127001141.407071-1-saravanak@google.com> <20230130085542.38546-1-naresh.kamboju@linaro.org> <20230131101813.goaoy32qvrowvyyb@bogus> In-Reply-To: <20230131101813.goaoy32qvrowvyyb@bogus> From: Maxim Kiselev Date: Thu, 2 Feb 2023 20:36:14 +0300 Message-ID: Subject: Re: [PATCH v2 00/11] fw_devlink improvements To: Sudeep Holla Cc: Saravana Kannan , Naresh Kamboju , abel.vesa@linaro.org, alexander.stein@ew.tq-group.com, andriy.shevchenko@linux.intel.com, brgl@bgdev.pl, colin.foster@in-advantage.com, cristian.marussi@arm.com, devicetree@vger.kernel.org, dianders@chromium.org, djrscally@gmail.com, dmitry.baryshkov@linaro.org, festevam@gmail.com, fido_max@inbox.ru, frowand.list@gmail.com, geert+renesas@glider.be, geert@linux-m68k.org, gregkh@linuxfoundation.org, heikki.krogerus@linux.intel.com, jpb@kernel.org, jstultz@google.com, kernel-team@android.com, kernel@pengutronix.de, lenb@kernel.org, linus.walleij@linaro.org, linux-acpi@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-gpio@vger.kernel.org, linux-imx@nxp.com, linux-kernel@vger.kernel.org, linux-renesas-soc@vger.kernel.org, linux@roeck-us.net, lkft@linaro.org, luca.weiss@fairphone.com, magnus.damm@gmail.com, martin.kepplinger@puri.sm, maz@kernel.org, miquel.raynal@bootlin.com, rafael@kernel.org, robh+dt@kernel.org, s.hauer@pengutronix.de, sakari.ailus@linux.intel.com, shawnguo@kernel.org, tglx@linutronix.de, tony@atomide.com X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230202_093629_832588_E92CC5E6 X-CRM114-Status: GOOD ( 12.57 ) 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 Hi Saravana, > 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 I did these tests and here is the results: 1. On top of this series - Not works 2. Without this series - Works 3. On top of the series with the fwnode_dev_initialized() deleted - Not works 4. Without this series, with the fwnode_dev_initialized() deleted - Works So your nvmem/core.c patch helps only when it is applied without the series. But despite the fact that this helps to avoid getting stuck at probing my ethernet device, there is still regression. When the ethernet module is loaded it takes a lot of time to drop dependency from the nvmem-cell with mac address. Please look at the kernel logs below. The first log corresponds to kernel with your nvmem/core.c patch: [ 0.036462] ethernet@70000 Linked as a fwnode consumer to clock-gating-control@1821c [ 0.036572] ethernet@70000 Linked as a fwnode consumer to partition@1 [ 0.045596] device: 'f1070000.ethernet': device_add [ 0.045854] ethernet@70000 Dropping the fwnode link to clock-gating-control@1821c [ 0.114990] device: 'platform:f1010600.spi:m25p80@0:partitions:partition@1--platform:f1070000.ethernet': device_add [ 0.115266] devices_kset: Moving f1070000.ethernet to end of list [ 0.115308] platform f1070000.ethernet: Linked as a consumer to f1010600.spi:m25p80@0:partitions:partition@1 [ 0.115345] ethernet@70000 Dropping the fwnode link to partition@1 [ 1.968232] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 2.088696] devices_kset: Moving f1070000.ethernet to end of list [ 2.088988] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 2.152411] devices_kset: Moving f1070000.ethernet to end of list [ 2.152735] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 2.153870] devices_kset: Moving f1070000.ethernet to end of list [ 2.154152] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 2.644950] devices_kset: Moving f1070000.ethernet to end of list [ 2.645282] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 3.169218] devices_kset: Moving f1070000.ethernet to end of list [ 3.169506] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 3.170444] devices_kset: Moving f1070000.ethernet to end of list [ 3.170721] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 3.419068] devices_kset: Moving f1070000.ethernet to end of list [ 3.419359] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 3.521275] devices_kset: Moving f1070000.ethernet to end of list [ 3.521564] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 3.639196] devices_kset: Moving f1070000.ethernet to end of list [ 3.639532] platform f1070000.ethernet: error -EPROBE_DEFER: supplier f1010600.spi:m25p80@0:partitions:partition@1 not ready [ 13.960144] platform f1070000.ethernet: Relaxing link with f1010600.spi:m25p80@0:partitions:partition@1 [ 13.960260] devices_kset: Moving f1070000.ethernet to end of list [ 13.971735] device: 'eth0': device_add [ 13.974140] mvneta f1070000.ethernet eth0: Using device tree mac address de:fa:ce:db:ab:e1 [ 13.974275] mvneta f1070000.ethernet: Dropping the link to f1010600.spi:m25p80@0:partitions:partition@1 [ 13.974318] device: 'platform:f1010600.spi:m25p80@0:partitions:partition@1--platform:f1070000.ethernet': device_unregister It took around 13 seconds to obtain a mac from nvmem-cell and bring up f1070000.ethernet And here is the second log which corresponds to kernel without your nvmem/core.c patch but also with reverted change 'bcdf0315': [ 0.036285] ethernet@70000 Linked as a fwnode consumer to clock-gating-control@1821c [ 0.036395] ethernet@70000 Linked as a fwnode consumer to partition@1 [ 0.045416] device: 'f1070000.ethernet': device_add [ 0.045674] ethernet@70000 Dropping the fwnode link to clock-gating-control@1821c [ 0.116136] ethernet@70000 Dropping the fwnode link to partition@1 [ 1.977060] device: 'eth0': device_add [ 1.979145] mvneta f1070000.ethernet eth0: Using device tree mac address de:fa:ce:db:ab:e1 It took around 1.5 second to obtain a mac from nvmem-cell P.S. Your nvmem patch definitely helps to avoid a device probe stuck but look like it is not best way to solve a problem which we discussed in the MTD thread. P.P.S. Also I don't know why your nvmem-cell patch doesn't help when it was applied on top of this series. Maybe I missed something. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel