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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAJZ5v0ipDXrgx3=cFuxzofkXLMzErETuqSSnf8ugo5jnB0ynNA@mail.gmail.com>
Date:	Wed, 8 Jun 2016 20:12:34 +0200
From:	"Rafael J. Wysocki" <rafael@...nel.org>
To:	Mark Brown <broonie@...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.og>, 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 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.

This series was supposed to help with dependencies that aren't of the
parent-child type.