[Ksummit-discuss] [TECH TOPIC] Addressing complex dependencies and semantics (v2)

[Luis R. Rodriguez]

On Wed, Jul 27, 2016 at 06:26:36PM +0100, Mark Brown wrote:
> > to help enable asynchronous probe, however for built-in devices this requires
> > very specific platform knowledge otherwise using async probe will blow up
> > your kernel -- if you get it right though, using async probe can help with
> 
> I'm not sure what specific platform knowledge you're thinking of here?
> We have coverage for most things in the form of deferred probe (messy
> though it is).

Deferred probe is a complete a hack and sub-optimal. Being able to address
ordering properly without much overhead would optimize this, to do this
properly though you really need to do a bit of kernel work, so in practice a
bit of delta carried. For instance, if using built-in you'd hope that all
your device ordering is already handled through the current set of init
levels of the kernel. As the kernel boots the later in boot gets the larger
the series of dependencies we can have and as such we end up running either
out of semantics for this, or knowing to to ensure proper link order is
in place. Some of this work is implicit, some explicit -- it depends on
the toolbox we use. The goal here is to evaluate the toolbox, if we should
grow it, and if so how.

> Probably worth me being involved as well, regulators seem to be among
> the devices with most visible PM related ordering issues since they are
> typically on slow buses and ASoC is all about composite devices.

Good to know thanks.

  Luis