[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