Re: [RFC/RFT][PATCH v3 0/5] Functional dependencies between devices

From: Rafael J. Wysocki
Date: Wed Sep 28 2016 - 20:45:35 EST

On Wednesday, September 28, 2016 01:42:20 PM Lukas Wunner wrote:
> On Wed, Sep 28, 2016 at 02:33:21AM +0200, Rafael J. Wysocki wrote:
> > On Tuesday, September 27, 2016 02:34:29 PM Lukas Wunner wrote:
> > > I made some notes while reviewing the state machine in patch 2 of this
> > > series and thought, why not rework it into something that could eventually
> > > go into the Documentation/ tree?
> > >
> > > So here's an initial draft. There's some introductory text plus
> > > a description of the state machine. Just putting this out there now
> > > to ease reviewers' lives, despite the obvious WIP status. I'll try to
> > > amend it as the series converges.
> > >
> > > This is already rst-formatted but I haven't actually run it through
> > > sphinx yet.
> >
> > Thanks a lot for doing this!
> >
> > It looks good to me in general. I think it would be good to add it to the
> > series at one point (if you don't mind).
> Sure thing, thanks.
> > I'm only a bit reluctant about advertising the usage of links between
> > children and parents, because that doesn't look like the right tool for
> > the purpose (as I said before, I'd prefer to add a device flag causing
> > the parent driver to be probed before the child one if needed).
> That wouldn't cover the unbinding of the child when the parent unbinds
> though, so it would only be a subset of the functionality offered by
> device links.
> I actually don't know of a use case where driver presence is needed
> between parent and child. But the patches look like they should work
> out of the box in such a scenario, so I was thinking, why forbid it?
> Someone might just try that because they think it should obviously work,
> and then they'll find out at runtime that it's forbidden. That gives
> us only a score of 5 in Rusty's API rating scheme.
> However for consistency, if you do want to forbid it, I think it should
> be forbidden for all ancestors of the device, not just the parent as v3
> does it. (Suspend/resume + shutdown ordering is already handled for
> hierarchical dependencies, i.e. all ancestors.)

Well, there is a difference between allowing something to be done and
documenting it as a good idea. :-)