| Message ID | 20190626035445.236406-1-drinkcat@chromium.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] pinctrl: mediatek: Update cur_mask in mask/mask ops | expand |
On Wed, Jun 26, 2019 at 4:54 AM Nicolas Boichat <drinkcat@chromium.org> wrote: > During suspend/resume, mtk_eint_mask may be called while > wake_mask is active. For example, this happens if a wake-source > with an active interrupt handler wakes the system: > irq/pm.c:irq_pm_check_wakeup would disable the interrupt, so > that it can be handled later on in the resume flow. > > However, this may happen before mtk_eint_do_resume is called: > in this case, wake_mask is loaded, and cur_mask is restored > from an older copy, re-enabling the interrupt, and causing > an interrupt storm (especially for level interrupts). > > Step by step, for a line that has both wake and interrupt enabled: > 1. cur_mask[irq] = 1; wake_mask[irq] = 1; EINT_EN[irq] = 1 (interrupt > enabled at hardware level) > 2. System suspends, resumes due to that line (at this stage EINT_EN > == wake_mask) > 3. irq_pm_check_wakeup is called, and disables the interrupt => > EINT_EN[irq] = 0, but we still have cur_mask[irq] = 1 > 4. mtk_eint_do_resume is called, and restores EINT_EN = cur_mask, so > it reenables EINT_EN[irq] = 1 => interrupt storm as the driver > is not yet ready to handle the interrupt. > > This patch fixes the issue in step 3, by recording all mask/unmask > changes in cur_mask. This also avoids the need to read the current > mask in eint_do_suspend, and we can remove mtk_eint_chip_read_mask > function. > > The interrupt will be re-enabled properly later on, sometimes after > mtk_eint_do_resume, when the driver is ready to handle it. > > Fixes: 58a5e1b64b ("pinctrl: mediatek: Implement wake handler and suspend resume") > Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> > Acked-by: Sean Wang <sean.wang@kernel.org> Patch applied after extending the has for Fixes: to 12 digits. Yours, Linus Walleij
diff --git a/drivers/pinctrl/mediatek/mtk-eint.c b/drivers/pinctrl/mediatek/mtk-eint.c index 737385e86beb807..7e526bcf5e0b55c 100644 --- a/drivers/pinctrl/mediatek/mtk-eint.c +++ b/drivers/pinctrl/mediatek/mtk-eint.c @@ -113,6 +113,8 @@ static void mtk_eint_mask(struct irq_data *d) void __iomem *reg = mtk_eint_get_offset(eint, d->hwirq, eint->regs->mask_set); + eint->cur_mask[d->hwirq >> 5] &= ~mask; + writel(mask, reg); } @@ -123,6 +125,8 @@ static void mtk_eint_unmask(struct irq_data *d) void __iomem *reg = mtk_eint_get_offset(eint, d->hwirq, eint->regs->mask_clr); + eint->cur_mask[d->hwirq >> 5] |= mask; + writel(mask, reg); if (eint->dual_edge[d->hwirq]) @@ -217,19 +221,6 @@ static void mtk_eint_chip_write_mask(const struct mtk_eint *eint, } } -static void mtk_eint_chip_read_mask(const struct mtk_eint *eint, - void __iomem *base, u32 *buf) -{ - int port; - void __iomem *reg; - - for (port = 0; port < eint->hw->ports; port++) { - reg = base + eint->regs->mask + (port << 2); - buf[port] = ~readl_relaxed(reg); - /* Mask is 0 when irq is enabled, and 1 when disabled. */ - } -} - static int mtk_eint_irq_request_resources(struct irq_data *d) { struct mtk_eint *eint = irq_data_get_irq_chip_data(d); @@ -384,7 +375,6 @@ static void mtk_eint_irq_handler(struct irq_desc *desc) int mtk_eint_do_suspend(struct mtk_eint *eint) { - mtk_eint_chip_read_mask(eint, eint->base, eint->cur_mask); mtk_eint_chip_write_mask(eint, eint->base, eint->wake_mask); return 0;
During suspend/resume, mtk_eint_mask may be called while wake_mask is active. For example, this happens if a wake-source with an active interrupt handler wakes the system: irq/pm.c:irq_pm_check_wakeup would disable the interrupt, so that it can be handled later on in the resume flow. However, this may happen before mtk_eint_do_resume is called: in this case, wake_mask is loaded, and cur_mask is restored from an older copy, re-enabling the interrupt, and causing an interrupt storm (especially for level interrupts). Step by step, for a line that has both wake and interrupt enabled: 1. cur_mask[irq] = 1; wake_mask[irq] = 1; EINT_EN[irq] = 1 (interrupt enabled at hardware level) 2. System suspends, resumes due to that line (at this stage EINT_EN == wake_mask) 3. irq_pm_check_wakeup is called, and disables the interrupt => EINT_EN[irq] = 0, but we still have cur_mask[irq] = 1 4. mtk_eint_do_resume is called, and restores EINT_EN = cur_mask, so it reenables EINT_EN[irq] = 1 => interrupt storm as the driver is not yet ready to handle the interrupt. This patch fixes the issue in step 3, by recording all mask/unmask changes in cur_mask. This also avoids the need to read the current mask in eint_do_suspend, and we can remove mtk_eint_chip_read_mask function. The interrupt will be re-enabled properly later on, sometimes after mtk_eint_do_resume, when the driver is ready to handle it. Fixes: 58a5e1b64b ("pinctrl: mediatek: Implement wake handler and suspend resume") Signed-off-by: Nicolas Boichat <drinkcat@chromium.org> Acked-by: Sean Wang <sean.wang@kernel.org> --- Applies on top of linux-pinctrl.git/fixes. Changes from v2: - Added Fixes tag - Reworded the commit message, added an example. Sean: I hope that's what you had in mind, I can reword further, if needed. Note that IRQCHIP_MASK_ON_SUSPEND does not work here, as it does not handle lines that are enabled as a wake source, but without interrupt enabled (e.g. cros_ec driver does that), which we do want to support. Also, Stephen Boyd suggested refactoring the genirq layer to make it aware of such IRQ controllers. I may try to look at this in the future, but don't have the cycles right now ,-( drivers/pinctrl/mediatek/mtk-eint.c | 18 ++++-------------- 1 file changed, 4 insertions(+), 14 deletions(-)