Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1417858
| From | "Rafael J. Wysocki" <rafael@kernel.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC][PATCH 2/5] driver core: Functional dependencies tracking support |
| Date | 2016-06-08 22:50 +0200 |
| Message-ID | <rHSAh-4ZD-5@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <qQFmF-8hY-7@gated-at.bofh.it> <qQFmG-8hY-9@gated-at.bofh.it> <rHL5M-aT-17@gated-at.bofh.it> <rHQf8-3Ci-21@gated-at.bofh.it> <rHQyu-3JS-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Wed, Jun 8, 2016 at 8:35 PM, Mark Brown <broonie@kernel.org> wrote: > 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. If that's a non-child device, I would expect it to exist beforehand and then the link creation would only enforce the specific ordering of certain operations (like runtime PM or async suspend/resume) between the two devices linked by it. That shouldn't be problematic in principle. Let me redo the series, though (that may take a couple of days realistically).
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [RFC][PATCH 2/5] driver core: Functional dependencies tracking support Mark Brown <broonie@kernel.org> - 2016-06-08 14:50 +0200
Re: [RFC][PATCH 2/5] driver core: Functional dependencies tracking support "Rafael J. Wysocki" <rafael@kernel.org> - 2016-06-08 20:20 +0200
Re: [RFC][PATCH 2/5] driver core: Functional dependencies tracking support Mark Brown <broonie@kernel.org> - 2016-06-08 20:40 +0200
Re: [RFC][PATCH 2/5] driver core: Functional dependencies tracking support "Rafael J. Wysocki" <rafael@kernel.org> - 2016-06-08 22:50 +0200
Re: [RFC][PATCH 2/5] driver core: Functional dependencies tracking support Mark Brown <broonie@kernel.org> - 2016-06-09 00:30 +0200
csiph-web