linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
To: alsa-devel@alsa-project.org
Cc: tiwai@suse.de, broonie@kernel.org, vkoul@kernel.org,
	liam.r.girdwood@linux.intel.com,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	Dan Williams <dan.j.williams@intel.com>,
	Jason Gunthorpe <jgg@nvidia.com>, Christoph Hellwig <hch@lst.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	linux-kernel@vger.kernel.org,
	Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	Geert Uytterhoeven <geert@linux-m68k.org>
Subject: [RFC PATCH 1/2] driver core: export driver_deferred_probe_trigger()
Date: Tue, 17 Aug 2021 14:00:56 -0500	[thread overview]
Message-ID: <20210817190057.255264-2-pierre-louis.bossart@linux.intel.com> (raw)
In-Reply-To: <20210817190057.255264-1-pierre-louis.bossart@linux.intel.com>

The premise of the deferred probe implementation is that a successful
driver binding is a proxy for the resources provided by this driver
becoming available. While this is a correct assumption in most of the
cases, there are exceptions to the rule such as

a) the use of request_firmware_nowait(). In this case, the resources
may become available when the 'cont' callback completes, for example
when if the firmware needs to be downloaded and executed on a SoC
core or DSP.

b) a split implementation of the probe with a workqueue when one or
ore request_module() calls are required: a synchronous probe prevents
other drivers from probing, impacting boot time, and an async probe is
not allowed to avoid a deadlock. This is the case on all Intel audio
platforms, with request_module() being required for the i915 display
audio and HDaudio external codecs.

In these cases, there is no way to notify the deferred probe
infrastructure of the enablement of resources after the driver
binding.

The driver_deferred_probe_trigger() function is currently used
'anytime a driver is successfully bound to a device', this patch
suggest exporing by exporting it so that drivers can kick-off
re-probing of deferred devices at the end of a deferred processing.

Signed-off-by: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
---
 drivers/base/dd.c             | 3 ++-
 include/linux/device/driver.h | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 437cd61343b2..33eca45aa65a 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -171,7 +171,7 @@ static bool driver_deferred_probe_enable = false;
  * 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;
@@ -193,6 +193,7 @@ static void driver_deferred_probe_trigger(void)
 	 */
 	queue_work(system_unbound_wq, &deferred_probe_work);
 }
+EXPORT_SYMBOL_GPL(driver_deferred_probe_trigger);
 
 /**
  * device_block_probing() - Block/defer device's probes
diff --git a/include/linux/device/driver.h b/include/linux/device/driver.h
index a498ebcf4993..2eec79d752a9 100644
--- a/include/linux/device/driver.h
+++ b/include/linux/device/driver.h
@@ -240,6 +240,7 @@ extern int driver_deferred_probe_timeout;
 void driver_deferred_probe_add(struct device *dev);
 int driver_deferred_probe_check_state(struct device *dev);
 void driver_init(void);
+void driver_deferred_probe_trigger(void);
 
 /**
  * module_driver() - Helper macro for drivers that don't do anything
-- 
2.25.1


  reply	other threads:[~2021-08-17 19:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-08-17 19:00 [RFC PATCH 0/2] driver core: kick deferred probe from delayed context Pierre-Louis Bossart
2021-08-17 19:00 ` Pierre-Louis Bossart [this message]
2021-08-18  5:44   ` [RFC PATCH 1/2] driver core: export driver_deferred_probe_trigger() Greg Kroah-Hartman
2021-08-18 11:57     ` Mark Brown
2021-08-18 13:22       ` Greg Kroah-Hartman
2021-08-18 13:48         ` Mark Brown
2021-08-18 14:51           ` Pierre-Louis Bossart
2021-08-18 14:59             ` Dan Williams
2021-08-18 15:28             ` Greg Kroah-Hartman
2021-08-18 15:53               ` Pierre-Louis Bossart
2021-08-18 16:49                 ` Greg Kroah-Hartman
2021-08-18 17:52                   ` Mark Brown
2021-08-18 18:09                   ` Pierre-Louis Bossart
2021-08-18 18:28                     ` Mark Brown
2021-08-17 19:00 ` [RFC PATCH 2/2] ASoC: SOF: trigger re-probing of deferred devices from workqueue Pierre-Louis Bossart
2021-08-18 12:07   ` Mark Brown
2021-08-18 15:25     ` Pierre-Louis Bossart

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=20210817190057.255264-2-pierre-louis.bossart@linux.intel.com \
    --to=pierre-louis.bossart@linux.intel.com \
    --cc=alsa-devel@alsa-project.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=broonie@kernel.org \
    --cc=dan.j.williams@intel.com \
    --cc=geert@linux-m68k.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hch@lst.de \
    --cc=jgg@nvidia.com \
    --cc=liam.r.girdwood@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=tiwai@suse.de \
    --cc=vkoul@kernel.org \
    /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).