[PATCH v2] irqchip/bcm2836: Prevent spurious interrupts

[PATCH v2] irqchip/bcm2836: Prevent spurious interrupts

[Eric Anholt]

From: Phil Elwell <phil@raspberrypi.org>

The old arch-specific IRQ macros included a dsb to ensure the
write to clear the mailbox interrupt completed before returning
from the interrupt. The BCM2836 irqchip driver needs the same
precaution to avoid spurious interrupts.

Signed-off-by: Phil Elwell <phil@raspberrypi.org>
Signed-off-by: Eric Anholt <eric@anholt.net>
---
 drivers/irqchip/irq-bcm2836.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
index d96b2c947e74..93e3f7660c42 100644
--- a/drivers/irqchip/irq-bcm2836.c
+++ b/drivers/irqchip/irq-bcm2836.c
@@ -175,6 +175,7 @@ __exception_irq_entry bcm2836_arm_irqchip_handle_irq(struct pt_regs *regs)
 		u32 ipi = ffs(mbox_val) - 1;
 
 		writel(1 << ipi, mailbox0);
+		dsb(sy);
 		handle_IPI(ipi, regs);
 #endif
 	} else if (stat) {
-- 
2.9.3

[PATCH v2] irqchip/bcm2836: Prevent spurious interrupts

[Thomas Gleixner]

On Thu, 27 Oct 2016, Eric Anholt wrote:

> From: Phil Elwell <phil@raspberrypi.org>
> 
> The old arch-specific IRQ macros included a dsb to ensure the
> write to clear the mailbox interrupt completed before returning
> from the interrupt. The BCM2836 irqchip driver needs the same
> precaution to avoid spurious interrupts.

This is missing a fixes tag. I have no idea when that problem was
introduced, so I have no way to decide whether this needs to be tagged
stable or not.

Thanks,

	tglx

> 
> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
> Signed-off-by: Eric Anholt <eric@anholt.net>
> ---
>  drivers/irqchip/irq-bcm2836.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/irqchip/irq-bcm2836.c b/drivers/irqchip/irq-bcm2836.c
> index d96b2c947e74..93e3f7660c42 100644
> --- a/drivers/irqchip/irq-bcm2836.c
> +++ b/drivers/irqchip/irq-bcm2836.c
> @@ -175,6 +175,7 @@ __exception_irq_entry bcm2836_arm_irqchip_handle_irq(struct pt_regs *regs)
>  		u32 ipi = ffs(mbox_val) - 1;
>  
>  		writel(1 << ipi, mailbox0);
> +		dsb(sy);
>  		handle_IPI(ipi, regs);
>  #endif
>  	} else if (stat) {
> -- 
> 2.9.3
> 
> 

[PATCH v2] irqchip/bcm2836: Prevent spurious interrupts

[Eric Anholt]

Thomas Gleixner <tglx@linutronix.de> writes:

> On Thu, 27 Oct 2016, Eric Anholt wrote:
>
>> From: Phil Elwell <phil@raspberrypi.org>
>> 
>> The old arch-specific IRQ macros included a dsb to ensure the
>> write to clear the mailbox interrupt completed before returning
>> from the interrupt. The BCM2836 irqchip driver needs the same
>> precaution to avoid spurious interrupts.
>
> This is missing a fixes tag. I have no idea when that problem was
> introduced, so I have no way to decide whether this needs to be tagged
> stable or not.

This code has been there since introduction of the driver, so:

Fixes: 1a15aaa998dc ("irqchip: Add bcm2836 interrupt controller for Raspberry Pi 2")

[PATCH v2] irqchip/bcm2836: Prevent spurious interrupts

[Thomas Gleixner]

On Fri, 28 Oct 2016, Eric Anholt wrote:

> Thomas Gleixner <tglx@linutronix.de> writes:
> 
> > On Thu, 27 Oct 2016, Eric Anholt wrote:
> >
> >> From: Phil Elwell <phil@raspberrypi.org>
> >> 
> >> The old arch-specific IRQ macros included a dsb to ensure the

Which old arch-specific macros?

> >> write to clear the mailbox interrupt completed before returning
> >> from the interrupt.

That's not what the patch does. It makes sure that the interrupt it cleared
_before_ the IPI handler is called.

> >> The BCM2836 irqchip driver needs the same precaution to avoid
> >> spurious interrupts.

Please describe issues proper. Something like this:

  The interrupt demultiplexer code clears a pending mailbox interrupt by
  writing the pending bit back to the hardware, but it does not ensure that
  the write is completed before proceeding. This causes the machine to
  catch fire and scares my cat. <<-- Replace by a proper description.

  The write() macro which was used, when the driver was developed,
  contained the necessary data sycnhronization barrier, but it was replaced
  by writel() when the driver got merged without adding the explicit
  barrier after the write.

  Add and document the barrier.

Can you spot the difference?

>  		writel(1 << ipi, mailbox0);

		/* Barriers need to be documented with a comment */

> +		dsb(sy);
> 		handle_IPI(ipi, regs);

> > This is missing a fixes tag. I have no idea when that problem was
> > introduced, so I have no way to decide whether this needs to be tagged
> > stable or not.
> 
> This code has been there since introduction of the driver, so:
> 
> Fixes: 1a15aaa998dc ("irqchip: Add bcm2836 interrupt controller for Raspberry Pi 2")

So it want's a stable tag, right?
 
Thanks,

	tglx

[PATCH v2] irqchip/bcm2836: Prevent spurious interrupts

[Eric Anholt]

Thomas Gleixner <tglx@linutronix.de> writes:

> On Fri, 28 Oct 2016, Eric Anholt wrote:
>
>> Thomas Gleixner <tglx@linutronix.de> writes:
>> > This is missing a fixes tag. I have no idea when that problem was
>> > introduced, so I have no way to decide whether this needs to be tagged
>> > stable or not.
>> 
>> This code has been there since introduction of the driver, so:
>> 
>> Fixes: 1a15aaa998dc ("irqchip: Add bcm2836 interrupt controller for Raspberry Pi 2")
>
> So it want's a stable tag, right?

I'm not the author here, and I was just trying to provide an assist with
upstreaming, so I'm not going to get too involved.  I'd say this is an
edge case for being a stable tree candidate (it's produces a scary dmesg
warning but no other functional problems that I know of), and I didn't
add a fixes tag myself because of that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161031/9eb0eb34/attachment.sig>

[PATCH v2] irqchip/bcm2836: Prevent spurious interrupts

[Thomas Gleixner]

On Mon, 31 Oct 2016, Eric Anholt wrote:
> Thomas Gleixner <tglx@linutronix.de> writes:
> 
> > On Fri, 28 Oct 2016, Eric Anholt wrote:
> >
> >> Thomas Gleixner <tglx@linutronix.de> writes:
> >> > This is missing a fixes tag. I have no idea when that problem was
> >> > introduced, so I have no way to decide whether this needs to be tagged
> >> > stable or not.
> >> 
> >> This code has been there since introduction of the driver, so:
> >> 
> >> Fixes: 1a15aaa998dc ("irqchip: Add bcm2836 interrupt controller for Raspberry Pi 2")
> >
> > So it want's a stable tag, right?
> 
> I'm not the author here, and I was just trying to provide an assist with
> upstreaming, so I'm not going to get too involved.  I'd say this is an
> edge case for being a stable tree candidate (it's produces a scary dmesg
> warning but no other functional problems that I know of), and I didn't
> add a fixes tag myself because of that.

A fixes tag is not the same as a stable tag, I really want to see Fixes
tags on patches which are bug fixes as it makes it simple to see the
context in which a bug was introduced.

vs. the stable tag: scary warnings tend to confuse users and cause people
to send bug reports. So in this case I'd add one.

Thanks,

	tglx