LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Greg Kroah-Hartman <email@example.com>
To: Mark Brown <firstname.lastname@example.org>
Cc: Pierre-Louis Bossart <email@example.com>,
firstname.lastname@example.org, email@example.com, firstname.lastname@example.org,
Andy Shevchenko <email@example.com>,
Dan Williams <firstname.lastname@example.org>,
Jason Gunthorpe <email@example.com>, Christoph Hellwig <firstname.lastname@example.org>,
"Rafael J . Wysocki" <email@example.com>,
Geert Uytterhoeven <firstname.lastname@example.org>
Subject: Re: [RFC PATCH 1/2] driver core: export driver_deferred_probe_trigger()
Date: Wed, 18 Aug 2021 15:22:19 +0200 [thread overview]
Message-ID: <YR0Ji7DQXoo0z4vP@kroah.com> (raw)
On Wed, Aug 18, 2021 at 12:57:36PM +0100, Mark Brown wrote:
> On Wed, Aug 18, 2021 at 07:44:39AM +0200, Greg Kroah-Hartman wrote:
> > On Tue, Aug 17, 2021 at 02:00:56PM -0500, Pierre-Louis Bossart wrote:
> > > 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?
> Through what mechanism will it happen naturally? Deferred probe
> currently only does things if things are being registered or if probes
> > > 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.
> I'm not sure I see the mess here - it's just queueing some work, one of
> the things that the workqueue stuff does well is handle things getting
> scheduled while they're already queued. Honestly having understood
> their problem I think we need to be adding these calls into all the
> resource provider APIs.
> > 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.
> That's exactly what they're doing currently and the driver core isn't
> Driver A is slow to start up and providing a resource to driver B, this
> gets handled in driver A by succeeding immediately and then registering
> the resource once the startup has completed. Unfortunately while that
> was happening not only has driver B registered and deferred but the rest
> of the probes/defers in the system have completed so the deferred probe
> mechanism is idle. Nothing currently tells the deferred probe mechanism
> that a new resource is now available so it never retries the probe of
> driver B. The only way I can see to fix this without modifying the
> driver core is to make driver A block during probe but that would at
> best slow down boot.
> 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.
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?
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?
next prev parent reply other threads:[~2021-08-18 13:22 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 [this message]
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
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--subject='Re: [RFC PATCH 1/2] driver core: export driver_deferred_probe_trigger()' \
* 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).