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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 4 Oct 2012 12:14:12 +0100
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Fabio Estevam <festevam@...il.com>, sameo@...ux.intel.com,
	ashish.jangam@...tcummins.com, dchen@...semi.com,
	kernel@...gutronix.de, linux-kernel@...r.kernel.org,
	Fabio Estevam <fabio.estevam@...escale.com>
Subject: Re: [PATCH 2/6] mfd: da9052: Introduce da9052-irq.c

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/