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

[haojian.zhuang@gmail.com (Haojian Zhuang)]

On Tue, Jan 26, 2010 at 6:28 AM, Mark Brown
<broonie@opensource.wolfsonmicro.com> wrote:
> 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.
>
Actually I can't find genirq reports any warning. I only find my code
reports warning message.

>> >> + * 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?
>
Em. it's OK. I'll do it.