linux-kernel - Re: [PATCH] drivercore: Add driver probe deferral mechanism

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20110704232509.GA12824@ponder.secretlab.ca>
Date:	Mon, 4 Jul 2011 17:25:09 -0600
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Cc:	Kay Sievers <kay.sievers@...y.org>,
	Greg Kroah-Hartman <gregkh@...e.de>,
	linux-kernel@...r.kernel.org, "Rafael J. Wysocki" <rjw@...k.pl>,
	"David S. Miller" <davem@...emloft.net>
Subject: Re: [PATCH] drivercore: Add driver probe deferral mechanism

On Mon, Jul 04, 2011 at 01:47:18PM -0700, Mark Brown wrote:
> 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.

Is that the bit that snd_soc_instantiate_cards() is doing?  If I made 
snd_soc_register_card() attempt to instantiate immediately and return
-EAGAIN if resources were not available, it looks like I should be
able to remove the card_list entirely.  Would that be the right way to
go about it?

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

I'm not sure what you're getting at here.  Are you talking about the
infrastructure to keep track of codecs, DAIs and the like?  Yes, that
infrastructure is still needed because the drivers need an api for
each of the kinds of resources it needs.

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

Do you have an example?  I don't see any problems with complex
dependencies providing that none of them are circular.  If, say,
device A depends on B and C, and B also depends on C, then it may take
a couple of cycles before everything gets probed, but it all still
works correctly.

g.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/