LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
	alsa-devel@alsa-project.org, tiwai@suse.de, 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 14:48:14 +0100	[thread overview]
Message-ID: <20210818134814.GF4177@sirena.org.uk> (raw)
In-Reply-To: <YR0Ji7DQXoo0z4vP@kroah.com>

[-- Attachment #1: Type: text/plain, Size: 2242 bytes --]

On Wed, Aug 18, 2021 at 03:22:19PM +0200, Greg Kroah-Hartman wrote:
> On Wed, Aug 18, 2021 at 12:57:36PM +0100, Mark Brown wrote:

> > The issue is that the driver core is using drivers completing probe as a
> > proxy for resources becoming available.  That works most of the time
> > because most probes are fully synchronous but it breaks down if a
> > resource provider registers resources outside of probe, we might still
> > be fine if system boot is still happening and something else probes but
> > only through luck.

> The driver core is not using that as a proxy, that is up to the driver
> itself or not.  All probe means is "yes, this driver binds to this
> device, thank you!" for that specific bus/class type.  That's all, if
> the driver needs to go off and do real work before it can properly
> control the device, wonderful, have it go and do that async.

Right, which is what is happening here - but the deferred probe
machinery in the core is reading more into the probe succeeding than it
should.

> So if you know you should be binding to the device, great, kick off some
> other work and return success from probe.  There's no reason you have to
> delay or defer for no good reason, right?

The driver that's deferring isn't the one that takes a long time to
probe - the driver that's deferring depends on the driver that takes a
long time to probe, it defers because the resource it needs isn't
available when it tries to probe as the slow device is still doing it's
thing asynchronously.  The problem is that the driver core isn't going
back and attempting to probe the deferred device again once the driver
that took a long time has provided resources.

> But yes, if you do get new resources, the probe should be called again,
> that's what the deferred logic is for (or is that the link logic, I
> can't recall)  This shouldn't be a new thing, no needing to call the
> driver core directly like this at all, it should "just happen", right?

How specifically does new resources becoming available directly cause
a new probe deferral run at the moment?  I can't see anything that
resource provider APIs are doing to say that a new resource has become
available, this patch is trying to provide something they can do.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

  reply	other threads:[~2021-08-18 13:48 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
2021-08-18 11:57     ` Mark Brown
2021-08-18 13:22       ` Greg Kroah-Hartman
2021-08-18 13:48         ` Mark Brown [this message]
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=20210818134814.GF4177@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=alsa-devel@alsa-project.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --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=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).