From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Grant Likely <grant.likely@secretlab.ca>
Cc: Kay Sievers <kay.sievers@vrfy.org>,
Greg Kroah-Hartman <gregkh@suse.de>,
linux-kernel@vger.kernel.org, "Rafael J. Wysocki" <rjw@sisk.pl>,
"David S. Miller" <davem@davemloft.net>
Subject: Re: [PATCH] drivercore: Add driver probe deferral mechanism
Date: Mon, 4 Jul 2011 13:47:18 -0700 [thread overview]
Message-ID: <20110704204717.GE32624@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <20110704170949.11059.92774.stgit@ponder>
On Mon, Jul 04, 2011 at 11:11:59AM -0600, Grant Likely wrote:
> Mark, I'm particularly interested in your thoughts on this approach.
> It is decidedly "low-tech" in its approach to handling device
> dependencies, but it has the advantage of being simple and should
> handle a wide range of use-cases reliably. Would this work for ALSA
> SoC probing?
It's essentially what we're doing currently for the part of the system
where we decide that everything is registered and we should run the
actual probe functions so it'll help with that. Having a clock API we
can actually use off-SoC will help with a lot of the remaining stuff.
I *think* we'll still going to need to have the infrastructure to deal
with running all the probes together, at least for a while, as the
current code really assumes that it's got some of the card wide stuff
around when all the devices get instantiated but I think if we were
starting from fresh this would be fairly good. The only thing I can
think might be an issue is n way dependencies, but those mostly shake
out as being a dependency of the overall card on subdevices. I'd need
to separate out the implementation issues from the assumptions to be
100% clear if that was the case, though.
next prev parent reply other threads:[~2011-07-04 20:47 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-07-04 17:11 [PATCH] drivercore: Add driver probe deferral mechanism Grant Likely
2011-07-04 17:41 ` Greg KH
2011-07-04 17:56 ` Mark Brown
2011-07-04 18:01 ` Grant Likely
2011-07-05 14:21 ` Greg KH
2011-07-05 15:21 ` Arnd Bergmann
2011-07-05 15:50 ` Greg KH
2011-07-05 16:05 ` Arnd Bergmann
2011-07-05 16:27 ` Grant Likely
2011-07-05 16:11 ` Kay Sievers
2011-07-05 16:28 ` Grant Likely
2011-07-05 16:36 ` Greg KH
2011-07-05 17:17 ` Grant Likely
2011-07-05 17:29 ` Greg KH
2011-07-05 17:35 ` Grant Likely
2011-07-10 14:24 ` Kay Sievers
2011-07-05 16:33 ` Grant Likely
2011-07-05 16:05 ` Grant Likely
2011-07-04 19:56 ` Randy Dunlap
2011-07-04 20:47 ` Mark Brown [this message]
2011-07-04 23:25 ` Grant Likely
2011-07-05 6:11 ` Mark Brown
-- strict thread matches above, loose matches on Subject: below --
2012-03-05 15:47 Grant Likely
2012-03-05 17:38 ` Alan Cox
2012-03-05 17:40 ` David Daney
2012-03-05 17:50 ` Mark Brown
2012-03-05 19:15 ` Arnd Bergmann
2012-03-05 21:10 ` Grant Likely
2012-03-05 21:24 ` Greg Kroah-Hartman
2012-03-05 21:28 ` Mark Brown
2012-03-06 9:10 ` Arnd Bergmann
2012-03-05 21:47 ` Greg Kroah-Hartman
2012-03-05 22:09 ` Grant Likely
2012-03-05 22:15 ` Greg Kroah-Hartman
2012-03-06 0:08 ` Grant Likely
2012-03-06 5:28 ` Greg Kroah-Hartman
2012-03-06 7:52 ` Grant Likely
2012-03-08 20:22 ` Greg KH
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=20110704204717.GE32624@opensource.wolfsonmicro.com \
--to=broonie@opensource.wolfsonmicro.com \
--cc=davem@davemloft.net \
--cc=grant.likely@secretlab.ca \
--cc=gregkh@suse.de \
--cc=kay.sievers@vrfy.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rjw@sisk.pl \
/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