Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1417377 > unrolled thread

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

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

#1417377 — Re: [RFC][PATCH 2/5] driver core: Functional dependencies tracking support

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [next] | [standalone]

#1417750 — Re: [RFC][PATCH 2/5] driver core: Functional dependencies tracking support

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.

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

[toc] | [prev] | [next] | [standalone]

#1417759

[Multipart message — attachments visible in raw view] — view raw

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.

[toc] | [prev] | [next] | [standalone]

#1417858 — Re: [RFC][PATCH 2/5] driver core: Functional dependencies tracking support

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).

[toc] | [prev] | [next] | [standalone]

#1417920

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jun 08, 2016 at 10:48:23PM +0200, Rafael J. Wysocki wrote:
> On Wed, Jun 8, 2016 at 8:35 PM, Mark Brown <broonie@kernel.org> wrote:

> > 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

No, it's an actual child.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web