lkml.org 
[lkml]   [2016]   [Jun]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 2/5] driver core: Functional dependencies tracking support
On Wed, Jun 08, 2016 at 08:12:34PM +0200, Rafael J. Wysocki wrote:
> On Wed, Jun 8, 2016 at 2:48 PM, Mark Brown <broonie@kernel.org> wrote:
> > On Thu, Jan 14, 2016 at 02:54:17AM +0100, Rafael J. Wysocki wrote:

> >> + * A side effect of the link creation is re-ordering of dpm_list and the
> >> + * devices_kset list by moving the consumer device and all devices depending
> >> + * on it to the ends of those lists.

> > How does this work in the scenario where a device instantiates a child
> > device then uses services that child provides to complete the
> > initializiation? We do have that scenario currently for on chip
> > regulators to allow external regulators to be used.

> I'm not sure I understand the question correctly, but it that is the
> parent and a child, we don't need an extra link entity to represent
> that dependency, as parent-child dependencies are taken by the current
> code into account already.

A parent (especially a MFD) may create a child to fulfil a role that
could also be filled by a non-parent device, if that happens then
depending on what ends up creating these links (it's not 100% clear from
this series) it's likely that the link creation will also end up
registering a dependency unless we do something special. Now I think
about it this does depend on how we create the children though, it's
less likely to be an issue if the dependencies are created by firmware
code.
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2016-06-08 21:01    [W:0.076 / U:1.196 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site