From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [RFC] [PATCH 3/3] IRQ: irq domain: defer of irq ressoure resolve at platform_drv_probe Date: Thu, 30 May 2013 09:52:05 +0200 Message-ID: <201305300952.06036.arnd@arndb.de> References: <20130528145219.GA30411@game.jcrosoft.org> <1369753729-12997-3-git-send-email-plagnioj@jcrosoft.com> <20130529224814.3F8F53E16F4@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <20130529224814.3F8F53E16F4@localhost> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: devicetree-discuss-bounces+gldd-devicetree-discuss=m.gmane.org-uLR06cmDAlY/bJ5BZ2RsiQ@public.gmane.org Sender: "devicetree-discuss" To: Grant Likely Cc: devicetree-discuss-mnsaURCQ41sdnm+yROfE0A@public.gmane.org, Ralf Baechle , Rob Herring List-Id: devicetree@vger.kernel.org On Thursday 30 May 2013, Grant Likely wrote: > On Tue, 28 May 2013 17:08:49 +0200, Jean-Christophe PLAGNIOL-VILLARD 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