linux-kernel - Re: [RFC][PATCH 2/5] driver core: Functional dependencies tracking support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 8 Jun 2016 19:35:35 +0100
From:	Mark Brown <broonie@...nel.org>
To:	"Rafael J. Wysocki" <rafael@...nel.org>
Cc:	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Linux PM list <linux-pm@...r.kernel.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Alan Stern <stern@...land.harvard.edu>,
	Grant Likely <grant.likely@...aro.org>,
	Mark Brown <broonie@...nel.org>, Rob Herring <robh@...nel.org>,
	Tomeu Vizoso <tomeu.vizoso@...labora.com>,
	Thierry Reding <treding@...dia.com>,
	Dmitry Torokhov <dtor@...gle.com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Michael Turquette <mturquette@...libre.com>
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@...nel.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.

Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)