Re: [PATCH 2/6] mfd: da9052: Introduce da9052-irq.c

[Mark Brown <broonie@opensource.wolfsonmicro.com>]

On Thu, Oct 04, 2012 at 07:12:48AM +0000, Arnd Bergmann wrote:
> On Thursday 04 October 2012, Fabio Estevam wrote:

> > +int da9052_enable_irq(struct da9052 *da9052, int irq)
> > +{
> > +       irq = da9052_map_irq(da9052, irq);
> > +       if (irq < 0)
> > +               return irq;
> > +
> > +       enable_irq(irq);
> > +
> > +       return 0;
> > +}
> > +EXPORT_SYMBOL_GPL(da9052_enable_irq);

> This looks correct, but I'm not sure it's actually simpler
> than letting the sub-drivers deal with calling regmap_irq_get_virq().

> Can't each driver just call regmap_irq_get_virq once at init time and
> then call the regular irq management functions?

> Maybe I just don't see the real purpose of these functions. If I'm
> contradicting what Mark said, listen to him instead.

Aside from hiding the lookup of the irqdomian a bit there's a couple of
reasons for existing devices having them:

 - With some devices like WM8994 the interrupts are optional so it's
   useful to eat errors due to the interrupts not existing.  With the
   ability to use linear domains this doesn't matter terribly much as we
   can just allocate the interrupts even if there's no way they can
   fire, it was more of an issue when irqdomain wasn't available.

 - With Arizona we've actually got a bunch of interrupt controllers the
   interrupts might be allocated to and these functions allow us to hide
   this mapping from the subdrivers.  This is pretty specialist though.

but if the interrupts are always requestable it really makes little
odds, just a matter of taste.