Re: [PATCH] drivercore: Add driver probe deferral mechanism

[Mark Brown]

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