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

[Arnd Bergmann]

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.

	Arnd