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

Jean-Christophe PLAGNIOL-VILLARD plagnioj at jcrosoft.com
Thu May 30 20:24:41 EST 2013


On 09:52 Thu 30 May     , Arnd Bergmann 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.
this is where I disagre we can have 2 interrupt-parent, this is why I get
other issue on some devices as you get interrupts from the code controller and
then use an irq on a gpio controller so you end up with 2 :(

Assume we can only have one will end-up with issue to descript such hardware

as example I comment some TI patch where we need such configuration

Best Regards,
J.
> 
> 	Arnd


More information about the devicetree-discuss mailing list