It's unsafe to call IRQ chip callbacks (.irq_mask/irq_unmask/irq_ack)
from chained IRQ handler directly. Because, Davinci GPIO block is used
by different SoCs, which, in turn, have different Main IRQ controllers
(Davinci - aintc, cp-intc; Keystone - arm-gic) which may introduce
diffrent set of IRQ chip callbacks. As result, call of
gpio_irq_handler() on Keysone will simply cause crash the system,
because ARM-GIC implements .irq_eoi() instead of .irq_ack().
Hence, fix it by using Kernel chained_irq_enter/chained_irq_exit APIs as
they are intended to handle exact such cases.
Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Santosh Shilimkar <santosh.shilimkar@ti.com>
Signed-off-by: Sekhar Nori <nsekhar@ti.com>
#include <linux/of_device.h>
#include <linux/platform_device.h>
#include <linux/platform_data/gpio-davinci.h>
+#include <linux/irqchip/chained_irq.h>
struct davinci_gpio_regs {
u32 dir;
mask <<= 16;
/* temporarily mask (level sensitive) parent IRQ */
- desc->irq_data.chip->irq_mask(&desc->irq_data);
- desc->irq_data.chip->irq_ack(&desc->irq_data);
+ chained_irq_enter(irq_desc_get_chip(desc), desc);
while (1) {
u32 status;
int bit;
d->chip.base + bit));
}
}
- desc->irq_data.chip->irq_unmask(&desc->irq_data);
+ chained_irq_exit(irq_desc_get_chip(desc), desc);
/* now it may re-trigger */
}