LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
Cc: alsa-devel@alsa-project.org, 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>,
	"Rafael J . Wysocki" <rafael@kernel.org>,
	linux-kernel@vger.kernel.org,
	Geert Uytterhoeven <geert@linux-m68k.org>
Subject: Re: [RFC PATCH 1/2] driver core: export driver_deferred_probe_trigger()
Date: Wed, 18 Aug 2021 07:44:39 +0200	[thread overview]
Message-ID: <YRyeR6imvSwOOasQ@kroah.com> (raw)
In-Reply-To: <20210817190057.255264-2-pierre-louis.bossart@linux.intel.com>

On Tue, Aug 17, 2021 at 02:00:56PM -0500, Pierre-Louis Bossart wrote:
> 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.

Then just wait for it to happen naturally?

> 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.

I really do not want to export this as it will get really messy very
quickly with different drivers/busses attempting to call this.

Either handle it in your driver (why do you have to defer probe at all,
just succeed and move on to register the needed stuff after you are
initialized) or rely on the driver core here.

thanks,

greg k-h

  reply	other threads:[~2021-08-18  5:44 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 ` [RFC PATCH 1/2] driver core: export driver_deferred_probe_trigger() Pierre-Louis Bossart
2021-08-18  5:44   ` Greg Kroah-Hartman [this message]
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=YRyeR6imvSwOOasQ@kroah.com \
    --to=gregkh@linuxfoundation.org \
    --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=hch@lst.de \
    --cc=jgg@nvidia.com \
    --cc=liam.r.girdwood@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pierre-louis.bossart@linux.intel.com \
    --cc=rafael@kernel.org \
    --cc=tiwai@suse.de \
    --cc=vkoul@kernel.org \
    --subject='Re: [RFC PATCH 1/2] driver core: export driver_deferred_probe_trigger()' \
    /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

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).