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 > > <[email protected]> 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 _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
