On Thu, Jun 12, 2014 at 04:05:32PM +0200, Arnd Bergmann wrote:
> This driver defines its own irqchip using the generic chip
> infrastructure, and hence needs the GENERIC_IRQ_CHIP Kconfig
> symbol enabled, or get this build error:
>
> drivers/built-in.o: In function `ipu_probe':
> :(.text+0x49ea4c): undefined reference to `irq_generic_chip_ops'
> :(.text+0x49ea5c): undefined reference to `irq_alloc_domain_generic_chips'
> :(.text+0x49ea60): undefined reference to `irq_get_domain_generic_chip'
> :(.text+0x49ea64): undefined reference to `irq_gc_ack_set_bit'
> :(.text+0x49ea6c): undefined reference to `irq_gc_mask_clr_bit'
> :(.text+0x49ea70): undefined reference to `irq_gc_mask_set_bit'
Let's take a step back, and ask the obvious question: is it reasonable
to make use if GENERIC_IRQ_CHIP in this driver?
Bear in mind that this is a platform driver (and so can be unbound), and
the IRQ domain stuff does not support tear-down. This code contains this...
static void ipu_irq_exit(struct ipu_soc *ipu)
{
int i, irq;
irq_set_chained_handler(ipu->irq_err, NULL);
irq_set_handler_data(ipu->irq_err, NULL);
irq_set_chained_handler(ipu->irq_sync, NULL);
irq_set_handler_data(ipu->irq_sync, NULL);
/* TODO: remove irq_domain_generic_chips */
for (i = 0; i < IPU_NUM_IRQS; i++) {
irq = irq_linear_revmap(ipu->domain, i);
if (irq)
irq_dispose_mapping(irq);
}
irq_domain_remove(ipu->domain);
}
which rather hints at it being more broken than just the above.
So, I think you're just papering over the symptom of a broken
implementation with your patch...
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
