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 15:10:33 +0200 Message-ID: <201305301510.33650.arnd@arndb.de> References: <20130528145219.GA30411@game.jcrosoft.org> <201305300952.06036.arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: 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 , Ralf Baechle , Rob Herring List-Id: devicetree@vger.kernel.org On Thursday 30 May 2013, Grant Likely wrote: > On Thu, May 30, 2013 at 8:52 AM, Arnd Bergmann wrote: > > > > 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. Right, so we clearly need it. I also though of a second case, which is that the xlate() function might itself return -EPROBE_DEFER in the case that the irqchip driver is registered but e.g. not the parent of a cascaded irqchip. Arnd