Messages in this thread | | | Date | Wed, 8 Jun 2016 19:35:35 +0100 | From | Mark Brown <> | Subject | Re: [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] | |