From patchwork Tue Jan 23 01:46:18 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Pratt X-Patchwork-Id: 1889474 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=BFXGhVJB; dkim=fail reason="signature verification failed" (2048-bit key; secure) header.d=pm.me header.i=@pm.me header.a=rsa-sha256 header.s=protonmail3 header.b=SNycMXJi; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.infradead.org (client-ip=198.137.202.133; helo=bombadil.infradead.org; envelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=patchwork.ozlabs.org) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4TJqhF6nygz23f0 for ; Tue, 23 Jan 2024 12:46:53 +1100 (AEDT) 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:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:From:To:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=U/NonO+xIhZvgNCFrPwHqnvtqeY3p5Cvjdo7MiSIbg4=; b=BFXGhVJBrOfvF5 6uzcunM8ljrTzztUSGmA4wDRvwlyYqnVNXAELhUX5LI/HZsV1YHqX4+2P4sueUF8nSemxqbdqWFOL 0Om9w/fm2dDA7TOoRkmkw1VbF+ITmtIsQ3FMs98Bdp8tHdQaGySIGNdnfshsNtGhBt1rYHuvcYiA+ i/LGdkK+5uPd4cLb+qgYA9opx6YstaV9uO5ZSlaUb/2t5+Juywyvs0OIa6zKHgougWha7yJ3EKmVE 0HVANbWJii0UaHkJbDbkGTdMuquyyEeuCdiwSzCM5eU7MBRrlwpuZCxTiyMmO+xdSzlK8DuCVXkt1 8Ms0L4Ll1hT7AsM52JgQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rS5ry-00EnlS-1B; Tue, 23 Jan 2024 01:46:30 +0000 Received: from mail-40133.protonmail.ch ([185.70.40.133]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rS5rv-00Enjz-36 for linux-mtd@lists.infradead.org; Tue, 23 Jan 2024 01:46:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1705974384; x=1706233584; bh=W9fDeKvWcAx5zWuX6Ptj6h/hvIvYxgy0niruIGIV07k=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=SNycMXJi1xUXbudVK27K6Ff/w7QHAB+U/PohdYu5wEEP8rtIlEBoxxf1fyWL1PEIE Nzl5I0slsPCV3rhtk5v8BMe5DglfMbHSZPjNHd22ISVeAYslobFD0dSK7VI7Myv/ZY mGH/bn4Toh7tVHaLFBgjLwP2VLTyJL6d39sTDIJXyrcu3bO1DXI8K4PD3i09jWUl6c qCkmvqSxF/ci+kJ7dD8Rv3tx9EMhi7ttBhJ1qgaA6X6WrYQYXIS/OtvizZEPsFcwV2 xO73OCxrLMXVS0qu4NwT6zgt9vfN2tvjaSlRLBsj/v9XsCWmY1taIer0hIVK7r9UwF gBozSVS8Gxxww== Date: Tue, 23 Jan 2024 01:46:18 +0000 To: devicetree@vger.kernel.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org From: Michael Pratt Cc: Michael Pratt , saravanak@google.com, abel.vesa@linaro.org, alexander.stein@ew.tq-group.com, andriy.shevchenko@linux.intel.com, bigunclemax@gmail.com, brgl@bgdev.pl, colin.foster@in-advantage.com, djrscally@gmail.com, dmitry.baryshkov@linaro.org, festevam@gmail.com, fido_max@inbox.ru, frowand.list@gmail.com, geert@linux-m68k.org, heikki.krogerus@linux.intel.com, kernel@pengutronix.de, linus.walleij@linaro.org, linux@roeck-us.net, luca.weiss@fairphone.com, magnus.damm@gmail.com, martin.kepplinger@puri.sm, miquel.raynal@bootlin.com, rafal@milecki.pl, ansuelsmth@gmail.com, richard@nod.at, sakari.ailus@linux.intel.com, sudeep.holla@arm.com, tglx@linutronix.de, tony@atomide.com, vigneshr@ti.com, dianders@chromium.org, jpb@kernel.org, rafael@kernel.org Subject: [PATCH v1 1/4] driver core: fw_devlink: Use driver to determine probe ability Message-ID: <20240123014517.5787-2-mcpratt@pm.me> In-Reply-To: <20240123014517.5787-1-mcpratt@pm.me> References: <20240123014517.5787-1-mcpratt@pm.me> Feedback-ID: 27397442:user:proton MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240122_174628_159116_76BABF5D X-CRM114-Status: GOOD ( 13.16 ) X-Spam-Score: -0.2 (/) X-Spam-Report: Spam detection software, running on the system "bombadil.infradead.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: The function __fw_devlink_pickup_dangling_consumers() intends to ignore suppliers that are already capable of probing, but uses whether or not a bus struct is defined in the device struct. There are some cases where a firmware child node can be address translatable but not able to probe (e.g. the use of of_platform_populate() for MTD partitions), so whether or not a driver is present is [...] Content analysis details: (-0.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain 0.0 RCVD_IN_MSPIKE_H5 RBL: Excellent reputation (+5) [185.70.40.133 listed in wl.mailspike.net] 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org The function __fw_devlink_pickup_dangling_consumers() intends to ignore suppliers that are already capable of probing, but uses whether or not a bus struct is defined in the device struct. There are some cases where a firmware child node can be address translatable but not able to probe (e.g. the use of of_platform_populate() for MTD partitions), so whether or not a driver is present is a more accurate way to guess whether a fwnode represents a real probing device here. This also serves as a preparation step for further changes to fw_devlink including making the contents of this function less strict in order to compensate for more cases being passed into the rest of the function because the return case is now more strict. "Hey! Who's driving the bus?" Signed-off-by: Michael Pratt --- drivers/base/core.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index 14d46af40f9a..c05a5f6b0641 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -214,7 +214,7 @@ static void __fwnode_links_move_consumers(struct fwnode_handle *from, * @new_sup: fwnode of new supplier * * If the @fwnode has a corresponding struct device and the device supports - * probing (that is, added to a bus), then we want to let fw_devlink create + * probing (that is, bound to a driver), then we want to let fw_devlink create * MANAGED device links to this device, so leave @fwnode and its descendant's * fwnode links alone. * @@ -225,7 +225,7 @@ static void __fw_devlink_pickup_dangling_consumers(struct fwnode_handle *fwnode, { struct fwnode_handle *child; - if (fwnode->dev && fwnode->dev->bus) + if (fwnode->dev && fwnode->dev->driver) return; fwnode->flags |= FWNODE_FLAG_NOT_DEVICE; From patchwork Tue Jan 23 01:46:40 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Pratt X-Patchwork-Id: 1889475 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=YkZEWbJL; dkim=fail reason="signature verification failed" (2048-bit key; secure) header.d=pm.me header.i=@pm.me header.a=rsa-sha256 header.s=protonmail3 header.b=JYBdeS/7; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.infradead.org (client-ip=198.137.202.133; helo=bombadil.infradead.org; envelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=patchwork.ozlabs.org) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4TJqhx1c0nz23f0 for ; Tue, 23 Jan 2024 12:47:29 +1100 (AEDT) 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:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:From:To:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=SpvUwu29DSyNGovIdyiYpaD0QEXIKATO1PQ5F6ZhHDk=; b=YkZEWbJL1M/mvN TwZYPPP59XLOiKo0vMOc6nrFpidhIE7+sHJ0WNzOj//HxWnMjuF9SY/VwP8syEL/jOsz3bJ63WJoz IBn5sup4gydm/ywWlXKdXRK5aUBmjQ/RHbXws0u6i7tC2DdkoGcGjiSV1fWU3cgWzHgekh8PF8/nm Hfb1ykMl0Ap7cLd+ZEWIiIQ1QbrLGTrbAGRBPHo7/LOL6mgLkBzFJ0eOgN4YExs6wuXJmid5sKAlj sESp96tbbu1XPDf67naQp3iFtWvMjHoP4XQAgoO3UybAG5hH+0Jo23MOqdkQXEFwXAXbgcqwe426Y NLM6E5zZySDldaiCoKoA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rS5sR-00EnsM-33; Tue, 23 Jan 2024 01:46:59 +0000 Received: from mail-40133.protonmail.ch ([185.70.40.133]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rS5sN-00EnrA-2b for linux-mtd@lists.infradead.org; Tue, 23 Jan 2024 01:46:57 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1705974413; x=1706233613; bh=IuTlLINJgaRw7B3N708S7h3v0HiOAtfm1OMnmzHUN50=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=JYBdeS/7qxzIJC0+6PiVAFOXhjyPOiiUuPrrE9l5qdNV1qW9G+nJIBi/H5pusUExW jEhCC3EXSPFrGjBsfXHoPG19+8YeL7BYH85PIm0PxWE1AW58Hf3b0ULPRhSHc2Fq2i nuq7W6Zmnc+5S9uj0FYj7IZej/dqnFMewI9bgdwaYcJYsvOkq/4kyZEk93Y12+RU3y Oc+tzZsVBMaThH35Erhf6F/aAhSVd7sQ3JOkbQCKrD/Oyww/SESsVFNyGM+hKUNT86 XEiBkD6ljwzuVWAOyXPni4Rs/Y7awS1OC7YhPjZkaIAzg0pk7hRPfkaGKtaQQWK8yU 3JDnNtJezGi1g== Date: Tue, 23 Jan 2024 01:46:40 +0000 To: devicetree@vger.kernel.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org From: Michael Pratt Cc: Michael Pratt , saravanak@google.com, abel.vesa@linaro.org, alexander.stein@ew.tq-group.com, andriy.shevchenko@linux.intel.com, bigunclemax@gmail.com, brgl@bgdev.pl, colin.foster@in-advantage.com, djrscally@gmail.com, dmitry.baryshkov@linaro.org, festevam@gmail.com, fido_max@inbox.ru, frowand.list@gmail.com, geert@linux-m68k.org, heikki.krogerus@linux.intel.com, kernel@pengutronix.de, linus.walleij@linaro.org, linux@roeck-us.net, luca.weiss@fairphone.com, magnus.damm@gmail.com, martin.kepplinger@puri.sm, miquel.raynal@bootlin.com, rafal@milecki.pl, ansuelsmth@gmail.com, richard@nod.at, sakari.ailus@linux.intel.com, sudeep.holla@arm.com, tglx@linutronix.de, tony@atomide.com, vigneshr@ti.com, dianders@chromium.org, jpb@kernel.org, rafael@kernel.org Subject: [PATCH v1 2/4] driver core: fw_devlink: Link to supplier ancestor if no device Message-ID: <20240123014517.5787-3-mcpratt@pm.me> In-Reply-To: <20240123014517.5787-1-mcpratt@pm.me> References: <20240123014517.5787-1-mcpratt@pm.me> Feedback-ID: 27397442:user:proton MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240122_174656_154183_47DF55C4 X-CRM114-Status: GOOD ( 22.23 ) X-Spam-Score: -0.2 (/) X-Spam-Report: Spam detection software, running on the system "bombadil.infradead.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Driver core currently supports linking to the next parent fwnode, but is not yet handling cases where that parent is also a firmware child node not representing a real device, which can lead to an ind [...] Content analysis details: (-0.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_MSPIKE_H5 RBL: Excellent reputation (+5) [185.70.40.133 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org Driver core currently supports linking to the next parent fwnode, but is not yet handling cases where that parent is also a firmware child node not representing a real device, which can lead to an indefinite deferred probe in some cases. In this case, the fwnode that should actually be linked to is multiple ancestors up which presents a challenge where it is unknown how many ancestors up the node that represents the real probing device is. This makes the usage of fwnode_get_next_parent_dev() insufficient because the real device's fwnode may or may not be an ancestor of the next parent fwnode as well. Introduce flag FWNODE_FLAG_PARENT_IS_DEV in order to mark child firmware nodes of a device as having a parent device that can probe. Allow fwnode link creation to the original supplier fwnode's ancestors when the original supplier fwnode and any fwnodes in between are flagged as FWNODE_FLAG_NOT_DEVICE and/or FWNODE_FLAG_PARENT_IS_DEV with a new function __fwnode_link_add_parents() which then creates the fwnode link to a real device that provides the supplier's function. This depends on other functions to label a supplier fwnode as not a real device, which must be done before the fwnode links are created, and if after that, relevant links to the supplier would have to be deleted and have links recreated, otherwise, the fwnode link would be dropped before the device link is attempted or a fwnode link would not be able to become a device link at all, because they were created before these fwnode flags can have any effect. It also depends on the supplier device to actually probe first in order to have the fwnode flags in place to know for certain which fwnodes are non-probing child nodes of the fwnode for the supplier device. The use case of function __fw_devlink_pickup_dangling_consumers() is designed so that the parameters are always a supplier fwnode and one of it's parent fwnodes, so it is safer to assume and more specific that the flag PARENT_IS_DEV should be added there, rather than declaring the original supplier fwnode as NOT_DEVICE at that point. Because this function is called when the real supplier device probes and recursively calls itself for all child nodes of the device's fwnode, set the new flag here in order to let it propagate down to all descendant nodes, thereby providing the info needed later in order to link to the proper fwnode representing the supplier device. If a fwnode is flagged as FWNODE_FLAG_NOT_DEVICE by the time a device link is to be made with it, but not flagged as FWNODE_FLAG_PARENT_IS_DEV, the link is dropped, otherwise the device link is still made with the original supplier fwnode. Theoretically, we can also handle linking to an ancestor of the supplier fwnode when forming device links, but there are still cases where the necessary fwnode flags are still missing because the real supplier device did not probe yet. Signed-off-by: Michael Pratt --- drivers/base/core.c | 49 ++++++++++++++++++++++++++++++++++++------ include/linux/fwnode.h | 4 ++++ 2 files changed, 47 insertions(+), 6 deletions(-) diff --git a/drivers/base/core.c b/drivers/base/core.c index c05a5f6b0641..7f2652cf5edc 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -92,13 +92,45 @@ static int __fwnode_link_add(struct fwnode_handle *con, return 0; } +static int __fwnode_link_add_parents(struct fwnode_handle *con, + struct fwnode_handle *sup, + u8 flags, bool loop) +{ + int ret = -EINVAL; + struct fwnode_handle *parent; + + fwnode_for_each_parent_node(sup, parent) { + /* Ignore the root node */ + if (fwnode_count_parents(parent) && + fwnode_device_is_available(parent) && + !(parent->flags & FWNODE_FLAG_NOT_DEVICE) && + !(parent->flags & FWNODE_FLAG_PARENT_IS_DEV)) { + ret = __fwnode_link_add(con, parent, flags); + } + + if (!loop && !ret) { + fwnode_handle_put(parent); + return 0; + } + } + + return ret; +} + int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup) { int ret; mutex_lock(&fwnode_link_lock); - ret = __fwnode_link_add(con, sup, 0); + + if ((sup->flags & FWNODE_FLAG_NOT_DEVICE) && + (sup->flags & FWNODE_FLAG_PARENT_IS_DEV)) + ret = __fwnode_link_add_parents(con, sup, 0, false); + else + ret = __fwnode_link_add(con, sup, 0); + mutex_unlock(&fwnode_link_lock); + return ret; } @@ -218,7 +250,8 @@ static void __fwnode_links_move_consumers(struct fwnode_handle *from, * MANAGED device links to this device, so leave @fwnode and its descendant's * fwnode links alone. * - * Otherwise, move its consumers to the new supplier @new_sup. + * Otherwise, flag descendants of @fwnode as having a parent fwnode for a device + * that has probed and move bad fwnode consumer links from @fwnode to @new_sup. */ static void __fw_devlink_pickup_dangling_consumers(struct fwnode_handle *fwnode, struct fwnode_handle *new_sup) @@ -228,8 +261,11 @@ static void __fw_devlink_pickup_dangling_consumers(struct fwnode_handle *fwnode, if (fwnode->dev && fwnode->dev->driver) return; - fwnode->flags |= FWNODE_FLAG_NOT_DEVICE; - __fwnode_links_move_consumers(fwnode, new_sup); + if (fwnode->flags & FWNODE_FLAG_NOT_DEVICE) + __fwnode_links_move_consumers(fwnode, new_sup); + + fwnode->flags |= FWNODE_FLAG_PARENT_IS_DEV; + new_sup->flags &= ~(FWNODE_FLAG_PARENT_IS_DEV); fwnode_for_each_available_child_node(fwnode, child) __fw_devlink_pickup_dangling_consumers(child, new_sup); @@ -2071,8 +2107,9 @@ static int fw_devlink_create_devlink(struct device *con, device_links_write_unlock(); } - if (sup_handle->flags & FWNODE_FLAG_NOT_DEVICE) - sup_dev = fwnode_get_next_parent_dev(sup_handle); + if ((sup_handle->flags & FWNODE_FLAG_NOT_DEVICE) && + !(sup_handle->flags & FWNODE_FLAG_PARENT_IS_DEV)) + return -EINVAL; else sup_dev = get_dev_from_fwnode(sup_handle); diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h index 2a72f55d26eb..3ed8ba503062 100644 --- a/include/linux/fwnode.h +++ b/include/linux/fwnode.h @@ -30,6 +30,9 @@ struct device; * BEST_EFFORT: The fwnode/device needs to probe early and might be missing some * suppliers. Only enforce ordering with suppliers that have * drivers. + * PARENT_IS_DEV: The fwnode is a child of a fwnode that is or will be populated as a + * struct device, which is more suitable for device links + * than the fwnode child which may never have a struct device. */ #define FWNODE_FLAG_LINKS_ADDED BIT(0) #define FWNODE_FLAG_NOT_DEVICE BIT(1) @@ -37,6 +40,7 @@ struct device; #define FWNODE_FLAG_NEEDS_CHILD_BOUND_ON_ADD BIT(3) #define FWNODE_FLAG_BEST_EFFORT BIT(4) #define FWNODE_FLAG_VISITED BIT(5) +#define FWNODE_FLAG_PARENT_IS_DEV BIT(6) struct fwnode_handle { struct fwnode_handle *secondary; From patchwork Tue Jan 23 01:47:01 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Pratt X-Patchwork-Id: 1889476 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=VF3rkKrL; dkim=fail reason="signature verification failed" (2048-bit key; secure) header.d=pm.me header.i=@pm.me header.a=rsa-sha256 header.s=protonmail3 header.b=qucMjGIL; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.infradead.org (client-ip=198.137.202.133; helo=bombadil.infradead.org; envelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=patchwork.ozlabs.org) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4TJqjK5nqFz23f0 for ; Tue, 23 Jan 2024 12:47:49 +1100 (AEDT) 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:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:From:To:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=vWIlrcSLwb3CZEzGfAljGvqiF6CRmcJGulf586j/+O4=; b=VF3rkKrL6e8Bxn +LjDDNC3gXQc+ZBA0OgaU4PoBvSKTuBoUuifidlJRZTJP/Y0pggMj0p2qu7HjE8/Gz+Rkjd4j22Mw bhnb1qeJJRjs1ba+PMuro6Pp7F1yqNc0B/BQPFvrw8MSv7j2fUc7RJ2QLe4b7EaHRvVVkcboW4Exh 9mAG68g757/eBs74eHseowqCsDK3L1AIF4ZP4Fus2l553pA/0+OZNFWubRCXU1zmF7zQqOmOMrp+F h4DQ99upb0CiTkNpGkwn3jsMo6Qm7WTcQXLtQJiZXzBzbXzCKb1HcW5haJSzeyVRwYooKUTCShfoM Xq2M3KaW5Or0igEKKW7Q==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rS5sq-00Enx4-0b; Tue, 23 Jan 2024 01:47:24 +0000 Received: from mail-40133.protonmail.ch ([185.70.40.133]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rS5sn-00Enw2-1o for linux-mtd@lists.infradead.org; Tue, 23 Jan 2024 01:47:23 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1705974439; x=1706233639; bh=4YREAB+lLFhLYt23yOuuQE8IjzcG54BZ+WRgblN4Okw=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=qucMjGILNV9xcag759X1TuTYlyL0txyxsfKThwXcZbwH7piqvdGUkheC7w6oM1ne1 cy9kEbGzLwMMKqQTrXDFvV22FAr4bI7QK6ntMZJuP7ORlhJDak+fRg6cfr90FQ4jNI S63nvaYljxfj+Ohg4Xw9URE0+p/sJdX1bcdaVP3KTjV0lxCdDBj+03g21N42sUMhj2 ATg+V4N1Pfl58CD7kt51GLnK/tg526xMjnQanL/loJ2Vqge7nrqwhZx9L4aN5iGsDR 424DxiwHM7Yj8SJAp/Z56wmUqxnauuipqmRstjuOOKWRXEKOJqdEqdUPltuer/QV6E NlrBgyN1KmpSA== Date: Tue, 23 Jan 2024 01:47:01 +0000 To: devicetree@vger.kernel.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org From: Michael Pratt Cc: Michael Pratt , saravanak@google.com, abel.vesa@linaro.org, alexander.stein@ew.tq-group.com, andriy.shevchenko@linux.intel.com, bigunclemax@gmail.com, brgl@bgdev.pl, colin.foster@in-advantage.com, djrscally@gmail.com, dmitry.baryshkov@linaro.org, festevam@gmail.com, fido_max@inbox.ru, frowand.list@gmail.com, geert@linux-m68k.org, heikki.krogerus@linux.intel.com, kernel@pengutronix.de, linus.walleij@linaro.org, linux@roeck-us.net, luca.weiss@fairphone.com, magnus.damm@gmail.com, martin.kepplinger@puri.sm, miquel.raynal@bootlin.com, rafal@milecki.pl, ansuelsmth@gmail.com, richard@nod.at, sakari.ailus@linux.intel.com, sudeep.holla@arm.com, tglx@linutronix.de, tony@atomide.com, vigneshr@ti.com, dianders@chromium.org, jpb@kernel.org, rafael@kernel.org Subject: [PATCH v1 3/4] driver core: fw_devlink: Add function device_links_fixup_suppliers() Message-ID: <20240123014517.5787-4-mcpratt@pm.me> In-Reply-To: <20240123014517.5787-1-mcpratt@pm.me> References: <20240123014517.5787-1-mcpratt@pm.me> Feedback-ID: 27397442:user:proton MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240122_174721_910955_6EF68725 X-CRM114-Status: GOOD ( 29.36 ) X-Spam-Score: -0.2 (/) X-Spam-Report: Spam detection software, running on the system "bombadil.infradead.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: If the supplier fwnode of a link is a child firmware node of a real device, the probe of the consumer device can be indefinitely deferred in some cases like when the consumer is registered as a device [...] Content analysis details: (-0.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_MSPIKE_H5 RBL: Excellent reputation (+5) [185.70.40.133 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org If the supplier fwnode of a link is a child firmware node of a real device, the probe of the consumer device can be indefinitely deferred in some cases like when the consumer is registered as a device and attempts probe first. Add a function to fixup or recreate both fwnode and device links to a consumer device before probing gets deferred. As noted in the previous commit, descendant fwnodes of the real supplier device only become flagged with PARENT_IS_DEV when the real supplier device probes, which is necessary in some cases for knowing how many ancestors up in the tree the fwnode representing the real device is. In the case where the consumer device has a probe attempt before the supplier device while the correct supplier fwnode is multiple ancestors up from the fwnode being linked, the unknowns present before the supplier device probes causes incorrect fwnode links that either become incorrect device links or in some cases, fwnode links are unable to become device links at all, which leads to the need to redo the link between the devices after a probe defer of the consumer, therefore, when the original supplier fwnode is flagged PARENT_IS_DEV after supplier device probing, and the consumer is about to be deferred again from a missing supplier, flag the original supplier fwnode as NOT_DEVICE also and recreate the relevant fwnode/device links to the consumer device. In the case where the supplier probes first but a descendant fwnode is the one linked to the consumer, the link recreation happens on the first probe attempt of the consumer. Because of the fwnode flags, the links will be handled differently when deleted and recreated compared to before the consumer probe attempt by linking the consumer with a ancestor of the original supplier fwnode, which at this point represents a device that already probed successfully. In the future, a way to develop "deferred device links" may be possible, but that is likely much more complex. The existing function device_links_check_suppliers() is not suitable for these fixup changes because of the case where a different supplier may also cause a deferred probe for a completely different reason. Handle this in a new function device_links_fixup_suppliers() which will be called before device_links_check_suppliers() which is where it is decided whether or not the consumer must be deferred. Checks in the new function exactly match checks in the function device_links_check_suppliers() for consistency. This new function is now the last opportunity to interact with device links before probe is deferred, which stops device links from being processed until re-probe or the next time device_add() is called. This makes it an ideal location to finally assume that the supplier must have probed at that point in time, unless there is an issue. This should be called at every probe, because it is important to handle as many device link changes as possible before probe deferral, since deferred_probe_initcall() will only be called *once* at late_initcall, and another probe defer at that point or later can cause the consumer to be deferred indefinitely, and the fact that in some cases, a probe deferral can be avoided entirely if the real supplier device probes first. Also, make sure that the device links are not handled earlier than the fixup function for these cases. Otherwise, before deferred probes are started again, the link will be converted to sync-state only. Signed-off-by: Michael Pratt --- drivers/base/base.h | 1 + drivers/base/core.c | 91 +++++++++++++++++++++++++++++++++++++++++++++ drivers/base/dd.c | 2 + 3 files changed, 94 insertions(+) diff --git a/drivers/base/base.h b/drivers/base/base.h index eb4c0ace9242..96593650a861 100644 --- a/drivers/base/base.h +++ b/drivers/base/base.h @@ -229,6 +229,7 @@ bool device_links_busy(struct device *dev); void device_links_unbind_consumers(struct device *dev); void fw_devlink_drivers_done(void); void fw_devlink_probing_done(void); +void device_links_fixup_suppliers(struct device *dev); /* device pm support */ void device_pm_move_to_tail(struct device *dev); diff --git a/drivers/base/core.c b/drivers/base/core.c index 7f2652cf5edc..96edcd842b42 100644 --- a/drivers/base/core.c +++ b/drivers/base/core.c @@ -1773,6 +1773,9 @@ static void fw_devlink_relax_link(struct device_link *link) if (device_link_flag_is_sync_state_only(link->flags)) return; + if (link->supplier->fwnode && (link->supplier->fwnode->flags & FWNODE_FLAG_PARENT_IS_DEV)) + return; + pm_runtime_drop_link(link); link->flags = DL_FLAG_MANAGED | FW_DEVLINK_FLAGS_PERMISSIVE; dev_dbg(link->consumer, "Relaxing link with %s\n", @@ -2286,6 +2289,94 @@ static void fw_devlink_link_device(struct device *dev) mutex_unlock(&fwnode_link_lock); } +/** + * device_links_fixup_suppliers - Fix bad device links to suppliers of @dev. + * @dev: Consumer device. + * + * This should be called after the suppliers of @dev have a chance to form + * device links and @dev is probing so that, even if the consumer device + * has had it's fwtree parsed and it's attempt to probe started first, + * the suppliers are guaranteed to have an attempt at probing + * thanks to the dependency defined through the existing device links. + * + * In driver core, the suppliers have had an opportunity to probe at this point. + * Therefore, this is an ideal position to handle corner cases where, + * for whatever reason, the supplier is not optional, but the link to + * a supplier is bad and causing the probing of the consumer to defer. + * This is the last opportunity to handle a bad device link before + * that link will cause a probe defer of the consumer. + * + * If a fwnode link has not been translated to a device link at this point, + * or if a device link has not successfully resulted in the supplier probing, + * we know it is not possible for that node to represent a real device that + * provides functionality to the consumer, but an ancestor of that node might be. + */ +void device_links_fixup_suppliers(struct device *dev) +{ + struct fwnode_link *fwlink, *fwtmp; + struct device_link *link, *tmp; + + mutex_lock(&fwnode_link_lock); + device_links_write_lock(); + + if (!dev->fwnode) + goto no_fwnode; + + /* Keep flag checks in sync with fwnode_links_check_suppliers() */ + list_for_each_entry_safe(fwlink, fwtmp, &dev->fwnode->suppliers, c_hook) { + if (fwlink->flags & FWLINK_FLAG_CYCLE) + continue; + + /* The supplier may be a child fwnode of a device, if so, relink */ + if (fwlink->supplier->flags & FWNODE_FLAG_PARENT_IS_DEV) { + dev_dbg(dev, + "Linking to ancestor of fwnode %pfwf\n", + fwlink->supplier); + fwlink->supplier->flags |= FWNODE_FLAG_NOT_DEVICE; + dev->fwnode->flags &= ~FWNODE_FLAG_LINKS_ADDED; + __fwnode_link_del(fwlink); + mutex_unlock(&fwnode_link_lock); + device_links_write_unlock(); + fw_devlink_link_device(dev); + mutex_lock(&fwnode_link_lock); + device_links_write_lock(); + continue; + } + } + +no_fwnode: + /* Keep flag checks in sync with device_links_check_suppliers() */ + list_for_each_entry_safe(link, tmp, &dev->links.suppliers, c_node) { + if (!(link->flags & DL_FLAG_MANAGED)) + continue; + + if (link->status != DL_STATE_AVAILABLE && + !(link->flags & DL_FLAG_SYNC_STATE_ONLY)) { + + if (!dev->fwnode || !link->supplier->fwnode) + continue; + + /* The supplier may be a child fwnode of a device, if so, relink */ + if (link->supplier->fwnode->flags & FWNODE_FLAG_PARENT_IS_DEV) { + dev_dbg(dev, + "Linking to ancestor of %s\n", + dev_name(link->supplier)); + link->supplier->fwnode->flags |= FWNODE_FLAG_NOT_DEVICE; + dev->fwnode->flags &= ~FWNODE_FLAG_LINKS_ADDED; + __device_link_del(&link->kref); + mutex_unlock(&fwnode_link_lock); + device_links_write_unlock(); + fw_devlink_link_device(dev); + mutex_lock(&fwnode_link_lock); + device_links_write_lock(); + continue; + } + } + } + mutex_unlock(&fwnode_link_lock); + device_links_write_unlock(); +} + /* Device links support end. */ int (*platform_notify)(struct device *dev) = NULL; diff --git a/drivers/base/dd.c b/drivers/base/dd.c index 85152537dbf1..24b8a506bc51 100644 --- a/drivers/base/dd.c +++ b/drivers/base/dd.c @@ -606,6 +606,8 @@ static int really_probe(struct device *dev, struct device_driver *drv) !drv->suppress_bind_attrs; int ret, link_ret; + device_links_fixup_suppliers(dev); + if (defer_all_probes) { /* * Value of defer_all_probes can be set only by From patchwork Tue Jan 23 01:47:21 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael Pratt X-Patchwork-Id: 1889477 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@legolas.ozlabs.org Authentication-Results: legolas.ozlabs.org; dkim=pass (2048-bit key; secure) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=b4Z5P8sZ; dkim=fail reason="signature verification failed" (2048-bit key; secure) header.d=pm.me header.i=@pm.me header.a=rsa-sha256 header.s=protonmail3 header.b=aGnzN1SP; dkim-atps=neutral Authentication-Results: legolas.ozlabs.org; spf=none (no SPF record) smtp.mailfrom=lists.infradead.org (client-ip=198.137.202.133; helo=bombadil.infradead.org; envelope-from=linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org; receiver=patchwork.ozlabs.org) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by legolas.ozlabs.org (Postfix) with ESMTPS id 4TJqjQ4PcBz23f0 for ; Tue, 23 Jan 2024 12:47:54 +1100 (AEDT) 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:MIME-Version:References:In-Reply-To: Message-ID:Subject:Cc:From:To:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=GMr5dQBAkEPXkuBi8PHnRsXXxXkXjHs6bytpA/VJCRA=; b=b4Z5P8sZlO/UDr QJJMSUxBYMXrJma9n3BV9OfhxawCWC4L2ZDamEKaewHo/BhedT5SZBe6SYQk5iUk9gRdfp12J0vlE B5Qtpbm9rjbHgO5K2edMYT54u4fnlIXVLEvxwAYFb3fIk8wjSh9U9Qk1hfR5VqIKcBD8maRT052en +2caV4BPUbTN+wp58s0Orhoa8O2JJhlU7jEWygITxPGBfTiSmYWi9r0TgV2xwCYjVAeKHT+uC2km+ TqzF3Zz50RUWGZdd8reWcsSesUHhVibC04BePS5Nlf8GbbERPl1mDq+iG5l4Ii7zeOytboiM0BMFZ 8RAQaOpRdBFdkAJ68meA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1rS5sw-00Enzq-2e; Tue, 23 Jan 2024 01:47:30 +0000 Received: from mail-40133.protonmail.ch ([185.70.40.133]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1rS5st-00Enxy-2m for linux-mtd@lists.infradead.org; Tue, 23 Jan 2024 01:47:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1705974445; x=1706233645; bh=fxYcyr7pTg3CIHphjSaf+5XlmBylc2uV3tWOoWgMT1I=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=aGnzN1SPVWxRuRi4Z7/2pPvz4qx+/sZqPAlwic66PqRSxOz12oLYuDGQ81TT554FJ TC87LdXQB4+y5NNUcRyw+NUf1ATXMcvo60pdGxwkWaTxojIUnhUdqZDAAuQMdzMRm2 bkYw5wkE59UC79vNsYKEgfr/jb3crCY9wFBdB8WcdW0eF3nQO6gytc/kMFKAr4vvO/ yODQ/be5Z8x5JSbkUf3/0ITSXJAEsm7f/QcU442N1e1TNZ6hAvmfE7hDlybzHK4loE ag2xjQmep00Z8ojpE+BUIKCKoG2hoVEpzH5DpbXa6HHKfgjBokN0IAnKlbp6WOhm69 zOQFz43uWo9dg== Date: Tue, 23 Jan 2024 01:47:21 +0000 To: devicetree@vger.kernel.org, gregkh@linuxfoundation.org, linux-kernel@vger.kernel.org, linux-mtd@lists.infradead.org From: Michael Pratt Cc: Michael Pratt , saravanak@google.com, abel.vesa@linaro.org, alexander.stein@ew.tq-group.com, andriy.shevchenko@linux.intel.com, bigunclemax@gmail.com, brgl@bgdev.pl, colin.foster@in-advantage.com, djrscally@gmail.com, dmitry.baryshkov@linaro.org, festevam@gmail.com, fido_max@inbox.ru, frowand.list@gmail.com, geert@linux-m68k.org, heikki.krogerus@linux.intel.com, kernel@pengutronix.de, linus.walleij@linaro.org, linux@roeck-us.net, luca.weiss@fairphone.com, magnus.damm@gmail.com, martin.kepplinger@puri.sm, miquel.raynal@bootlin.com, rafal@milecki.pl, ansuelsmth@gmail.com, richard@nod.at, sakari.ailus@linux.intel.com, sudeep.holla@arm.com, tglx@linutronix.de, tony@atomide.com, vigneshr@ti.com, dianders@chromium.org, jpb@kernel.org, rafael@kernel.org Subject: [PATCH v1 4/4] mtd: mtdpart: Allow fwnode links to NVMEM compatible fwnodes Message-ID: <20240123014517.5787-5-mcpratt@pm.me> In-Reply-To: <20240123014517.5787-1-mcpratt@pm.me> References: <20240123014517.5787-1-mcpratt@pm.me> Feedback-ID: 27397442:user:proton MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240122_174728_053291_E120B21F X-CRM114-Status: GOOD ( 10.50 ) X-Spam-Score: -0.2 (/) X-Spam-Report: Spam detection software, running on the system "bombadil.infradead.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: This reverts commit fb42378dcc7f247df56f0ecddfdae85487495fbc ("mtd: mtdpart: Don't create platform device that'll never probe"). That commit is a manual named exception in order to avoid fw_devlink links to an "nvmem-cells" compatible node which is a descendant of the fwnode that represents the real supplier device that probes. Content analysis details: (-0.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 SPF_PASS SPF: sender matches SPF record -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_EF Message has a valid DKIM or DK signature from envelope-from domain 0.0 RCVD_IN_MSPIKE_H5 RBL: Excellent reputation (+5) [185.70.40.133 listed in wl.mailspike.net] 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-mtd" Errors-To: linux-mtd-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org This reverts commit fb42378dcc7f247df56f0ecddfdae85487495fbc ("mtd: mtdpart: Don't create platform device that'll never probe"). That commit is a manual named exception in order to avoid fw_devlink links to an "nvmem-cells" compatible node which is a descendant of the fwnode that represents the real supplier device that probes. The commit does not work for newer cases, like the "fixed-layout" compatible nodes, but instead of adding another compatible string, remove this workaround as it is no longer needed after the previous few commits which handle the situation in a generic way for all supplier nodes that are a child or further descendant fwnode of a parent device that can probe, including when the consumer device has a probe attempt before the supplier device, by using an existing incorrect fwnode or device link to recreate the correct one. Signed-off-by: Michael Pratt --- drivers/mtd/mtdpart.c | 10 ---------- 1 file changed, 10 deletions(-) diff --git a/drivers/mtd/mtdpart.c b/drivers/mtd/mtdpart.c index 6811a714349d..dd2b27674f56 100644 --- a/drivers/mtd/mtdpart.c +++ b/drivers/mtd/mtdpart.c @@ -582,7 +582,6 @@ static int mtd_part_of_parse(struct mtd_info *master, { struct mtd_part_parser *parser; struct device_node *np; - struct device_node *child; struct property *prop; struct device *dev; const char *compat; @@ -600,15 +599,6 @@ static int mtd_part_of_parse(struct mtd_info *master, else np = of_get_child_by_name(np, "partitions"); - /* - * Don't create devices that are added to a bus but will never get - * probed. That'll cause fw_devlink to block probing of consumers of - * this partition until the partition device is probed. - */ - for_each_child_of_node(np, child) - if (of_device_is_compatible(child, "nvmem-cells")) - of_node_set_flag(child, OF_POPULATED); - of_property_for_each_string(np, "compatible", prop, compat) { parser = mtd_part_get_compatible_parser(compat); if (!parser)