netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Saravana Kannan <saravanak@google.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>,
	Kevin Hilman <khilman@kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	Joerg Roedel <joro@8bytes.org>, Will Deacon <will@kernel.org>,
	Andrew Lunn <andrew@lunn.ch>,
	Heiner Kallweit <hkallweit1@gmail.com>,
	Russell King <linux@armlinux.org.uk>,
	"David S. Miller" <davem@davemloft.net>,
	Eric Dumazet <edumazet@google.com>,
	Jakub Kicinski <kuba@kernel.org>, Paolo Abeni <pabeni@redhat.com>,
	Linus Walleij <linus.walleij@linaro.org>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Daniel Scally <djrscally@gmail.com>,
	Heikki Krogerus <heikki.krogerus@linux.intel.com>,
	Sakari Ailus <sakari.ailus@linux.intel.com>,
	Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>,
	David Ahern <dsahern@kernel.org>, Len Brown <lenb@kernel.org>
Cc: Saravana Kannan <saravanak@google.com>,
	Mark Brown <broonie@kernel.org>, Rob Herring <robh@kernel.org>,
	Geert Uytterhoeven <geert@linux-m68k.org>,
	Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>,
	John Stultz <jstultz@google.com>,
	Nathan Chancellor <nathan@kernel.org>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	kernel-team@android.com, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org, iommu@lists.linux-foundation.org,
	netdev@vger.kernel.org, linux-gpio@vger.kernel.org,
	linux-acpi@vger.kernel.org
Subject: [RFC PATCH v1 7/9] driver core: Add fw_devlink_unblock_may_probe() helper function
Date: Thu, 26 May 2022 01:15:46 -0700	[thread overview]
Message-ID: <20220526081550.1089805-8-saravanak@google.com> (raw)
In-Reply-To: <20220526081550.1089805-1-saravanak@google.com>

This function can be used during the kernel boot sequence to forcefully
override fw_devlink=on and unblock the probing of all devices that have
a driver.

It's mainly meant to be called from late_initcall() or
late_initcall_sync() where a device needs to probe before the kernel can
mount rootfs.

Signed-off-by: Saravana Kannan <saravanak@google.com>
---
 drivers/base/base.h    |  1 +
 drivers/base/core.c    | 58 ++++++++++++++++++++++++++++++++++++++++++
 drivers/base/dd.c      |  2 +-
 include/linux/fwnode.h |  2 ++
 4 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/drivers/base/base.h b/drivers/base/base.h
index ab71403d102f..b3a43a164dcd 100644
--- a/drivers/base/base.h
+++ b/drivers/base/base.h
@@ -160,6 +160,7 @@ extern int devres_release_all(struct device *dev);
 extern void device_block_probing(void);
 extern void device_unblock_probing(void);
 extern void deferred_probe_extend_timeout(void);
+extern void driver_deferred_probe_trigger(void);
 
 /* /sys/devices directory */
 extern struct kset *devices_kset;
diff --git a/drivers/base/core.c b/drivers/base/core.c
index 7672f23231c1..7ff7fbb00643 100644
--- a/drivers/base/core.c
+++ b/drivers/base/core.c
@@ -1655,6 +1655,64 @@ void fw_devlink_drivers_done(void)
 	device_links_write_unlock();
 }
 
+static int fw_devlink_may_probe(struct device *dev, void *data)
+{
+	struct device_link *link = to_devlink(dev);
+
+	if (!link->supplier->can_match && link->consumer->can_match)
+		fw_devlink_relax_link(link);
+
+	return 0;
+}
+
+/**
+ * fw_devlink_unblock_may_probe - Force unblock any device that has a driver
+ *
+ * This function is more of a sledge hammer than a scalpel. Use this very
+ * sparingly.
+ *
+ * Some devices might need to be probed and bound successfully before the kernel
+ * boot sequence can finish and move on to init/userspace. For example, a
+ * network interface might need to be bound to be able to mount a NFS rootfs.
+ *
+ * With fw_devlink=on by default, some of these devices might be blocked from
+ * probing because they are waiting on a optional supplier that doesn't have a
+ * driver. While fw_devlink will eventually identify such devices and unblock
+ * the probing automatically, it might be too late by the time it unblocks the
+ * probing of devices. For example, the IP4 autoconfig might timeout before
+ * fw_devlink unblocks probing of the network interface. This function is
+ * available to unblock the probing of such devices.
+ *
+ * Since there's no easy way to know which unprobed device needs to probe for
+ * boot to succeed, this function makes sure fw_devlink doesn't block any device
+ * that has a driver at the point in time this function is called.
+ *
+ * It does this by relaxing (fw_devlink=permissive behavior) all the device
+ * links created by fw_devlink where the consumer has a driver and the supplier
+ * doesn't have a driver.
+ *
+ * It's extremely unlikely that a proper use of this function will be outside of
+ * an initcall. So, until a case is made for that, this function is
+ * intentionally marked with __init.
+ */
+void __init fw_devlink_unblock_may_probe(void)
+{
+	struct device_link *link, *ln;
+
+	if (!fw_devlink_flags || fw_devlink_is_permissive())
+		return;
+
+	/* Wait for current probes to finish to limit impact. */
+	wait_for_device_probe();
+
+	device_links_write_lock();
+	class_for_each_device(&devlink_class, NULL, NULL,
+			      fw_devlink_may_probe);
+	device_links_write_unlock();
+
+	driver_deferred_probe_trigger();
+}
+
 static void fw_devlink_unblock_consumers(struct device *dev)
 {
 	struct device_link *link;
diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index f963d9010d7f..af8138d44e6c 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -172,7 +172,7 @@ static bool driver_deferred_probe_enable;
  * changes in the midst of a probe, then deferred processing should be triggered
  * again.
  */
-static void driver_deferred_probe_trigger(void)
+void driver_deferred_probe_trigger(void)
 {
 	if (!driver_deferred_probe_enable)
 		return;
diff --git a/include/linux/fwnode.h b/include/linux/fwnode.h
index 9a81c4410b9f..0770edda7068 100644
--- a/include/linux/fwnode.h
+++ b/include/linux/fwnode.h
@@ -13,6 +13,7 @@
 #include <linux/list.h>
 #include <linux/bits.h>
 #include <linux/err.h>
+#include <linux/init.h>
 
 struct fwnode_operations;
 struct device;
@@ -199,5 +200,6 @@ extern bool fw_devlink_is_strict(void);
 int fwnode_link_add(struct fwnode_handle *con, struct fwnode_handle *sup);
 void fwnode_links_purge(struct fwnode_handle *fwnode);
 void fw_devlink_purge_absent_suppliers(struct fwnode_handle *fwnode);
+void __init fw_devlink_unblock_may_probe(void);
 
 #endif
-- 
2.36.1.124.g0e6072fb45-goog


  parent reply	other threads:[~2022-05-26  8:17 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-26  8:15 [RFC PATCH v1 0/9] deferred_probe_timeout logic clean up Saravana Kannan
2022-05-26  8:15 ` [RFC PATCH v1 1/9] PM: domains: Delete usage of driver_deferred_probe_check_state() Saravana Kannan
2022-05-26  8:15 ` [RFC PATCH v1 2/9] pinctrl: devicetree: " Saravana Kannan
2022-05-30  9:22   ` Geert Uytterhoeven
2022-06-05  3:41     ` Saravana Kannan
2022-06-06 10:17       ` Andy Shevchenko
2022-05-26  8:15 ` [RFC PATCH v1 3/9] net: mdio: " Saravana Kannan
2022-05-26  8:15 ` [RFC PATCH v1 4/9] Revert "driver core: Set default deferred_probe_timeout back to 0." Saravana Kannan
2022-05-30  9:12   ` Geert Uytterhoeven
2022-06-05  3:18     ` Saravana Kannan
2022-06-05  4:12       ` Saravana Kannan
2022-05-26  8:15 ` [RFC PATCH v1 5/9] driver core: Set fw_devlink.strict=1 by default Saravana Kannan
2022-05-26  8:15 ` [RFC PATCH v1 6/9] iommu/of: Delete usage of driver_deferred_probe_check_state() Saravana Kannan
2022-05-26  8:15 ` Saravana Kannan [this message]
2022-05-30  9:46   ` [RFC PATCH v1 7/9] driver core: Add fw_devlink_unblock_may_probe() helper function Andy Shevchenko
2022-05-26  8:15 ` [RFC PATCH v1 8/9] net: ipconfig: Force fw_devlink to unblock any devices that might probe Saravana Kannan
2022-06-07 12:36   ` Geert Uytterhoeven
2022-05-26  8:15 ` [RFC PATCH v1 9/9] driver core: Delete driver_deferred_probe_check_state() Saravana Kannan
2022-05-30  8:49 ` [RFC PATCH v1 0/9] deferred_probe_timeout logic clean up Sebastian Andrzej Siewior
2022-06-05  3:45   ` Saravana Kannan
2022-05-30  9:38 ` Geert Uytterhoeven
2022-06-05  3:47   ` Saravana Kannan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20220526081550.1089805-8-saravanak@google.com \
    --to=saravanak@google.com \
    --cc=andrew@lunn.ch \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=bigeasy@linutronix.de \
    --cc=broonie@kernel.org \
    --cc=davem@davemloft.net \
    --cc=djrscally@gmail.com \
    --cc=dsahern@kernel.org \
    --cc=edumazet@google.com \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=heikki.krogerus@linux.intel.com \
    --cc=hkallweit1@gmail.com \
    --cc=iommu@lists.linux-foundation.org \
    --cc=joro@8bytes.org \
    --cc=jstultz@google.com \
    --cc=kernel-team@android.com \
    --cc=khilman@kernel.org \
    --cc=kuba@kernel.org \
    --cc=len.brown@intel.com \
    --cc=lenb@kernel.org \
    --cc=linus.walleij@linaro.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux@armlinux.org.uk \
    --cc=nathan@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=rafael@kernel.org \
    --cc=robh@kernel.org \
    --cc=sakari.ailus@linux.intel.com \
    --cc=ulf.hansson@linaro.org \
    --cc=will@kernel.org \
    --cc=yoshfuji@linux-ipv6.org \
    --cc=yoshihiro.shimoda.uh@renesas.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).