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 16:57:33 +0200 Message-ID: <201305301657.34093.arnd@arndb.de> References: <20130528145219.GA30411@game.jcrosoft.org> <201305301510.33650.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 2:10 PM, Arnd Bergmann wrote: > > On Thursday 30 May 2013, Grant Likely wrote: > > 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. > > That shouldn't happen. If the parent isn't registered, then how can > the child set itself up? I guess it can just register the domain, but as long as no irqs are needed, it doesn't have to set up a chained handler. I don't think any irqchip driver today does it that way, but I think there is nothing stopping us from doing a driver that does. Arnd