Re: [PATCH] [RFC] OF: probe order dependency aware of_platform_populate

[Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>]

On Thu, Apr 16, 2015 at 5:40 AM, Peter Hurley <peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org> wrote:
> On 04/15/2015 10:35 AM, Rob Herring wrote:
>> On Wed, Apr 15, 2015 at 9:17 AM, Peter Hurley <peter-WaGBZJeGNqdsbIuE7sb01tBPR1lH4CV8@public.gmane.org> wrote:
>
>>> 2. Should DT-specific drivers not be using irq_of_parse_and_map()?
>>>    On probe failure irq_dispose_mapping() will be junking the mapping,
>>>    thus invalidating the irq assignment in the platform resource table,
>>>    which breaks platform drivers which might otherwise probe successfully.
>>
>> Generally no, they should not use irq_of_parse_and_map as we want
>> drivers to work with platform_data, DT, ACPI, or Bob's Firmware
>> Interface. I think most users are PPC drivers which don't have so much
>> of the probe ordering problems.
>
> Apologies for hijacking this thread for a moment.
>
> If of_device_alloc() creates the irq mapping, and no driver probes succeed,
> what is disposing the mapping?
>
> Similarly, if a platform driver fails its probe after platform_get_irq()
> what should dispose of that mapping?

The mapping is created by the irqchip init, not of_device_alloc or
platform_get_irq. Disposing would occur when the irqchip is hot
unplugged. Perhaps we could save some memory by also creating the
irqdesc when we probe. Of course, the resources set by of_device_alloc
would be stale if unplug happened, but platform_get_irq would be okay.
However, I think we don't reference count irqchips to prevent their
hot unplug while in use. GPIOs have similar hotplug issues and that is
being worked on.

Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html