Re: [RFC] [PATCH 3/3] IRQ: irq domain: defer of irq ressoure resolve at platform_drv_probe
From: Arnd Bergmann <hidden>
Date: 2013-05-30 14:57:33
Possibly related (same subject, not in this thread)
- 2013-06-24 · Re: [RFC] [PATCH 3/3] IRQ: irq domain: defer of irq ressoure resolve at platform_drv_probe · Alexander Sverdlin <hidden>
- 2013-06-07 · Re: [RFC] [PATCH 3/3] IRQ: irq domain: defer of irq ressoure resolve at platform_drv_probe · Alexander Sverdlin <hidden>
- 2013-05-30 · Re: [RFC] [PATCH 3/3] IRQ: irq domain: defer of irq ressoure resolve at platform_drv_probe · Grant Likely <hidden>
- 2013-05-30 · Re: [RFC] [PATCH 3/3] IRQ: irq domain: defer of irq ressoure resolve at platform_drv_probe · Arnd Bergmann <hidden>
- 2013-05-30 · Re: [RFC] [PATCH 3/3] IRQ: irq domain: defer of irq ressoure resolve at platform_drv_probe · Grant Likely <hidden>
On Thursday 30 May 2013, Grant Likely wrote:
On Thu, May 30, 2013 at 2:10 PM, Arnd Bergmann [off-list ref] wrote:quoted
On Thursday 30 May 2013, Grant Likely wrote:
quoted
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