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

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

On Thursday, July 28, 2016 12:54:47 PM Hans Verkuil wrote:
> 
> On 07/28/2016 12:41 PM, Laurent Pinchart wrote:
> > On Thursday 28 Jul 2016 02:54:56 Rafael J. Wysocki wrote:
> >> 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.
> > 
> > Let's not demonize deferred probing, I think it's a good safety net to be used 
> > as a last resort when everything else failed. The problem is that we're using 
> > it as our primary mean to order initialization, and that leads to all sorts of 
> > inefficient behaviours at boot time.
> > 
> >> 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.
> > 
> > That's the core of the issue.
> > 
> > Linux has traditionally represented the device hierarchy from a control bus 
> > point of view, both in the driver model and in DT. We know other dependencies 
> > exist (data bus access, clocks, regulators, power domains, ...), and we try to 
> > address them with various heuristics.
> > 
> > One problem with those other dependencies is that they can't always be 
> > expressed as a tree and may a graph instead. Worse, in some cases, the graph 
> > can be cyclic (I've recently been told about an external I2C-based PLL that 
> > takes an input clock and generates an output clock, with the input clock being 
> > produced by an on-SoC sound device and the output clock being used by the same 
> > sound device). Even when individual resource trees or graphs are not cyclic, 
> > combining them in a global dependency graph will often result in cycles. The 
> > challenge is to find a proper way to both express the dependency graph and 
> > break the cycles.
> > 
> 
> Do we need to capture 100% of all the weird and wonderful dependencies? I think
> (speaking for the media subsystem) that the vast majority of the dependencies
> are pretty simple trees without cycles. Being able to capture that would be a
> huge help. The remaining more complex devices could still fall back on deferred
> probe, I'd say.
> 
> I'm never very keen on creating complex code to cater to a small percentage of
> problem cases.

The problem I'm interested in (and the patches posted are designed to help
address) is specifically when the dependency graph is not a tree.  However,
I don't think it is necessary to cover cycles in a generic way (as they should
be rare enough).

Thanks,
Rafael