On Thu, May 30, 2013 at 8:52 AM, Arnd Bergmann <[email protected]> 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.
If it goes through an interrupt map node then it may only be able to resolve a subset. g. _______________________________________________ devicetree-discuss mailing list [email protected] https://lists.ozlabs.org/listinfo/devicetree-discuss
