[PATCH] drm: imx: use GENERIC_IRQ_CHIP

[linux@arm.linux.org.uk (Russell King - ARM Linux)]

On Thu, Jun 12, 2014 at 04:51:26PM +0200, Arnd Bergmann wrote:
> On Thursday 12 June 2014 15:23:54 Russell King - ARM Linux wrote:
> > 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?
> 
> While I haven't looked at this driver in particular, I know that
> Thomas Gleixner has been rather upset in the past when new irqchip
> drivers got introduced that were reimplementing the generic irqchip
> rather than using it.
> 
> You can argue over whether it should be an irqchip at all or not,
> I don't know, and I simply had to assume that this part of the
> code is ok.

The question was more whether "peripheral" drivers should register their
own irqchips to split a single IRQ into multiple separate Linux IRQs.
We don't have PCI devices behaving like that... and I don't think we
should allow it as a general rule.

> This seems more like a second bug in a related part of the code
> to me. Looking at other generic irqchip users, it seems like
> the same bug exists in gpio-dwapb.c, gpio-ml-ioh.c, gpio-pch.c
> and possibly others, which are all loadable modules using a
> generic irqchip that can't be freed.

Generally, that means either (a) the subsystem being used does not
support the approach, or (b) the subsystem is being inappropriately
used.

In the case of (a), it means a discussion whether support for it
should be added.  If the answer to that is no, then we need these
drivers to become modules which can only be loaded _and_ drivers
which can never be unbound.

In the case of (b) it means that the real bug is that the driver is
making use of the subsystem (irqchip in this case) that it should not
be using.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.