[PATCH 2/4] mfd: update irq handler in max8925

[Mark Brown]

On Mon, Jan 25, 2010 at 10:12:39PM -0500, Haojian Zhuang wrote:
> On Mon, Jan 25, 2010 at 6:59 AM, Mark Brown
> > On Mon, Jan 25, 2010 at 06:08:19AM -0500, Haojian Zhuang wrote:

> >> +             else if (value & irq_data->offs) {
> >> +                     dev_err(chip->dev, "Noboday cares IRQ #%d. Mask it\n",
> >> +                             chip->irq_base + i);
> >> +                     max8925_set_bits(i2c, irq_data->mask_reg,
> >> +                                     irq_data->offs, irq_data->offs);

> > genirq ought to be handling this for you?

> No, genirq doesn't know this. I let the thread_fn to take this job.

This suggests that something is wrong somewhere else - genirq will
normally warn if an interrupt is reported without being handled which
looks like what this code is trying to achieve.  Looking at the patch
I expect you should just be able to drop the test you're doing
immediately before the quoted code to see if the interrupt is enabled
and call handle_nested_irq() unconditionally, genirq should generate a
warning and mask the IRQ if it's not handled which is what your code
here is doing.

> >> + * clear_irq: operation on clearing status of nIRQ pin in platform
> >> + * clear_tsc_irq: operation on clearing status of nTIRQ pin in platform
> >> + */

> > Shouldn't these also be handled by genirq as functions of the interrupt
> > controller that the chip is chained from?

> Because PMIC IRQ is connected to the special pin of CPU. CPU needs to
> clear pin status in external. genirq shouldn't take care on it. I have
> to use this ugly way to clear pin status.

I would expect this to be handled by the special pin on the CPU being an
irq_chip, or by having the existing interrupt controller handle this pin
properly.  The need to ack is going to be there for anything that ends
up hanging off this special IRQ, isn't it?