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

Groups > linux.kernel > #1220149 > unrolled thread

Re: [PATCH v3 02/18] of/platform: add of_platform_probe

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: [PATCH v3 02/18] of/platform: add of_platform_probe Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-07 14:40 +0200
    Re: [PATCH v3 02/18] of/platform: add of_platform_probe Mark Brown <broonie@kernel.org> - 2015-09-11 12:00 +0200
      Re: [PATCH v3 02/18] of/platform: add of_platform_probe Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-11 16:10 +0200
        Re: [PATCH v3 02/18] of/platform: add of_platform_probe Mark Brown <broonie@kernel.org> - 2015-09-11 17:40 +0200
          Re: [PATCH v3 02/18] of/platform: add of_platform_probe Tomeu Vizoso <tomeu.vizoso@collabora.com> - 2015-09-15 15:10 +0200

#1220149 — Re: [PATCH v3 02/18] of/platform: add of_platform_probe

On 11 August 2015 at 11:37, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
> On 7 August 2015 at 14:19, Mark Brown <broonie@kernel.org> wrote:
>> On Thu, Aug 06, 2015 at 04:11:39PM +0200, Tomeu Vizoso wrote:
>>
>>> Walks the OF tree up and finds the closest ancestor that has a platform
>>> device associated with it, probing it if isn't bound to a driver yet.
>>
>>> The above should ensure that the dependency represented by the passed OF
>>> node is available, because probing a platform device should cause its
>>> descendants to be probed as well.
>>
>> This sounds like it's going to break in the case where we have MFDs that
>> represent their functions in DT (not a pattern I'm a fan of but it's a
>> thing people do).  We'll walk back to the platform device for the MFD
>> function, try to probe it and then give up.  Perhaps that's good enough
>> anyway but it's not clear to me why we don't just try every parent we
>> find?
>
> Agreed. In the attempt at probing dependencies before a device is
> probed, I considered that a device's parent is also a dependency and
> that worked well. From what I saw, few devices will defer their probe
> if their parent hasn't been probed yet, assuming that it will have
> probed already. But with simple-mfd and simple-bus that shouldn't be
> relied upon as things will break if their parents defer their probe.
> With async probing enabled this failure scenario becomes more
> probable.

Actually I'm not sure how we could probe the ascendants on demand, as
currently the parent's device lock is taken when probing so trying to
probe a sibling from within a probe callback will cause a deadlock.

AFAICS this is only needed for USB interface devices and this
behaviour could be limited to them, but I don't like much assuming
that no USB device will ever have a dependency on a sibling (though
that probably won't happen ever).

Regards,

Tomeu

>> I'm also not a fan of the fact that the interface here is explicitly
>> saying that we want to probe a platform device, that's an implementation
>> detail that callers shouldn't need to know about.  From the point of
>> view of the callers what they're trying to do is kick any dependencies
>> into being instantiated, the fact that we currently try to accomplish it
>> with platform devices isn't something they care about.
>
> Agreed.
>
> Thanks,
>
> Tomeu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1222669

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

On Mon, Sep 07, 2015 at 02:31:06PM +0200, Tomeu Vizoso wrote:
> On 11 August 2015 at 11:37, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
> > On 7 August 2015 at 14:19, Mark Brown <broonie@kernel.org> wrote:

> >> This sounds like it's going to break in the case where we have MFDs that
> >> represent their functions in DT (not a pattern I'm a fan of but it's a
> >> thing people do).  We'll walk back to the platform device for the MFD
> >> function, try to probe it and then give up.  Perhaps that's good enough
> >> anyway but it's not clear to me why we don't just try every parent we
> >> find?

> > Agreed. In the attempt at probing dependencies before a device is
> > probed, I considered that a device's parent is also a dependency and

> Actually I'm not sure how we could probe the ascendants on demand, as
> currently the parent's device lock is taken when probing so trying to
> probe a sibling from within a probe callback will cause a deadlock.

How do silbilings come into this?  There is an issue there but it's
going to happen anyway.

> AFAICS this is only needed for USB interface devices and this
> behaviour could be limited to them, but I don't like much assuming
> that no USB device will ever have a dependency on a sibling (though
> that probably won't happen ever).

I don't see the connection with USB here, sorry - my initial thought was
about MFDs?

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

#1222864

On 11 September 2015 at 11:57, Mark Brown <broonie@kernel.org> wrote:
> On Mon, Sep 07, 2015 at 02:31:06PM +0200, Tomeu Vizoso wrote:
>> On 11 August 2015 at 11:37, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
>> > On 7 August 2015 at 14:19, Mark Brown <broonie@kernel.org> wrote:
>
>> >> This sounds like it's going to break in the case where we have MFDs that
>> >> represent their functions in DT (not a pattern I'm a fan of but it's a
>> >> thing people do).  We'll walk back to the platform device for the MFD
>> >> function, try to probe it and then give up.  Perhaps that's good enough
>> >> anyway but it's not clear to me why we don't just try every parent we
>> >> find?
>
>> > Agreed. In the attempt at probing dependencies before a device is
>> > probed, I considered that a device's parent is also a dependency and
>
>> Actually I'm not sure how we could probe the ascendants on demand, as
>> currently the parent's device lock is taken when probing so trying to
>> probe a sibling from within a probe callback will cause a deadlock.
>
> How do silbilings come into this?  There is an issue there but it's
> going to happen anyway.

Once a platform device (with the platform bus as its parent) is
retrieved from the deferred queue, both the parent and the device in
question are locked (because of the USB stuff mentioned below). If
that device depends on another device whose parent is the platform bus
and we try to probe it (useless, but I don't see a good way of
avoiding it) then we'll deadlock when device_attach locks that device.

>> AFAICS this is only needed for USB interface devices and this
>> behaviour could be limited to them, but I don't like much assuming
>> that no USB device will ever have a dependency on a sibling (though
>> that probably won't happen ever).
>
> I don't see the connection with USB here, sorry - my initial thought was
> about MFDs?

This commit introduced locking of a device's parent before it's
probed, mainly for USB interfaces:

bf74ad5bc417 ("[PATCH] Hold the device's parent's lock during probe and remove")

Regards,

Tomeu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

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

#1222917

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

On Fri, Sep 11, 2015 at 04:06:07PM +0200, Tomeu Vizoso wrote:

> Once a platform device (with the platform bus as its parent) is
> retrieved from the deferred queue, both the parent and the device in
> question are locked (because of the USB stuff mentioned below). If
> that device depends on another device whose parent is the platform bus
> and we try to probe it (useless, but I don't see a good way of
> avoiding it) then we'll deadlock when device_attach locks that device.

Ugh, that's nasty.  Trying to fix this would most likely devolve into
trying to shove things onto the deferred list in the right order but
that's definitely a very different solution with problems.

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

#1225078

On 11 September 2015 at 17:35, Mark Brown <broonie@kernel.org> wrote:
> On Fri, Sep 11, 2015 at 04:06:07PM +0200, Tomeu Vizoso wrote:
>
>> Once a platform device (with the platform bus as its parent) is
>> retrieved from the deferred queue, both the parent and the device in
>> question are locked (because of the USB stuff mentioned below). If
>> that device depends on another device whose parent is the platform bus
>> and we try to probe it (useless, but I don't see a good way of
>> avoiding it) then we'll deadlock when device_attach locks that device.
>
> Ugh, that's nasty.  Trying to fix this would most likely devolve into
> trying to shove things onto the deferred list in the right order but
> that's definitely a very different solution with problems.

Well, that's effectively what my "ordered probing" series did (and
indeed didn't have this problem and parents were made sure to have
probed before their children), but if we want to have dependency
information before the probe starts, then we cannot reuse the
implementation of the DT bindings that we already have in the resource
getters as this series do.

Regards,

Tomeu
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web