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 99AD3C6FD1A for ; Tue, 7 Mar 2023 17:00:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230429AbjCGQ7p (ORCPT ); Tue, 7 Mar 2023 11:59:45 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:52154 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229706AbjCGQ6K (ORCPT ); Tue, 7 Mar 2023 11:58:10 -0500 Received: from relay6-d.mail.gandi.net (relay6-d.mail.gandi.net [217.70.183.198]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5426B90099; Tue, 7 Mar 2023 08:54:46 -0800 (PST) Received: (Authenticated sender: miquel.raynal@bootlin.com) by mail.gandi.net (Postfix) with ESMTPSA id 2D87BC000D; Tue, 7 Mar 2023 16:54:37 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bootlin.com; s=gm1; t=1678208085; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=kOBXXD4vbju2aL5V1RwDCtfqYKoZS1/2BAnTjzjhigg=; b=XmvOkhJe/csozAO8RiC8briNTgzHaFAAeLwzDqCK5gHSaayiyxCSAkjAukIRH1k59bhq/K +S0T3pupqkvWW+nNIBG51gEyZ1XnlGdxOq2oW4sGPQJbn3Sl48GvY7jtAsEBDe27jebiQ4 Ia3We7tWbjefJ4ukYMM7B7+tZGgv6mYd9apYvPCLOyKeBqxCByy3Be5QlXHNucg15MMX0s Anh4WXFdYr4ue087X/eRxrHSHtg7EiLe3loDg9kRjG1ryd3ff4xqkCkKNDgojG5Go4WGhM wa8FHizTxjoWOmLsYgTHU3X3To44xP+GI8cPPPvRZn5a7NbOHm6IkskEUU4sew== From: Miquel Raynal To: Srinivas Kandagatla , Cc: Greg Kroah-Hartman , Michael Walle , =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= , Robert Marko , Luka Perkov , Thomas Petazzoni , Rob Herring , Frank Rowand , devicetree@vger.kernel.org, Miquel Raynal Subject: [PATCH v2 12/21] nvmem: core: request layout modules loading Date: Tue, 7 Mar 2023 17:53:50 +0100 Message-Id: <20230307165359.225361-13-miquel.raynal@bootlin.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20230307165359.225361-1-miquel.raynal@bootlin.com> References: <20230307165359.225361-1-miquel.raynal@bootlin.com> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org When a storage device like an eeprom or an mtd device probes, it registers an nvmem device if the nvmem subsystem has been enabled (bool symbol). During nvmem registration, if the device is using layouts to expose dynamic nvmem cells, the core will first try to get a reference over the layout driver callbacks. In practice there is not relationship that can be described between the storage driver and the nvmem layout. So there is no way we can enforce both drivers will be built-in or both will be modules. If the storage device driver is built-in but the layout is built as a module, instead of badly failing with an endless probe deferral loop, lets just make a modprobe call in case the driver was made available in an initramfs with of_device_node_request_module(), and offer a fully functional system to the user. Signed-off-by: Miquel Raynal Tested-by: Michael Walle --- drivers/nvmem/core.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c index 51fd792b8d70..9ef7617e2718 100644 --- a/drivers/nvmem/core.c +++ b/drivers/nvmem/core.c @@ -17,6 +17,7 @@ #include #include #include +#include #include struct nvmem_device { @@ -761,6 +762,13 @@ static struct nvmem_layout *nvmem_layout_get(struct nvmem_device *nvmem) if (!layout_np) return NULL; + /* + * In case the nvmem device was built-in while the layout was built as a + * module, we shall manually request the layout driver loading otherwise + * we'll never have any match. + */ + of_device_node_request_module(layout_np); + spin_lock(&nvmem_layout_lock); list_for_each_entry(l, &nvmem_layouts, node) { -- 2.34.1