[PATCH AUTOSEL 5.8 23/24] gpio: pca953x: Survive spurious interrupts

as it still tries to handle the error code as a real interrupt. Handle this particular case and warn on spurious interrupts. Signed-off-by: Marc Zyngier Link: https://lore.kernel.org/r/20201005140217.1390851-1-...@kernel.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin --- drivers

Re: [PATCH] gpio: pca953x: Survive spurious interrupts

> >> >> > The pca953x driver never checks the result of irq_find_mapping(), > >> >> >> > which returns 0 when no mapping is found. When a spurious interrupt > >> >> >> > is delivered (which can happen under obscure circumstances),

Re: [PATCH] gpio: pca953x: Survive spurious interrupts

ious interrupt >> >> > is delivered (which can happen under obscure circumstances), the >> >> > kernel explodes as it still tries to handle the error code as >> >> > a real interrupt. >> >> > >> >> > Handle this particular case

Re: [PATCH] gpio: pca953x: Survive spurious interrupts

terrupt > >> >> > is delivered (which can happen under obscure circumstances), the > >> >> > kernel explodes as it still tries to handle the error code as > >> >> > a real interrupt. > >> >> > > >> >> >

Re: [PATCH] gpio: pca953x: Survive spurious interrupts

gt;> > a real interrupt. >> > >> > Handle this particular case and warn on spurious interrupts. >> > >> > Signed-off-by: Marc Zyngier > > Wait, doesn't actually [1] fix the reported issue? Not at all. > Marc, can you confirm this? > &g

Re: [PATCH] gpio: pca953x: Survive spurious interrupts

r never checks the result of irq_find_mapping(), > >> > which returns 0 when no mapping is found. When a spurious interrupt > >> > is delivered (which can happen under obscure circumstances), the > >> > kernel explodes as it still tries to handle the error code as > &

Re: [PATCH] gpio: pca953x: Survive spurious interrupts

errupt > is delivered (which can happen under obscure circumstances), the > kernel explodes as it still tries to handle the error code as > a real interrupt. > > Handle this particular case and warn on spurious interrupts. > > Signed-off-by: Marc Zyngier Wait, doesn't actually

Re: [PATCH] gpio: pca953x: Survive spurious interrupts

red (which can happen under obscure circumstances), the > > kernel explodes as it still tries to handle the error code as > > a real interrupt. > > > > Handle this particular case and warn on spurious interrupts. > > > > Signed-off-by: Marc Zyngier Wait, does

Re: [PATCH] gpio: pca953x: Survive spurious interrupts

still tries to handle the error code as > a real interrupt. > > Handle this particular case and warn on spurious interrupts. > > Signed-off-by: Marc Zyngier Patch applied for fixes. Yours, Linus Walleij

[PATCH] gpio: pca953x: Survive spurious interrupts

this particular case and warn on spurious interrupts. Signed-off-by: Marc Zyngier --- drivers/gpio/gpio-pca953x.c | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/gpio/gpio-pca953x.c b/drivers/gpio/gpio-pca953x.c index fb61f2fc6ed7..c2d6121c48c9 100644

[PATCH 4.4 38/46] MIPS: SNI: Fix spurious interrupts

0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") the function to do after service update got lost, which caused spurious interrupts. Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin

[PATCH 4.14 81/94] MIPS: SNI: Fix spurious interrupts

0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") the function to do after service update got lost, which caused spurious interrupts. Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin

[PATCH 4.19 34/49] MIPS: SNI: Fix spurious interrupts

0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") the function to do after service update got lost, which caused spurious interrupts. Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin

[PATCH 5.4 44/72] MIPS: SNI: Fix spurious interrupts

0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") the function to do after service update got lost, which caused spurious interrupts. Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin

[PATCH 5.8 066/118] MIPS: SNI: Fix spurious interrupts

0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") the function to do after service update got lost, which caused spurious interrupts. Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin

[PATCH 4.9 61/70] MIPS: SNI: Fix spurious interrupts

0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") the function to do after service update got lost, which caused spurious interrupts. Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") Signed-off-by: Thomas Bogendoerfer Signed-off-by: Sasha Levin

Re: [PATCH] MIPS: SNI: Fix spurious interrupts

0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") the > function to do after service update got lost, which caused spurious > interrupts. > > Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") > Signed-off-by: Thomas Bogendoerfer > -

[PATCH] MIPS: SNI: Fix spurious interrupts

o do after service update got lost, which caused spurious interrupts. Fixes: 0b888c7f3a03 ("MIPS: SNI: Convert to new irq_chip functions") Signed-off-by: Thomas Bogendoerfer --- arch/mips/sni/a20r.c | 9 +++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/arch/mips/sni/a2

Re: [PATCH v2] mmc: sdhci-iproc: fix spurious interrupts on Multiblock reads with bcm2711

On Fri, 4 Oct 2019 at 15:45, Nicolas Saenz Julienne wrote: > > The Raspberry Pi 4 SDHCI hardware seems to automatically issue CMD12 > after multiblock reads even when ACMD12 is disabled. This triggers > spurious interrupts after the data transfer is done with the following > mess

[PATCH v2] mmc: sdhci-iproc: fix spurious interrupts on Multiblock reads with bcm2711

The Raspberry Pi 4 SDHCI hardware seems to automatically issue CMD12 after multiblock reads even when ACMD12 is disabled. This triggers spurious interrupts after the data transfer is done with the following message: mmc1: Got data interrupt 0x0002 even though no data operation

Re: [PATCH] mmc: sdhci-iproc: fix spurious interrupts on Multiblock reads with bcm2711

Am 04.10.19 um 14:59 schrieb Nicolas Saenz Julienne: > On Fri, 2019-10-04 at 14:52 +0200, Nicolas Saenz Julienne wrote: >> The Raspberry Pi 4 SDHCI hardware seems to automatically issue CMD12 >> after multiblock reads even when ACMD12 is disabled. This triggers >> spur

Re: [PATCH] mmc: sdhci-iproc: fix spurious interrupts on Multiblock reads with bcm2711

On Fri, 2019-10-04 at 14:52 +0200, Nicolas Saenz Julienne wrote: > The Raspberry Pi 4 SDHCI hardware seems to automatically issue CMD12 > after multiblock reads even when ACMD12 is disabled. This triggers > spurious interrupts after the data transfer is done with the following

[PATCH] mmc: sdhci-iproc: fix spurious interrupts on Multiblock reads with bcm2711

The Raspberry Pi 4 SDHCI hardware seems to automatically issue CMD12 after multiblock reads even when ACMD12 is disabled. This triggers spurious interrupts after the data transfer is done with the following message: mmc1: Got data interrupt 0x0002 even though no data operation

[PATCH 4.19 011/271] wil6210: fix spurious interrupts in 3-msi

[ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ] Interrupt is set in ICM (ICR & ~IMV) rising trigger. As the driver masks the IRQ after clearing it, there can be a race where an additional spurious interrupt is triggered when the driver unmask the IRQ. This can happen in case HW

[PATCH 5.1 018/371] wil6210: fix spurious interrupts in 3-msi

[ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ] Interrupt is set in ICM (ICR & ~IMV) rising trigger. As the driver masks the IRQ after clearing it, there can be a race where an additional spurious interrupt is triggered when the driver unmask the IRQ. This can happen in case HW

[PATCH 5.2 013/413] wil6210: fix spurious interrupts in 3-msi

[ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ] Interrupt is set in ICM (ICR & ~IMV) rising trigger. As the driver masks the IRQ after clearing it, there can be a race where an additional spurious interrupt is triggered when the driver unmask the IRQ. This can happen in case HW

[PATCH AUTOSEL 4.19 007/158] wil6210: fix spurious interrupts in 3-msi

From: Maya Erez [ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ] Interrupt is set in ICM (ICR & ~IMV) rising trigger. As the driver masks the IRQ after clearing it, there can be a race where an additional spurious interrupt is triggered when the driver unmask the IRQ. This can

[PATCH AUTOSEL 5.1 014/219] wil6210: fix spurious interrupts in 3-msi

From: Maya Erez [ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ] Interrupt is set in ICM (ICR & ~IMV) rising trigger. As the driver masks the IRQ after clearing it, there can be a race where an additional spurious interrupt is triggered when the driver unmask the IRQ. This can

[PATCH AUTOSEL 5.2 014/249] wil6210: fix spurious interrupts in 3-msi

From: Maya Erez [ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ] Interrupt is set in ICM (ICR & ~IMV) rising trigger. As the driver masks the IRQ after clearing it, there can be a race where an additional spurious interrupt is triggered when the driver unmask the IRQ. This can

[PATCH AUTOSEL 5.1 014/219] wil6210: fix spurious interrupts in 3-msi

From: Maya Erez [ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ] Interrupt is set in ICM (ICR & ~IMV) rising trigger. As the driver masks the IRQ after clearing it, there can be a race where an additional spurious interrupt is triggered when the driver unmask the IRQ. This can

[PATCH AUTOSEL 4.19 007/158] wil6210: fix spurious interrupts in 3-msi

From: Maya Erez [ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ] Interrupt is set in ICM (ICR & ~IMV) rising trigger. As the driver masks the IRQ after clearing it, there can be a race where an additional spurious interrupt is triggered when the driver unmask the IRQ. This can

[PATCH AUTOSEL 5.2 014/249] wil6210: fix spurious interrupts in 3-msi

From: Maya Erez [ Upstream commit e10b0eddd5235aa5aef4e40b970e34e735611a80 ] Interrupt is set in ICM (ICR & ~IMV) rising trigger. As the driver masks the IRQ after clearing it, there can be a race where an additional spurious interrupt is triggered when the driver unmask the IRQ. This can

[PATCH 3.16 175/202] mmc: tmio_mmc_core: don't claim spurious interrupts

3.16.66-rc1 review patch. If anyone has any objections, please let me know. -- From: Sergei Shtylyov commit 5c27ff5db1491a947264d6d4e4cbe43ae6535bae upstream. I have encountered an interrupt storm during the eMMC chip probing (and the chip finally didn't get detected). It

[PATCH 3.18 06/50] mmc: tmio_mmc_core: dont claim spurious interrupts

3.18-stable review patch. If anyone has any objections, please let me know. -- From: Sergei Shtylyov commit 5c27ff5db1491a947264d6d4e4cbe43ae6535bae upstream. I have encountered an interrupt storm during the eMMC chip probing (and the chip finally didn't get detected). It

[PATCH 4.4 010/131] mmc: tmio_mmc_core: dont claim spurious interrupts

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Sergei Shtylyov commit 5c27ff5db1491a947264d6d4e4cbe43ae6535bae upstream. I have encountered an interrupt storm during the eMMC chip probing (and the chip finally didn't get detected). It

[PATCH 4.9 29/31] mmc: tmio_mmc_core: dont claim spurious interrupts

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Sergei Shtylyov commit 5c27ff5db1491a947264d6d4e4cbe43ae6535bae upstream. I have encountered an interrupt storm during the eMMC chip probing (and the chip finally didn't get detected). It

[PATCH 4.14 46/52] mmc: tmio_mmc_core: dont claim spurious interrupts

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Sergei Shtylyov commit 5c27ff5db1491a947264d6d4e4cbe43ae6535bae upstream. I have encountered an interrupt storm during the eMMC chip probing (and the chip finally didn't get detected). It

[PATCH 4.20 69/88] mmc: tmio_mmc_core: dont claim spurious interrupts

4.20-stable review patch. If anyone has any objections, please let me know. -- From: Sergei Shtylyov commit 5c27ff5db1491a947264d6d4e4cbe43ae6535bae upstream. I have encountered an interrupt storm during the eMMC chip probing (and the chip finally didn't get detected). It

[PATCH 4.19 66/78] mmc: tmio_mmc_core: dont claim spurious interrupts

4.19-stable review patch. If anyone has any objections, please let me know. -- From: Sergei Shtylyov commit 5c27ff5db1491a947264d6d4e4cbe43ae6535bae upstream. I have encountered an interrupt storm during the eMMC chip probing (and the chip finally didn't get detected). It

[PATCH 4.4 081/124] memory: tegra: Do not handle spurious interrupts

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Dmitry Osipenko [ Upstream commit bf3fbdfbec947cdd04b2f2c4bce11534c8786eee ] The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the mask to the interrupt status and don't

[PATCH 4.4 081/124] memory: tegra: Do not handle spurious interrupts

4.4-stable review patch. If anyone has any objections, please let me know. -- From: Dmitry Osipenko [ Upstream commit bf3fbdfbec947cdd04b2f2c4bce11534c8786eee ] The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the mask to the interrupt status and don't

[PATCH 4.17 249/336] memory: tegra: Do not handle spurious interrupts

4.17-stable review patch. If anyone has any objections, please let me know. -- From: Dmitry Osipenko [ Upstream commit bf3fbdfbec947cdd04b2f2c4bce11534c8786eee ] The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the mask to the interrupt status and don't

[PATCH 4.17 249/336] memory: tegra: Do not handle spurious interrupts

4.17-stable review patch. If anyone has any objections, please let me know. -- From: Dmitry Osipenko [ Upstream commit bf3fbdfbec947cdd04b2f2c4bce11534c8786eee ] The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the mask to the interrupt status and don't

[PATCH 4.9 117/144] memory: tegra: Do not handle spurious interrupts

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dmitry Osipenko [ Upstream commit bf3fbdfbec947cdd04b2f2c4bce11534c8786eee ] The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the mask to the interrupt status and don't

[PATCH 4.9 117/144] memory: tegra: Do not handle spurious interrupts

4.9-stable review patch. If anyone has any objections, please let me know. -- From: Dmitry Osipenko [ Upstream commit bf3fbdfbec947cdd04b2f2c4bce11534c8786eee ] The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the mask to the interrupt status and don't

[PATCH 4.14 183/246] memory: tegra: Do not handle spurious interrupts

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Dmitry Osipenko [ Upstream commit bf3fbdfbec947cdd04b2f2c4bce11534c8786eee ] The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the mask to the interrupt status and don't

[PATCH 4.14 183/246] memory: tegra: Do not handle spurious interrupts

4.14-stable review patch. If anyone has any objections, please let me know. -- From: Dmitry Osipenko [ Upstream commit bf3fbdfbec947cdd04b2f2c4bce11534c8786eee ] The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the mask to the interrupt status and don't

[PATCH 4.16 48/52] irqchip/qcom: Fix check for spurious interrupts

if any interrupts have been asserted on each register before checking for spurious interrupts. Checking each register seperately leads to false positive warnings. [ tglx: Massaged changelog ] Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver") Signed-off-by: Agustin V

[PATCH 4.16 48/52] irqchip/qcom: Fix check for spurious interrupts

on each register before checking for spurious interrupts. Checking each register seperately leads to false positive warnings. [ tglx: Massaged changelog ] Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver") Signed-off-by: Agustin Vega-Frias Signed-off-by: Thomas Gleixner

[PATCH 4.14 42/43] irqchip/qcom: Fix check for spurious interrupts

if any interrupts have been asserted on each register before checking for spurious interrupts. Checking each register seperately leads to false positive warnings. [ tglx: Massaged changelog ] Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver") Signed-off-by: Agustin V

[PATCH 4.14 42/43] irqchip/qcom: Fix check for spurious interrupts

on each register before checking for spurious interrupts. Checking each register seperately leads to false positive warnings. [ tglx: Massaged changelog ] Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver") Signed-off-by: Agustin Vega-Frias Signed-off-by: Thomas Gleixner

[tip:irq/urgent] irqchip/qcom: Fix check for spurious interrupts

mitDate: Wed, 2 May 2018 15:56:10 +0200 irqchip/qcom: Fix check for spurious interrupts When the interrupts for a combiner span multiple registers it must be checked if any interrupts have been asserted on each register before checking for spurious interrupts. Checking each register seperately le

[tip:irq/urgent] irqchip/qcom: Fix check for spurious interrupts

check for spurious interrupts When the interrupts for a combiner span multiple registers it must be checked if any interrupts have been asserted on each register before checking for spurious interrupts. Checking each register seperately leads to false positive warnings. [ tglx: Massaged

[PATCH V1] irqchip/qcom: Fix check for spurious interrupts

When the interrupts for a combiner span multiple registers we need to check if any interrupts have been asserted on each register before checking for spurious interrupts. Signed-off-by: Agustin Vega-Frias <agust...@codeaurora.org> --- drivers/irqchip/qcom-irq-combiner.c | 4 ++-- 1 file c

[PATCH V1] irqchip/qcom: Fix check for spurious interrupts

When the interrupts for a combiner span multiple registers we need to check if any interrupts have been asserted on each register before checking for spurious interrupts. Signed-off-by: Agustin Vega-Frias --- drivers/irqchip/qcom-irq-combiner.c | 4 ++-- 1 file changed, 2 insertions(+), 2

Re: [PATCH v4 05/15] memory: tegra: Do not handle spurious interrupts

On Mon, Apr 09, 2018 at 10:28:27PM +0300, Dmitry Osipenko wrote: > The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the > mask to the interrupt status and don't handle interrupts that MC driver > haven't asked for. Kernel would disable spurious MC IRQ and report the > error.

Re: [PATCH v4 05/15] memory: tegra: Do not handle spurious interrupts

On Mon, Apr 09, 2018 at 10:28:27PM +0300, Dmitry Osipenko wrote: > The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the > mask to the interrupt status and don't handle interrupts that MC driver > haven't asked for. Kernel would disable spurious MC IRQ and report the > error.

[PATCH v4 05/15] memory: tegra: Do not handle spurious interrupts

The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the mask to the interrupt status and don't handle interrupts that MC driver haven't asked for. Kernel would disable spurious MC IRQ and report the error. This would happen only in a case of a very severe bug. Signed-off-by:

[PATCH v4 05/15] memory: tegra: Do not handle spurious interrupts

The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the mask to the interrupt status and don't handle interrupts that MC driver haven't asked for. Kernel would disable spurious MC IRQ and report the error. This would happen only in a case of a very severe bug. Signed-off-by:

[PATCH v1 4/5] media: staging: tegra-vde: Do not handle spurious interrupts

Do not handle interrupts if we haven't asked for them, potentially that could happen if HW wasn't programmed properly. Signed-off-by: Dmitry Osipenko --- drivers/staging/media/tegra-vde/tegra-vde.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH v1 4/5] media: staging: tegra-vde: Do not handle spurious interrupts

Do not handle interrupts if we haven't asked for them, potentially that could happen if HW wasn't programmed properly. Signed-off-by: Dmitry Osipenko --- drivers/staging/media/tegra-vde/tegra-vde.c | 3 +++ 1 file changed, 3 insertions(+) diff --git

[PATCH v3 05/15] memory: tegra: Do not handle spurious interrupts

The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the mask to the interrupt status and don't handle interrupts that MC driver haven't asked for. Kernel would disable spurious MC IRQ and report the error. This would happen only in a case of a very severe bug. Signed-off-by:

[PATCH v3 05/15] memory: tegra: Do not handle spurious interrupts

The ISR reads interrupts-enable mask, but doesn't utilize it. Apply the mask to the interrupt status and don't handle interrupts that MC driver haven't asked for. Kernel would disable spurious MC IRQ and report the error. This would happen only in a case of a very severe bug. Signed-off-by:

[PATCH 4.9 25/48] clockevents/drivers/cs5535: Improve resilience to spurious interrupts

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Kozub <z...@linux.fjfi.cvut.cz> commit eb39a7c0355393c5a8d930f342ad7a6231b552c4 upstream. The interrupt handler mfgpt_tick() is not robust versus spurious interrupts which happen

[PATCH 4.9 25/48] clockevents/drivers/cs5535: Improve resilience to spurious interrupts

4.9-stable review patch. If anyone has any objections, please let me know. -- From: David Kozub commit eb39a7c0355393c5a8d930f342ad7a6231b552c4 upstream. The interrupt handler mfgpt_tick() is not robust versus spurious interrupts which happen before the clock event device

[PATCH 4.13 56/85] clockevents/drivers/cs5535: Improve resilience to spurious interrupts

4.13-stable review patch. If anyone has any objections, please let me know. -- From: David Kozub <z...@linux.fjfi.cvut.cz> commit eb39a7c0355393c5a8d930f342ad7a6231b552c4 upstream. The interrupt handler mfgpt_tick() is not robust versus spurious interrupts which happen

[PATCH 4.13 56/85] clockevents/drivers/cs5535: Improve resilience to spurious interrupts

4.13-stable review patch. If anyone has any objections, please let me know. -- From: David Kozub commit eb39a7c0355393c5a8d930f342ad7a6231b552c4 upstream. The interrupt handler mfgpt_tick() is not robust versus spurious interrupts which happen before the clock event device

[PATCH 4.4 19/27] clockevents/drivers/cs5535: Improve resilience to spurious interrupts

4.4-stable review patch. If anyone has any objections, please let me know. -- From: David Kozub <z...@linux.fjfi.cvut.cz> commit eb39a7c0355393c5a8d930f342ad7a6231b552c4 upstream. The interrupt handler mfgpt_tick() is not robust versus spurious interrupts which happen

[PATCH 4.4 19/27] clockevents/drivers/cs5535: Improve resilience to spurious interrupts

4.4-stable review patch. If anyone has any objections, please let me know. -- From: David Kozub commit eb39a7c0355393c5a8d930f342ad7a6231b552c4 upstream. The interrupt handler mfgpt_tick() is not robust versus spurious interrupts which happen before the clock event device

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On Fri, 20 Oct 2017, Daniel Lezcano wrote: On 20/10/2017 09:49, David Kozub wrote: On Fri, 20 Oct 2017, Daniel Lezcano wrote: On 20/10/2017 00:25, Thomas Gleixner wrote: On Fri, 20 Oct 2017, Daniel Lezcano wrote: On 19/10/2017 22:57, David Kozub wrote: This solves a BUG on ALIX 2c3 where

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On Fri, 20 Oct 2017, Daniel Lezcano wrote: On 20/10/2017 09:49, David Kozub wrote: On Fri, 20 Oct 2017, Daniel Lezcano wrote: On 20/10/2017 00:25, Thomas Gleixner wrote: On Fri, 20 Oct 2017, Daniel Lezcano wrote: On 19/10/2017 22:57, David Kozub wrote: This solves a BUG on ALIX 2c3 where

[tip:timers/urgent] clockevents/drivers/cs5535: Improve resilience to spurious interrupts

ate: Fri, 20 Oct 2017 13:41:52 +0200 clockevents/drivers/cs5535: Improve resilience to spurious interrupts The interrupt handler mfgpt_tick() is not robust versus spurious interrupts which happen before the clock event device is registered and fully initialized. The reason is that the safe g

[tip:timers/urgent] clockevents/drivers/cs5535: Improve resilience to spurious interrupts

/cs5535: Improve resilience to spurious interrupts The interrupt handler mfgpt_tick() is not robust versus spurious interrupts which happen before the clock event device is registered and fully initialized. The reason is that the safe guard against spurious interrupts solely checks

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On 20/10/2017 11:40, Thomas Gleixner wrote: > On Fri, 20 Oct 2017, Daniel Lezcano wrote: >> On 20/10/2017 09:49, David Kozub wrote: >> >> And it ends up to the bad commit (assuming there are no compilation >> broken patches in the process). > > I don't think it's worth the trouble for this

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On 20/10/2017 11:40, Thomas Gleixner wrote: > On Fri, 20 Oct 2017, Daniel Lezcano wrote: >> On 20/10/2017 09:49, David Kozub wrote: >> >> And it ends up to the bad commit (assuming there are no compilation >> broken patches in the process). > > I don't think it's worth the trouble for this

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On Fri, 20 Oct 2017, Daniel Lezcano wrote: > On 20/10/2017 09:49, David Kozub wrote: > > And it ends up to the bad commit (assuming there are no compilation > broken patches in the process). I don't think it's worth the trouble for this particular issue. We already know that the commit which

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On Fri, 20 Oct 2017, Daniel Lezcano wrote: > On 20/10/2017 09:49, David Kozub wrote: > > And it ends up to the bad commit (assuming there are no compilation > broken patches in the process). I don't think it's worth the trouble for this particular issue. We already know that the commit which

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On 20/10/2017 09:49, David Kozub wrote: > On Fri, 20 Oct 2017, Daniel Lezcano wrote: > >> On 20/10/2017 00:25, Thomas Gleixner wrote: >>> On Fri, 20 Oct 2017, Daniel Lezcano wrote: >>> On 19/10/2017 22:57, David Kozub wrote: > This solves a BUG on ALIX 2c3 where mfgpt_tick is called

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On 20/10/2017 09:49, David Kozub wrote: > On Fri, 20 Oct 2017, Daniel Lezcano wrote: > >> On 20/10/2017 00:25, Thomas Gleixner wrote: >>> On Fri, 20 Oct 2017, Daniel Lezcano wrote: >>> On 19/10/2017 22:57, David Kozub wrote: > This solves a BUG on ALIX 2c3 where mfgpt_tick is called

[PATCH v2] clockevents/drivers/cs5535: improve resilience to spurious interrupts

The interrupt handler mfgpt_tick() is not robust versus spurious interrupts which happen before the clock event device is registered and fully initialized. The reason is that the safe guard against spurious interrupts solely checks for the clockevents shutdown state, but lacks a check

[PATCH v2] clockevents/drivers/cs5535: improve resilience to spurious interrupts

The interrupt handler mfgpt_tick() is not robust versus spurious interrupts which happen before the clock event device is registered and fully initialized. The reason is that the safe guard against spurious interrupts solely checks for the clockevents shutdown state, but lacks a check

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On Fri, 20 Oct 2017, David Kozub wrote: > > Now that I'm neither the author of the code nor the author of the commit > message it doesn't seem right that I should be submitting this. Don't worry. Just resubmit it for exercise so Daniel or I can pick it up for merging. You did the hard work of

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On Fri, 20 Oct 2017, David Kozub wrote: > > Now that I'm neither the author of the code nor the author of the commit > message it doesn't seem right that I should be submitting this. Don't worry. Just resubmit it for exercise so Daniel or I can pick it up for merging. You did the hard work of

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On Fri, 20 Oct 2017, Daniel Lezcano wrote: On 20/10/2017 00:25, Thomas Gleixner wrote: On Fri, 20 Oct 2017, Daniel Lezcano wrote: On 19/10/2017 22:57, David Kozub wrote: This solves a BUG on ALIX 2c3 where mfgpt_tick is called before clockevents_config_and_register returns. This caused

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On Fri, 20 Oct 2017, Daniel Lezcano wrote: On 20/10/2017 00:25, Thomas Gleixner wrote: On Fri, 20 Oct 2017, Daniel Lezcano wrote: On 19/10/2017 22:57, David Kozub wrote: This solves a BUG on ALIX 2c3 where mfgpt_tick is called before clockevents_config_and_register returns. This caused

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

explanation. Let me give you an example: The interrupt handler mfgpt_tick() is not robust versus spurious interrupts which happen before the clock event device is registered and fully initialized. The reason is that the safe guard against spurious interrupts solely checks for the clockevents

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

explanation. Let me give you an example: The interrupt handler mfgpt_tick() is not robust versus spurious interrupts which happen before the clock event device is registered and fully initialized. The reason is that the safe guard against spurious interrupts solely checks for the clockevents

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On 20/10/2017 00:25, Thomas Gleixner wrote: > On Fri, 20 Oct 2017, Daniel Lezcano wrote: > >> On 19/10/2017 22:57, David Kozub wrote: >>> This solves a BUG on ALIX 2c3 where mfgpt_tick is called before >>> clockevents_config_and_register returns. This caused mfgpt_tick to call a >>> null function

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On 20/10/2017 00:25, Thomas Gleixner wrote: > On Fri, 20 Oct 2017, Daniel Lezcano wrote: > >> On 19/10/2017 22:57, David Kozub wrote: >>> This solves a BUG on ALIX 2c3 where mfgpt_tick is called before >>> clockevents_config_and_register returns. This caused mfgpt_tick to call a >>> null function

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On Fri, 20 Oct 2017, Daniel Lezcano wrote: > On 19/10/2017 22:57, David Kozub wrote: > > This solves a BUG on ALIX 2c3 where mfgpt_tick is called before > > clockevents_config_and_register returns. This caused mfgpt_tick to call a > > null function pointer. > > > > Thanks to Daniel Lezcano and

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On Fri, 20 Oct 2017, Daniel Lezcano wrote: > On 19/10/2017 22:57, David Kozub wrote: > > This solves a BUG on ALIX 2c3 where mfgpt_tick is called before > > clockevents_config_and_register returns. This caused mfgpt_tick to call a > > null function pointer. > > > > Thanks to Daniel Lezcano and

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

ive you an example: The interrupt handler mfgpt_tick() is not robust versus spurious interrupts which happen before the clock event device is registered and fully initialized. The reason is that the safe guard against spurious interrupts solely checks for the clockevents shutdown state,

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

ive you an example: The interrupt handler mfgpt_tick() is not robust versus spurious interrupts which happen before the clock event device is registered and fully initialized. The reason is that the safe guard against spurious interrupts solely checks for the clockevents shutdown state,

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On 19/10/2017 22:57, David Kozub wrote: > This solves a BUG on ALIX 2c3 where mfgpt_tick is called before > clockevents_config_and_register returns. This caused mfgpt_tick to call a > null function pointer. > > Thanks to Daniel Lezcano and Thomas Gleixner for helping me analyze this > and

Re: [PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

On 19/10/2017 22:57, David Kozub wrote: > This solves a BUG on ALIX 2c3 where mfgpt_tick is called before > clockevents_config_and_register returns. This caused mfgpt_tick to call a > null function pointer. > > Thanks to Daniel Lezcano and Thomas Gleixner for helping me analyze this > and

[PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

This solves a BUG on ALIX 2c3 where mfgpt_tick is called before clockevents_config_and_register returns. This caused mfgpt_tick to call a null function pointer. Thanks to Daniel Lezcano and Thomas Gleixner for helping me analyze this and suggesting a solution. Suggested-by: Thomas Gleixner

[PATCH] clockevents/drivers/cs5535: improve resilience to spurious interrupts

This solves a BUG on ALIX 2c3 where mfgpt_tick is called before clockevents_config_and_register returns. This caused mfgpt_tick to call a null function pointer. Thanks to Daniel Lezcano and Thomas Gleixner for helping me analyze this and suggesting a solution. Suggested-by: Thomas Gleixner

Re: [PATCH net-next 07/12] net: bcmgenet: clear status to reduce spurious interrupts

old status from causing spurious interrupts when the > interrupt is unmasked at a later time. > > Signed-off-by: Doug Berger <open...@gmail.com> Reviewed-by: Florian Fainelli <f.faine...@gmail.com> -- Florian

Re: [PATCH net-next 07/12] net: bcmgenet: clear status to reduce spurious interrupts

old status from causing spurious interrupts when the > interrupt is unmasked at a later time. > > Signed-off-by: Doug Berger Reviewed-by: Florian Fainelli -- Florian

[PATCH net-next 07/12] net: bcmgenet: clear status to reduce spurious interrupts

Since the DMA interrupt status is latched and the DMA servicing can be polled, it is a good idea to clear the latched status of a DMA interrupt before performing the service that would be invoked by the interrupt. This prevents old status from causing spurious interrupts when the interrupt

  1   2   3   >