[RFC] [PATCH 3/3] IRQ: irq domain: defer of irq ressoure resolve at platform_drv_probe

[Grant Likely]

On Thu, May 30, 2013 at 8:52 AM, Arnd Bergmann <arnd at arndb.de> wrote:
> On Thursday 30 May 2013, Grant Likely wrote:
>> On Tue, 28 May 2013 17:08:49 +0200, Jean-Christophe PLAGNIOL-VILLARD <plagnioj at jcrosoft.com> wrote:
>> >
>> >  /**
>> > + * of_device_alloc_irq - initialize irq of an platfrom_device
>> > + * @dev: plaform_device to work on
>> > + */
>> > +int of_device_init_irq(struct platform_device *dev)
>> > +{
>> > +   struct device_node *np = dev->dev.of_node;
>> > +   int num_irq;
>> > +   int ret;
>> > +   struct resource *res = dev->resource;
>> > +
>> > +   if (!np)
>> > +           return 0;
>> > +
>> > +   num_irq = of_irq_count(np);
>> > +   if (!num_irq)
>> > +           return 0;
>> > +
>> > +   res += dev->num_resources - num_irq;
>>
>> This is a little fragile. Instead of statically calculating the offset,
>> scan the table and make *absolutely* sure that there is a free block of
>> irq resources.
>>
>> Also, if the table has already been populated successfully, then that
>> should be checked for. That would prevent the same table from being
>> parsed over and over in the case of a device that keeps getting
>> deferred.
>>
>> Finally, if it fails, make sure any entries that have been filled in get
>> cleared out again before exiting.
>
> Can we actually ever get a case where mapping a subset of the interrupts
> fail but works at a later point? If not, we could just return a fatal
> error here and won't get called again.
>
> Since a platform device only has one "interrupt-parent", as soon as
> one of the interrupts can get mapped, I would expect that the controller
> is present, and we don't need to defer the probing any more.

If it goes through an interrupt map node then it may only be able to
resolve a subset.

g.