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

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

On Wednesday, July 27, 2016 09:20:40 PM Luis R. Rodriguez wrote:
> On Wed, Jul 27, 2016 at 07:03:46PM +0100, Mark Brown wrote:
> > On Wed, Jul 27, 2016 at 07:58:29PM +0200, Luis R. Rodriguez wrote:
> > > 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
> > 
> > Sure, I don't think anyone disagrees on that but it does mean we don't
> > actually blow up easily like we used to - it's messy but it does get
> > there safely.
> 
> Good point, without learning from the past we would otherwise expect
> this is just a sloppy situation, so indeed deferred probe had its
> merits, and we're at least now safe. The goal here is then how to
> do this better, optimized and make it a non-hack.

Well, my patchset uses deferred probing, so it won't help much here I guess.

> > I was specifically querying your statement that things would blow up.
> 
> In practice this varies as it depends on the device driver or component,
> but the general theme seems to be "relying on something which is not
> yet available".

Not only that.

There also is a "relying on something that is not a direct ancestor of the
device you care about" angle of that.

The device hierarchy as we know it is insufficient for representing dependencies
beyond parent-child and that really is part of the problem, and a significant
one IMO.

Thanks,
Rafael