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

2020-10-12 Thread Sasha Levin
From: Marc Zyngier 

[ Upstream commit 8b81edd80baf12d64420daff1759380aa9a14998 ]

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), 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 
Link: https://lore.kernel.org/r/20201005140217.1390851-1-...@kernel.org
Signed-off-by: Linus Walleij 
Signed-off-by: Sasha Levin 
---
 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 11c3bbd105f11..1de182b85e4c4 100644
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -821,8 +821,21 @@ static irqreturn_t pca953x_irq_handler(int irq, void 
*devid)
ret = pca953x_irq_pending(chip, pending);
mutex_unlock(>i2c_lock);
 
-   for_each_set_bit(level, pending, gc->ngpio)
-   handle_nested_irq(irq_find_mapping(gc->irq.domain, level));
+   if (ret) {
+   ret = 0;
+
+   for_each_set_bit(level, pending, gc->ngpio) {
+   int nested_irq = irq_find_mapping(gc->irq.domain, 
level);
+
+   if (unlikely(nested_irq <= 0)) {
+   dev_warn_ratelimited(gc->parent, "unmapped 
interrupt %d\n", level);
+   continue;
+   }
+
+   handle_nested_irq(nested_irq);
+   ret = 1;
+   }
+   }
 
return IRQ_RETVAL(ret);
 }
-- 
2.25.1



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

2020-10-07 Thread Andy Shevchenko
On Wed, Oct 7, 2020 at 6:00 PM Marc Zyngier  wrote:
> On 2020-10-07 15:03, Andy Shevchenko wrote:
> > On Wed, Oct 7, 2020 at 4:20 PM Marc Zyngier  wrote:
> >> On 2020-10-07 14:10, Andy Shevchenko wrote:
> >> > On Wed, Oct 7, 2020 at 3:09 PM Marc Zyngier  wrote:
> >> >> On 2020-10-07 13:02, Andy Shevchenko wrote:
> >> >> > On Wed, Oct 7, 2020 at 12:49 PM Linus Walleij
> >> >> >  wrote:
> >> >> >> On Mon, Oct 5, 2020 at 4:02 PM Marc Zyngier  wrote:
> >> >> >>
> >> >> >> > 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), 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 [1]  fix the reported issue?
> >> >>
> >> >> Not at all.
> >> >>
> >> >> > Marc, can you confirm this?
> >> >> >
> >> >> > [1]: e43c26e12dd4 ("gpio: pca953x: Fix uninitialized pending 
> >> >> > variable")
> >> >>
> >> >> Different bug, really. If an interrupt is *really* pending, and no
> >> >> mapping established yet, feeding the result of irq_find_mapping() to
> >> >> handle_nested_irq() will lead to a panic.
> >> >
> >> > I don't understand. We have plenty of drivers doing exactly the way
> >> > without checking this returned code.
> >>
> >> I'm sure we do. Most driver code is buggy as hell, but I don't see
> >> that
> >> as a reason to cargo-cult the crap. The API is crystal clear that it
> >> can
> >> return 0 for no mapping, and 0 isn't a valid interrupt.
> >
> > Yes, and the problem here is that we got this response from IRQ core,
> > which we shouldn't.
>
> What do you mean? There is no mapping at all. and all the core code
> can tell you is exactly that. If you think that using an error code
> as a valid input to another function is OK, we have a much bigger
> problem.

Of course it's not okay. And that's what puzzles me. We shouldn't get
bit set in pending if there is no requested IRQ (handler assigned).
I think there is a bug indeed, but I'm not sure it is in the code you
are patching. Rather in the code when we are preparing a pending
bitmap.
Shouldn't we have unused (unassigned interrupts) being masked in the
first place?

I can imagine that we have the chip preconfigured by firmware and when
->probe() happens the enabled IRQs should be left untouched, but is it
the case?
I guess you are using a non-latched version of the GPIO expander (I
don't have such for a test).

I need to look at this closer...
Since Linus already applied this we will live with it now, but it
would be really helpful if you may dump the traces of non-working case
before this patch to analyze (I would like to see all regmap IO for
this chip).

> >> > What circumstances makes the mapping be absent?
> >>
> >> Other bugs in the system ([1]), spurious interrupts (which can
> >> *always*
> >> happen).
> >>
> >> > Shouldn't we rather change this:
> >> >
> >> > girq->handler = handle_simple_irq;
> >> > to this:
> >> > girq->handler = handle_bad_irq;
> >> > ?
> >>
> >> I don't understand what you are trying to achieve with that, apart
> >> from
> >> maybe breaking the driver. The right way to handle spurious interrupts
> >> is by telling the core code that the interrupt wasn't handled, and to
> >> let
> >> the spurious interrupt code do its magic.
> >
> > handle_bad_irq() is exactly for handling spurious IRQs as far as we
> > believe documentation. So, by default the driver assigns (should
> > assign) handle_bad_irq() to all IRQs as a default handler. If, by any
> > chance, we got it, we already have a proper handler in place. The read
> > handler is assigned whenever the IRQ core is called to register it (by
> > means of ->irq_set_type() callback). My understanding that GPIO IRQ
> > drivers are designed (should be designed) in this way.  The approach
> > will make us sure that we don't have spurious interrupts with assigned
> > handlers.
>
> I can't see how setting this to anything else can work, given that
> handle_nested_irq() knows nothing about this flow (it doesn't use
> any).



-- 
With Best Regards,
Andy Shevchenko


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

2020-10-07 Thread Marc Zyngier

On 2020-10-07 15:03, Andy Shevchenko wrote:

On Wed, Oct 7, 2020 at 4:20 PM Marc Zyngier  wrote:

On 2020-10-07 14:10, Andy Shevchenko wrote:
> On Wed, Oct 7, 2020 at 3:09 PM Marc Zyngier  wrote:
>> On 2020-10-07 13:02, Andy Shevchenko wrote:
>> > On Wed, Oct 7, 2020 at 12:49 PM Linus Walleij
>> >  wrote:
>> >> On Mon, Oct 5, 2020 at 4:02 PM Marc Zyngier  wrote:
>> >>
>> >> > 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), 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 [1]  fix the reported issue?
>>
>> Not at all.
>>
>> > Marc, can you confirm this?
>> >
>> > [1]: e43c26e12dd4 ("gpio: pca953x: Fix uninitialized pending variable")
>>
>> Different bug, really. If an interrupt is *really* pending, and no
>> mapping established yet, feeding the result of irq_find_mapping() to
>> handle_nested_irq() will lead to a panic.
>
> I don't understand. We have plenty of drivers doing exactly the way
> without checking this returned code.

I'm sure we do. Most driver code is buggy as hell, but I don't see 
that
as a reason to cargo-cult the crap. The API is crystal clear that it 
can

return 0 for no mapping, and 0 isn't a valid interrupt.


Yes, and the problem here is that we got this response from IRQ core,
which we shouldn't.


What do you mean? There is no mapping at all. and all the core code
can tell you is exactly that. If you think that using an error code
as a valid input to another function is OK, we have a much bigger
problem.




> What circumstances makes the mapping be absent?

Other bugs in the system ([1]), spurious interrupts (which can 
*always*

happen).

> Shouldn't we rather change this:
>
> girq->handler = handle_simple_irq;
> to this:
> girq->handler = handle_bad_irq;
> ?

I don't understand what you are trying to achieve with that, apart 
from

maybe breaking the driver. The right way to handle spurious interrupts
is by telling the core code that the interrupt wasn't handled, and to
let
the spurious interrupt code do its magic.


handle_bad_irq() is exactly for handling spurious IRQs as far as we
believe documentation. So, by default the driver assigns (should
assign) handle_bad_irq() to all IRQs as a default handler. If, by any
chance, we got it, we already have a proper handler in place. The read
handler is assigned whenever the IRQ core is called to register it (by
means of ->irq_set_type() callback). My understanding that GPIO IRQ
drivers are designed (should be designed) in this way.  The approach
will make us sure that we don't have spurious interrupts with assigned
handlers.


I can't see how setting this to anything else can work, given that
handle_nested_irq() knows nothing about this flow (it doesn't use
any).

M.
--
Jazz is not dead. It just smells funny...


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

2020-10-07 Thread Andy Shevchenko
On Wed, Oct 7, 2020 at 4:20 PM Marc Zyngier  wrote:
> On 2020-10-07 14:10, Andy Shevchenko wrote:
> > On Wed, Oct 7, 2020 at 3:09 PM Marc Zyngier  wrote:
> >> On 2020-10-07 13:02, Andy Shevchenko wrote:
> >> > On Wed, Oct 7, 2020 at 12:49 PM Linus Walleij
> >> >  wrote:
> >> >> On Mon, Oct 5, 2020 at 4:02 PM Marc Zyngier  wrote:
> >> >>
> >> >> > 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), 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 [1]  fix the reported issue?
> >>
> >> Not at all.
> >>
> >> > Marc, can you confirm this?
> >> >
> >> > [1]: e43c26e12dd4 ("gpio: pca953x: Fix uninitialized pending variable")
> >>
> >> Different bug, really. If an interrupt is *really* pending, and no
> >> mapping established yet, feeding the result of irq_find_mapping() to
> >> handle_nested_irq() will lead to a panic.
> >
> > I don't understand. We have plenty of drivers doing exactly the way
> > without checking this returned code.
>
> I'm sure we do. Most driver code is buggy as hell, but I don't see that
> as a reason to cargo-cult the crap. The API is crystal clear that it can
> return 0 for no mapping, and 0 isn't a valid interrupt.

Yes, and the problem here is that we got this response from IRQ core,
which we shouldn't.

> > What circumstances makes the mapping be absent?
>
> Other bugs in the system ([1]), spurious interrupts (which can *always*
> happen).
>
> > Shouldn't we rather change this:
> >
> > girq->handler = handle_simple_irq;
> > to this:
> > girq->handler = handle_bad_irq;
> > ?
>
> I don't understand what you are trying to achieve with that, apart from
> maybe breaking the driver. The right way to handle spurious interrupts
> is by telling the core code that the interrupt wasn't handled, and to
> let
> the spurious interrupt code do its magic.

handle_bad_irq() is exactly for handling spurious IRQs as far as we
believe documentation. So, by default the driver assigns (should
assign) handle_bad_irq() to all IRQs as a default handler. If, by any
chance, we got it, we already have a proper handler in place. The read
handler is assigned whenever the IRQ core is called to register it (by
means of ->irq_set_type() callback). My understanding that GPIO IRQ
drivers are designed (should be designed) in this way.  The approach
will make us sure that we don't have spurious interrupts with assigned
handlers.

> [1] https://lore.kernel.org/r/20201005111443.1390096-1-...@kernel.org


-- 
With Best Regards,
Andy Shevchenko


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

2020-10-07 Thread Marc Zyngier

On 2020-10-07 14:10, Andy Shevchenko wrote:

On Wed, Oct 7, 2020 at 3:09 PM Marc Zyngier  wrote:

On 2020-10-07 13:02, Andy Shevchenko wrote:
> On Wed, Oct 7, 2020 at 12:49 PM Linus Walleij
>  wrote:
>> On Mon, Oct 5, 2020 at 4:02 PM Marc Zyngier  wrote:
>>
>> > 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), 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 [1]  fix the reported issue?

Not at all.

> Marc, can you confirm this?
>
> [1]: e43c26e12dd4 ("gpio: pca953x: Fix uninitialized pending variable")

Different bug, really. If an interrupt is *really* pending, and no
mapping established yet, feeding the result of irq_find_mapping() to
handle_nested_irq() will lead to a panic.


I don't understand. We have plenty of drivers doing exactly the way
without checking this returned code.


I'm sure we do. Most driver code is buggy as hell, but I don't see that
as a reason to cargo-cult the crap. The API is crystal clear that it can
return 0 for no mapping, and 0 isn't a valid interrupt.


What circumstances makes the mapping be absent?


Other bugs in the system ([1]), spurious interrupts (which can *always*
happen).


Shouldn't we rather change this:

girq->handler = handle_simple_irq;
to this:
girq->handler = handle_bad_irq;
?


I don't understand what you are trying to achieve with that, apart from
maybe breaking the driver. The right way to handle spurious interrupts
is by telling the core code that the interrupt wasn't handled, and to 
let

the spurious interrupt code do its magic.

M.

[1] https://lore.kernel.org/r/20201005111443.1390096-1-...@kernel.org
--
Jazz is not dead. It just smells funny...


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

2020-10-07 Thread Andy Shevchenko
On Wed, Oct 7, 2020 at 3:09 PM Marc Zyngier  wrote:
> On 2020-10-07 13:02, Andy Shevchenko wrote:
> > On Wed, Oct 7, 2020 at 12:49 PM Linus Walleij
> >  wrote:
> >> On Mon, Oct 5, 2020 at 4:02 PM Marc Zyngier  wrote:
> >>
> >> > 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), 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 [1]  fix the reported issue?
>
> Not at all.
>
> > Marc, can you confirm this?
> >
> > [1]: e43c26e12dd4 ("gpio: pca953x: Fix uninitialized pending variable")
>
> Different bug, really. If an interrupt is *really* pending, and no
> mapping established yet, feeding the result of irq_find_mapping() to
> handle_nested_irq() will lead to a panic.

I don't understand. We have plenty of drivers doing exactly the way
without checking this returned code. What circumstances makes the
mapping be absent?

Shouldn't we rather change this:

girq->handler = handle_simple_irq;
to this:
girq->handler = handle_bad_irq;
?

> Recently seen on a Tegra system suffering from even more pathological
> bugs.


-- 
With Best Regards,
Andy Shevchenko


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

2020-10-07 Thread Marc Zyngier

On 2020-10-07 13:02, Andy Shevchenko wrote:
On Wed, Oct 7, 2020 at 12:49 PM Linus Walleij 
 wrote:


On Mon, Oct 5, 2020 at 4:02 PM Marc Zyngier  wrote:

> 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), 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 [1]  fix the reported issue?


Not at all.


Marc, can you confirm this?

[1]: e43c26e12dd4 ("gpio: pca953x: Fix uninitialized pending variable")


Different bug, really. If an interrupt is *really* pending, and no
mapping established yet, feeding the result of irq_find_mapping() to
handle_nested_irq() will lead to a panic.

Recently seen on a Tegra system suffering from even more pathological 
bugs.


M.
--
Jazz is not dead. It just smells funny...


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

2020-10-07 Thread Andy Shevchenko
On Wed, Oct 7, 2020 at 12:49 PM Linus Walleij  wrote:
>
> On Mon, Oct 5, 2020 at 4:02 PM Marc Zyngier  wrote:
>
> > 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), 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 [1]  fix the reported issue?
Marc, can you confirm this?

[1]: e43c26e12dd4 ("gpio: pca953x: Fix uninitialized pending variable")


-- 
With Best Regards,
Andy Shevchenko


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

2020-10-07 Thread Linus Walleij
On Mon, Oct 5, 2020 at 4:02 PM Marc Zyngier  wrote:

> 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), 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 

Patch applied for fixes.

Yours,
Linus Walleij


[PATCH] gpio: pca953x: Survive spurious interrupts

2020-10-05 Thread Marc Zyngier
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), 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 
---
 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
--- a/drivers/gpio/gpio-pca953x.c
+++ b/drivers/gpio/gpio-pca953x.c
@@ -824,8 +824,21 @@ static irqreturn_t pca953x_irq_handler(int irq, void 
*devid)
ret = pca953x_irq_pending(chip, pending);
mutex_unlock(>i2c_lock);
 
-   for_each_set_bit(level, pending, gc->ngpio)
-   handle_nested_irq(irq_find_mapping(gc->irq.domain, level));
+   if (ret) {
+   ret = 0;
+
+   for_each_set_bit(level, pending, gc->ngpio) {
+   int nested_irq = irq_find_mapping(gc->irq.domain, 
level);
+
+   if (unlikely(nested_irq <= 0)) {
+   dev_warn_ratelimited(gc->parent, "unmapped 
interrupt %d\n", level);
+   continue;
+   }
+
+   handle_nested_irq(nested_irq);
+   ret = 1;
+   }
+   }
 
return IRQ_RETVAL(ret);
 }
-- 
2.28.0



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

2020-09-21 Thread Greg Kroah-Hartman
From: Thomas Bogendoerfer 

[ Upstream commit b959b97860d0fee8c8f6a3e641d3c2ad76eab6be ]

On A20R machines the interrupt pending bits in cause register need to be
updated by requesting the chipset to do it. This needs to be done to
find the interrupt cause and after interrupt service. In
commit 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 
---
 arch/mips/sni/a20r.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/mips/sni/a20r.c b/arch/mips/sni/a20r.c
index f9407e1704762..c6af7047eb0d2 100644
--- a/arch/mips/sni/a20r.c
+++ b/arch/mips/sni/a20r.c
@@ -143,7 +143,10 @@ static struct platform_device sc26xx_pdev = {
},
 };
 
-static u32 a20r_ack_hwint(void)
+/*
+ * Trigger chipset to update CPU's CAUSE IP field
+ */
+static u32 a20r_update_cause_ip(void)
 {
u32 status = read_c0_status();
 
@@ -205,12 +208,14 @@ static void a20r_hwint(void)
int irq;
 
clear_c0_status(IE_IRQ0);
-   status = a20r_ack_hwint();
+   status = a20r_update_cause_ip();
cause = read_c0_cause();
 
irq = ffs(((cause & status) >> 8) & 0xf8);
if (likely(irq > 0))
do_IRQ(SNI_A20R_IRQ_BASE + irq - 1);
+
+   a20r_update_cause_ip();
set_c0_status(IE_IRQ0);
 }
 
-- 
2.25.1





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

2020-09-21 Thread Greg Kroah-Hartman
From: Thomas Bogendoerfer 

[ Upstream commit b959b97860d0fee8c8f6a3e641d3c2ad76eab6be ]

On A20R machines the interrupt pending bits in cause register need to be
updated by requesting the chipset to do it. This needs to be done to
find the interrupt cause and after interrupt service. In
commit 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 
---
 arch/mips/sni/a20r.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/mips/sni/a20r.c b/arch/mips/sni/a20r.c
index f9407e1704762..c6af7047eb0d2 100644
--- a/arch/mips/sni/a20r.c
+++ b/arch/mips/sni/a20r.c
@@ -143,7 +143,10 @@ static struct platform_device sc26xx_pdev = {
},
 };
 
-static u32 a20r_ack_hwint(void)
+/*
+ * Trigger chipset to update CPU's CAUSE IP field
+ */
+static u32 a20r_update_cause_ip(void)
 {
u32 status = read_c0_status();
 
@@ -205,12 +208,14 @@ static void a20r_hwint(void)
int irq;
 
clear_c0_status(IE_IRQ0);
-   status = a20r_ack_hwint();
+   status = a20r_update_cause_ip();
cause = read_c0_cause();
 
irq = ffs(((cause & status) >> 8) & 0xf8);
if (likely(irq > 0))
do_IRQ(SNI_A20R_IRQ_BASE + irq - 1);
+
+   a20r_update_cause_ip();
set_c0_status(IE_IRQ0);
 }
 
-- 
2.25.1





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

2020-09-21 Thread Greg Kroah-Hartman
From: Thomas Bogendoerfer 

[ Upstream commit b959b97860d0fee8c8f6a3e641d3c2ad76eab6be ]

On A20R machines the interrupt pending bits in cause register need to be
updated by requesting the chipset to do it. This needs to be done to
find the interrupt cause and after interrupt service. In
commit 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 
---
 arch/mips/sni/a20r.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/mips/sni/a20r.c b/arch/mips/sni/a20r.c
index f9407e1704762..c6af7047eb0d2 100644
--- a/arch/mips/sni/a20r.c
+++ b/arch/mips/sni/a20r.c
@@ -143,7 +143,10 @@ static struct platform_device sc26xx_pdev = {
},
 };
 
-static u32 a20r_ack_hwint(void)
+/*
+ * Trigger chipset to update CPU's CAUSE IP field
+ */
+static u32 a20r_update_cause_ip(void)
 {
u32 status = read_c0_status();
 
@@ -205,12 +208,14 @@ static void a20r_hwint(void)
int irq;
 
clear_c0_status(IE_IRQ0);
-   status = a20r_ack_hwint();
+   status = a20r_update_cause_ip();
cause = read_c0_cause();
 
irq = ffs(((cause & status) >> 8) & 0xf8);
if (likely(irq > 0))
do_IRQ(SNI_A20R_IRQ_BASE + irq - 1);
+
+   a20r_update_cause_ip();
set_c0_status(IE_IRQ0);
 }
 
-- 
2.25.1





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

2020-09-21 Thread Greg Kroah-Hartman
From: Thomas Bogendoerfer 

[ Upstream commit b959b97860d0fee8c8f6a3e641d3c2ad76eab6be ]

On A20R machines the interrupt pending bits in cause register need to be
updated by requesting the chipset to do it. This needs to be done to
find the interrupt cause and after interrupt service. In
commit 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 
---
 arch/mips/sni/a20r.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/mips/sni/a20r.c b/arch/mips/sni/a20r.c
index f9407e1704762..c6af7047eb0d2 100644
--- a/arch/mips/sni/a20r.c
+++ b/arch/mips/sni/a20r.c
@@ -143,7 +143,10 @@ static struct platform_device sc26xx_pdev = {
},
 };
 
-static u32 a20r_ack_hwint(void)
+/*
+ * Trigger chipset to update CPU's CAUSE IP field
+ */
+static u32 a20r_update_cause_ip(void)
 {
u32 status = read_c0_status();
 
@@ -205,12 +208,14 @@ static void a20r_hwint(void)
int irq;
 
clear_c0_status(IE_IRQ0);
-   status = a20r_ack_hwint();
+   status = a20r_update_cause_ip();
cause = read_c0_cause();
 
irq = ffs(((cause & status) >> 8) & 0xf8);
if (likely(irq > 0))
do_IRQ(SNI_A20R_IRQ_BASE + irq - 1);
+
+   a20r_update_cause_ip();
set_c0_status(IE_IRQ0);
 }
 
-- 
2.25.1





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

2020-09-21 Thread Greg Kroah-Hartman
From: Thomas Bogendoerfer 

[ Upstream commit b959b97860d0fee8c8f6a3e641d3c2ad76eab6be ]

On A20R machines the interrupt pending bits in cause register need to be
updated by requesting the chipset to do it. This needs to be done to
find the interrupt cause and after interrupt service. In
commit 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 
---
 arch/mips/sni/a20r.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/mips/sni/a20r.c b/arch/mips/sni/a20r.c
index b09dc844985a8..c18c420a6 100644
--- a/arch/mips/sni/a20r.c
+++ b/arch/mips/sni/a20r.c
@@ -143,7 +143,10 @@ static struct platform_device sc26xx_pdev = {
},
 };
 
-static u32 a20r_ack_hwint(void)
+/*
+ * Trigger chipset to update CPU's CAUSE IP field
+ */
+static u32 a20r_update_cause_ip(void)
 {
u32 status = read_c0_status();
 
@@ -205,12 +208,14 @@ static void a20r_hwint(void)
int irq;
 
clear_c0_status(IE_IRQ0);
-   status = a20r_ack_hwint();
+   status = a20r_update_cause_ip();
cause = read_c0_cause();
 
irq = ffs(((cause & status) >> 8) & 0xf8);
if (likely(irq > 0))
do_IRQ(SNI_A20R_IRQ_BASE + irq - 1);
+
+   a20r_update_cause_ip();
set_c0_status(IE_IRQ0);
 }
 
-- 
2.25.1





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

2020-09-21 Thread Greg Kroah-Hartman
From: Thomas Bogendoerfer 

[ Upstream commit b959b97860d0fee8c8f6a3e641d3c2ad76eab6be ]

On A20R machines the interrupt pending bits in cause register need to be
updated by requesting the chipset to do it. This needs to be done to
find the interrupt cause and after interrupt service. In
commit 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 
---
 arch/mips/sni/a20r.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/mips/sni/a20r.c b/arch/mips/sni/a20r.c
index f9407e1704762..c6af7047eb0d2 100644
--- a/arch/mips/sni/a20r.c
+++ b/arch/mips/sni/a20r.c
@@ -143,7 +143,10 @@ static struct platform_device sc26xx_pdev = {
},
 };
 
-static u32 a20r_ack_hwint(void)
+/*
+ * Trigger chipset to update CPU's CAUSE IP field
+ */
+static u32 a20r_update_cause_ip(void)
 {
u32 status = read_c0_status();
 
@@ -205,12 +208,14 @@ static void a20r_hwint(void)
int irq;
 
clear_c0_status(IE_IRQ0);
-   status = a20r_ack_hwint();
+   status = a20r_update_cause_ip();
cause = read_c0_cause();
 
irq = ffs(((cause & status) >> 8) & 0xf8);
if (likely(irq > 0))
do_IRQ(SNI_A20R_IRQ_BASE + irq - 1);
+
+   a20r_update_cause_ip();
set_c0_status(IE_IRQ0);
 }
 
-- 
2.25.1





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

2020-09-17 Thread Thomas Bogendoerfer
On Wed, Sep 16, 2020 at 03:54:37PM +0200, Thomas Bogendoerfer wrote:
> On A20R machines the interrupt pending bits in cause register need to be
> updated by requesting the chipset to do it. This needs to be done to
> find the interrupt cause and after interrupt service. In
> commit 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 
> ---
>  arch/mips/sni/a20r.c | 9 +++--
>  1 file changed, 7 insertions(+), 2 deletions(-)

applied to mips-fixes.

Thomas.

-- 
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea.[ RFC1925, 2.3 ]


[PATCH] MIPS: SNI: Fix spurious interrupts

2020-09-16 Thread Thomas Bogendoerfer
On A20R machines the interrupt pending bits in cause register need to be
updated by requesting the chipset to do it. This needs to be done to
find the interrupt cause and after interrupt service. In
commit 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 
---
 arch/mips/sni/a20r.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/arch/mips/sni/a20r.c b/arch/mips/sni/a20r.c
index b09dc844985a..c18c420a 100644
--- a/arch/mips/sni/a20r.c
+++ b/arch/mips/sni/a20r.c
@@ -143,7 +143,10 @@ static struct platform_device sc26xx_pdev = {
},
 };
 
-static u32 a20r_ack_hwint(void)
+/*
+ * Trigger chipset to update CPU's CAUSE IP field
+ */
+static u32 a20r_update_cause_ip(void)
 {
u32 status = read_c0_status();
 
@@ -205,12 +208,14 @@ static void a20r_hwint(void)
int irq;
 
clear_c0_status(IE_IRQ0);
-   status = a20r_ack_hwint();
+   status = a20r_update_cause_ip();
cause = read_c0_cause();
 
irq = ffs(((cause & status) >> 8) & 0xf8);
if (likely(irq > 0))
do_IRQ(SNI_A20R_IRQ_BASE + irq - 1);
+
+   a20r_update_cause_ip();
set_c0_status(IE_IRQ0);
 }
 
-- 
2.16.4



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

2019-10-09 Thread Ulf Hansson
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
> message:
>
>   mmc1: Got data interrupt 0x0002 even though no data operation was in 
> progress.
>   mmc1: sdhci:  SDHCI REGISTER DUMP ===
>   mmc1: sdhci: Sys addr:  0x | Version:  0x1002
>   mmc1: sdhci: Blk size:  0x7200 | Blk cnt:  0x
>   mmc1: sdhci: Argument:  0x | Trn mode: 0x0033
>   mmc1: sdhci: Present:   0x1fff | Host ctl: 0x0017
>   mmc1: sdhci: Power: 0x000f | Blk gap:  0x0080
>   mmc1: sdhci: Wake-up:   0x | Clock:0x0107
>   mmc1: sdhci: Timeout:   0x | Int stat: 0x
>   mmc1: sdhci: Int enab:  0x03ff100b | Sig enab: 0x03ff100b
>   mmc1: sdhci: ACmd stat: 0x | Slot int: 0x
>   mmc1: sdhci: Caps:  0x45ee6432 | Caps_1:   0xa525
>   mmc1: sdhci: Cmd:   0x0c1a | Max curr: 0x00080008
>   mmc1: sdhci: Resp[0]:   0x0b00 | Resp[1]:  0x00edc87f
>   mmc1: sdhci: Resp[2]:   0x325b5900 | Resp[3]:  0x00400e00
>   mmc1: sdhci: Host ctl2: 0x0001
>   mmc1: sdhci: ADMA Err:  0x | ADMA Ptr: 0xf3025208
>   mmc1: sdhci: 
>
> Enable SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 to enable ACMD12 on multiblock
> reads and suppress the spurious interrupts.
>
> Fixes: f84e411c85be ("mmc: sdhci-iproc: Add support for emmc2 of the BCM2711")
> Signed-off-by: Nicolas Saenz Julienne 
> Tested-by: Matthias Brugger 
> Acked-by: Stefan Wahren 

Applied for fixes, thanks!

Kind regards
Uffe


> ---
>
> Changes since v1:
> - Add Fixes tag and Acked-by
>
>  drivers/mmc/host/sdhci-iproc.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
> index 2b9cdcd1dd9d..f4f5f0a70cda 100644
> --- a/drivers/mmc/host/sdhci-iproc.c
> +++ b/drivers/mmc/host/sdhci-iproc.c
> @@ -262,6 +262,7 @@ static const struct sdhci_iproc_data bcm2835_data = {
>  };
>
>  static const struct sdhci_pltfm_data sdhci_bcm2711_pltfm_data = {
> +   .quirks = SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12,
> .ops = _iproc_32only_ops,
>  };
>
> --
> 2.23.0
>


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

2019-10-04 Thread Nicolas Saenz Julienne
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 was in 
progress.
  mmc1: sdhci:  SDHCI REGISTER DUMP ===
  mmc1: sdhci: Sys addr:  0x | Version:  0x1002
  mmc1: sdhci: Blk size:  0x7200 | Blk cnt:  0x
  mmc1: sdhci: Argument:  0x | Trn mode: 0x0033
  mmc1: sdhci: Present:   0x1fff | Host ctl: 0x0017
  mmc1: sdhci: Power: 0x000f | Blk gap:  0x0080
  mmc1: sdhci: Wake-up:   0x | Clock:0x0107
  mmc1: sdhci: Timeout:   0x | Int stat: 0x
  mmc1: sdhci: Int enab:  0x03ff100b | Sig enab: 0x03ff100b
  mmc1: sdhci: ACmd stat: 0x | Slot int: 0x
  mmc1: sdhci: Caps:  0x45ee6432 | Caps_1:   0xa525
  mmc1: sdhci: Cmd:   0x0c1a | Max curr: 0x00080008
  mmc1: sdhci: Resp[0]:   0x0b00 | Resp[1]:  0x00edc87f
  mmc1: sdhci: Resp[2]:   0x325b5900 | Resp[3]:  0x00400e00
  mmc1: sdhci: Host ctl2: 0x0001
  mmc1: sdhci: ADMA Err:  0x | ADMA Ptr: 0xf3025208
  mmc1: sdhci: 

Enable SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 to enable ACMD12 on multiblock
reads and suppress the spurious interrupts.

Fixes: f84e411c85be ("mmc: sdhci-iproc: Add support for emmc2 of the BCM2711")
Signed-off-by: Nicolas Saenz Julienne 
Tested-by: Matthias Brugger 
Acked-by: Stefan Wahren 
---

Changes since v1:
- Add Fixes tag and Acked-by

 drivers/mmc/host/sdhci-iproc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
index 2b9cdcd1dd9d..f4f5f0a70cda 100644
--- a/drivers/mmc/host/sdhci-iproc.c
+++ b/drivers/mmc/host/sdhci-iproc.c
@@ -262,6 +262,7 @@ static const struct sdhci_iproc_data bcm2835_data = {
 };
 
 static const struct sdhci_pltfm_data sdhci_bcm2711_pltfm_data = {
+   .quirks = SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12,
.ops = _iproc_32only_ops,
 };
 
-- 
2.23.0



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

2019-10-04 Thread Stefan Wahren
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
>> spurious interrupts after the data transfer is done with the following
>> message:
>>
>>   mmc1: Got data interrupt 0x0002 even though no data operation was in
>> progress.
>>   mmc1: sdhci:  SDHCI REGISTER DUMP ===
>>   mmc1: sdhci: Sys addr:  0x | Version:  0x1002
>>   mmc1: sdhci: Blk size:  0x7200 | Blk cnt:  0x
>>   mmc1: sdhci: Argument:  0x | Trn mode: 0x0033
>>   mmc1: sdhci: Present:   0x1fff | Host ctl: 0x0017
>>   mmc1: sdhci: Power: 0x000f | Blk gap:  0x0080
>>   mmc1: sdhci: Wake-up:   0x | Clock:0x0107
>>   mmc1: sdhci: Timeout:   0x | Int stat: 0x
>>   mmc1: sdhci: Int enab:  0x03ff100b | Sig enab: 0x03ff100b
>>   mmc1: sdhci: ACmd stat: 0x | Slot int: 0x
>>   mmc1: sdhci: Caps:  0x45ee6432 | Caps_1:   0xa525
>>   mmc1: sdhci: Cmd:   0x0c1a | Max curr: 0x00080008
>>   mmc1: sdhci: Resp[0]:   0x0b00 | Resp[1]:  0x00edc87f
>>   mmc1: sdhci: Resp[2]:   0x325b5900 | Resp[3]:  0x00400e00
>>   mmc1: sdhci: Host ctl2: 0x0001
>>   mmc1: sdhci: ADMA Err:  0x | ADMA Ptr: 0xf3025208
>>   mmc1: sdhci: ========
>>
>> Enable SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 to enable ACMD12 on multiblock
>> reads and suppress the spurious interrupts.
>>
>> Signed-off-by: Nicolas Saenz Julienne 
>> Tested-by: Matthias Brugger 
> Forgot to add:
>
> Fixes: f84e411c85be ("mmc: sdhci-iproc: Add support for emmc2 of the BCM2711")
>
> I'll resend if needed.

Yes, please and you can add my:

Acked-by: Stefan Wahren 

>
> Regards,
> Nicolas
>
>
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel


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

2019-10-04 Thread 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
> spurious interrupts after the data transfer is done with the following
> message:
> 
>   mmc1: Got data interrupt 0x0002 even though no data operation was in
> progress.
>   mmc1: sdhci:  SDHCI REGISTER DUMP ===
>   mmc1: sdhci: Sys addr:  0x | Version:  0x1002
>   mmc1: sdhci: Blk size:  0x7200 | Blk cnt:  0x
>   mmc1: sdhci: Argument:  0x | Trn mode: 0x0033
>   mmc1: sdhci: Present:   0x1fff | Host ctl: 0x0017
>   mmc1: sdhci: Power: 0x000f | Blk gap:  0x0080
>   mmc1: sdhci: Wake-up:   0x | Clock:0x0107
>   mmc1: sdhci: Timeout:   0x | Int stat: 0x
>   mmc1: sdhci: Int enab:  0x03ff100b | Sig enab: 0x03ff100b
>   mmc1: sdhci: ACmd stat: 0x | Slot int: 0x
>   mmc1: sdhci: Caps:  0x45ee6432 | Caps_1:   0xa525
>   mmc1: sdhci: Cmd:   0x0c1a | Max curr: 0x00080008
>   mmc1: sdhci: Resp[0]:   0x0b00 | Resp[1]:  0x00edc87f
>   mmc1: sdhci: Resp[2]:   0x325b5900 | Resp[3]:  0x00400e00
>   mmc1: sdhci: Host ctl2: 0x0001
>   mmc1: sdhci: ADMA Err:  0x | ADMA Ptr: 0xf3025208
>   mmc1: sdhci: 
> 
> Enable SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 to enable ACMD12 on multiblock
> reads and suppress the spurious interrupts.
> 
> Signed-off-by: Nicolas Saenz Julienne 
> Tested-by: Matthias Brugger 

Forgot to add:

Fixes: f84e411c85be ("mmc: sdhci-iproc: Add support for emmc2 of the BCM2711")

I'll resend if needed.

Regards,
Nicolas



signature.asc
Description: This is a digitally signed message part


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

2019-10-04 Thread Nicolas Saenz Julienne
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 was in 
progress.
  mmc1: sdhci:  SDHCI REGISTER DUMP ===
  mmc1: sdhci: Sys addr:  0x | Version:  0x1002
  mmc1: sdhci: Blk size:  0x7200 | Blk cnt:  0x
  mmc1: sdhci: Argument:  0x | Trn mode: 0x0033
  mmc1: sdhci: Present:   0x1fff | Host ctl: 0x0017
  mmc1: sdhci: Power: 0x000f | Blk gap:  0x0080
  mmc1: sdhci: Wake-up:   0x | Clock:0x0107
  mmc1: sdhci: Timeout:   0x | Int stat: 0x
  mmc1: sdhci: Int enab:  0x03ff100b | Sig enab: 0x03ff100b
  mmc1: sdhci: ACmd stat: 0x | Slot int: 0x
  mmc1: sdhci: Caps:  0x45ee6432 | Caps_1:   0xa525
  mmc1: sdhci: Cmd:   0x0c1a | Max curr: 0x00080008
  mmc1: sdhci: Resp[0]:   0x0b00 | Resp[1]:  0x00edc87f
  mmc1: sdhci: Resp[2]:   0x325b5900 | Resp[3]:  0x00400e00
  mmc1: sdhci: Host ctl2: 0x0001
  mmc1: sdhci: ADMA Err:  0x | ADMA Ptr: 0xf3025208
  mmc1: sdhci: 

Enable SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12 to enable ACMD12 on multiblock
reads and suppress the spurious interrupts.

Signed-off-by: Nicolas Saenz Julienne 
Tested-by: Matthias Brugger 
---
 drivers/mmc/host/sdhci-iproc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/host/sdhci-iproc.c b/drivers/mmc/host/sdhci-iproc.c
index 2b9cdcd1dd9d..f4f5f0a70cda 100644
--- a/drivers/mmc/host/sdhci-iproc.c
+++ b/drivers/mmc/host/sdhci-iproc.c
@@ -262,6 +262,7 @@ static const struct sdhci_iproc_data bcm2835_data = {
 };
 
 static const struct sdhci_pltfm_data sdhci_bcm2711_pltfm_data = {
+   .quirks = SDHCI_QUIRK_MULTIBLOCK_READ_ACMD12,
.ops = _iproc_32only_ops,
 };
 
-- 
2.23.0



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

2019-07-24 Thread Greg Kroah-Hartman
[ 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 triggers an interrupt after the clear
and before the mask.

To prevent the second spurious interrupt the driver needs to mask the
IRQ before reading and clearing it.

Signed-off-by: Maya Erez 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/ath/wil6210/interrupt.c | 65 
 1 file changed, 40 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/interrupt.c 
b/drivers/net/wireless/ath/wil6210/interrupt.c
index 5d287a8e1b45..0655cd884514 100644
--- a/drivers/net/wireless/ath/wil6210/interrupt.c
+++ b/drivers/net/wireless/ath/wil6210/interrupt.c
@@ -296,21 +296,24 @@ void wil_configure_interrupt_moderation(struct 
wil6210_priv *wil)
 static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err_ratelimited(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx(wil);
-
/* RX_DONE and RX_HTRSH interrupts are the same if interrupt
 * moderation is not used. Interrupt moderation may cause RX
 * buffer overflow while RX_DONE is delayed. The required
@@ -355,21 +358,24 @@ static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 static irqreturn_t wil6210_irq_rx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx_edma(wil);
-
if (likely(isr & BIT_RX_STATUS_IRQ)) {
wil_dbg_irq(wil, "RX status ring\n");
isr &= ~BIT_RX_STATUS_IRQ;
@@ -403,21 +409,24 @@ static irqreturn_t wil6210_irq_rx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_tx(isr);
wil_dbg_irq(wil, "ISR TX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: TX\n");
+   wil6210_unmask_irq_tx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_tx_edma(wil);
-
if (likely(isr & BIT_TX_STATUS_IRQ)) {
wil_dbg_irq(wil, "TX status ring\n");
isr &= ~BIT_TX_STATUS_IRQ;
@@ -446,21 +455,24 @@ static irqreturn_t wil6210_irq_tx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+

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

2019-07-24 Thread Greg Kroah-Hartman
[ 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 triggers an interrupt after the clear
and before the mask.

To prevent the second spurious interrupt the driver needs to mask the
IRQ before reading and clearing it.

Signed-off-by: Maya Erez 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/ath/wil6210/interrupt.c | 65 
 1 file changed, 40 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/interrupt.c 
b/drivers/net/wireless/ath/wil6210/interrupt.c
index e41ba24011d8..b00a13d6d530 100644
--- a/drivers/net/wireless/ath/wil6210/interrupt.c
+++ b/drivers/net/wireless/ath/wil6210/interrupt.c
@@ -296,21 +296,24 @@ void wil_configure_interrupt_moderation(struct 
wil6210_priv *wil)
 static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err_ratelimited(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx(wil);
-
/* RX_DONE and RX_HTRSH interrupts are the same if interrupt
 * moderation is not used. Interrupt moderation may cause RX
 * buffer overflow while RX_DONE is delayed. The required
@@ -355,21 +358,24 @@ static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 static irqreturn_t wil6210_irq_rx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx_edma(wil);
-
if (likely(isr & BIT_RX_STATUS_IRQ)) {
wil_dbg_irq(wil, "RX status ring\n");
isr &= ~BIT_RX_STATUS_IRQ;
@@ -403,21 +409,24 @@ static irqreturn_t wil6210_irq_rx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_tx(isr);
wil_dbg_irq(wil, "ISR TX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: TX\n");
+   wil6210_unmask_irq_tx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_tx_edma(wil);
-
if (likely(isr & BIT_TX_STATUS_IRQ)) {
wil_dbg_irq(wil, "TX status ring\n");
isr &= ~BIT_TX_STATUS_IRQ;
@@ -446,21 +455,24 @@ static irqreturn_t wil6210_irq_tx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+

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

2019-07-24 Thread Greg Kroah-Hartman
[ 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 triggers an interrupt after the clear
and before the mask.

To prevent the second spurious interrupt the driver needs to mask the
IRQ before reading and clearing it.

Signed-off-by: Maya Erez 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/ath/wil6210/interrupt.c | 65 
 1 file changed, 40 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/interrupt.c 
b/drivers/net/wireless/ath/wil6210/interrupt.c
index e41ba24011d8..b00a13d6d530 100644
--- a/drivers/net/wireless/ath/wil6210/interrupt.c
+++ b/drivers/net/wireless/ath/wil6210/interrupt.c
@@ -296,21 +296,24 @@ void wil_configure_interrupt_moderation(struct 
wil6210_priv *wil)
 static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err_ratelimited(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx(wil);
-
/* RX_DONE and RX_HTRSH interrupts are the same if interrupt
 * moderation is not used. Interrupt moderation may cause RX
 * buffer overflow while RX_DONE is delayed. The required
@@ -355,21 +358,24 @@ static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 static irqreturn_t wil6210_irq_rx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx_edma(wil);
-
if (likely(isr & BIT_RX_STATUS_IRQ)) {
wil_dbg_irq(wil, "RX status ring\n");
isr &= ~BIT_RX_STATUS_IRQ;
@@ -403,21 +409,24 @@ static irqreturn_t wil6210_irq_rx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_tx(isr);
wil_dbg_irq(wil, "ISR TX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: TX\n");
+   wil6210_unmask_irq_tx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_tx_edma(wil);
-
if (likely(isr & BIT_TX_STATUS_IRQ)) {
wil_dbg_irq(wil, "TX status ring\n");
isr &= ~BIT_TX_STATUS_IRQ;
@@ -446,21 +455,24 @@ static irqreturn_t wil6210_irq_tx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+

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

2019-07-15 Thread Sasha Levin
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 happen in case HW triggers an interrupt after the clear
and before the mask.

To prevent the second spurious interrupt the driver needs to mask the
IRQ before reading and clearing it.

Signed-off-by: Maya Erez 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/ath/wil6210/interrupt.c | 65 
 1 file changed, 40 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/interrupt.c 
b/drivers/net/wireless/ath/wil6210/interrupt.c
index 5d287a8e1b45..0655cd884514 100644
--- a/drivers/net/wireless/ath/wil6210/interrupt.c
+++ b/drivers/net/wireless/ath/wil6210/interrupt.c
@@ -296,21 +296,24 @@ void wil_configure_interrupt_moderation(struct 
wil6210_priv *wil)
 static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err_ratelimited(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx(wil);
-
/* RX_DONE and RX_HTRSH interrupts are the same if interrupt
 * moderation is not used. Interrupt moderation may cause RX
 * buffer overflow while RX_DONE is delayed. The required
@@ -355,21 +358,24 @@ static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 static irqreturn_t wil6210_irq_rx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx_edma(wil);
-
if (likely(isr & BIT_RX_STATUS_IRQ)) {
wil_dbg_irq(wil, "RX status ring\n");
isr &= ~BIT_RX_STATUS_IRQ;
@@ -403,21 +409,24 @@ static irqreturn_t wil6210_irq_rx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_tx(isr);
wil_dbg_irq(wil, "ISR TX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: TX\n");
+   wil6210_unmask_irq_tx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_tx_edma(wil);
-
if (likely(isr & BIT_TX_STATUS_IRQ)) {
wil_dbg_irq(wil, "TX status ring\n");
isr &= ~BIT_TX_STATUS_IRQ;
@@ -446,21 +455,24 @@ static irqreturn_t wil6210_irq_tx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+

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

2019-07-15 Thread Sasha Levin
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 happen in case HW triggers an interrupt after the clear
and before the mask.

To prevent the second spurious interrupt the driver needs to mask the
IRQ before reading and clearing it.

Signed-off-by: Maya Erez 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/ath/wil6210/interrupt.c | 65 
 1 file changed, 40 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/interrupt.c 
b/drivers/net/wireless/ath/wil6210/interrupt.c
index e41ba24011d8..b00a13d6d530 100644
--- a/drivers/net/wireless/ath/wil6210/interrupt.c
+++ b/drivers/net/wireless/ath/wil6210/interrupt.c
@@ -296,21 +296,24 @@ void wil_configure_interrupt_moderation(struct 
wil6210_priv *wil)
 static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err_ratelimited(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx(wil);
-
/* RX_DONE and RX_HTRSH interrupts are the same if interrupt
 * moderation is not used. Interrupt moderation may cause RX
 * buffer overflow while RX_DONE is delayed. The required
@@ -355,21 +358,24 @@ static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 static irqreturn_t wil6210_irq_rx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx_edma(wil);
-
if (likely(isr & BIT_RX_STATUS_IRQ)) {
wil_dbg_irq(wil, "RX status ring\n");
isr &= ~BIT_RX_STATUS_IRQ;
@@ -403,21 +409,24 @@ static irqreturn_t wil6210_irq_rx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_tx(isr);
wil_dbg_irq(wil, "ISR TX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: TX\n");
+   wil6210_unmask_irq_tx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_tx_edma(wil);
-
if (likely(isr & BIT_TX_STATUS_IRQ)) {
wil_dbg_irq(wil, "TX status ring\n");
isr &= ~BIT_TX_STATUS_IRQ;
@@ -446,21 +455,24 @@ static irqreturn_t wil6210_irq_tx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+

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

2019-07-15 Thread Sasha Levin
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 happen in case HW triggers an interrupt after the clear
and before the mask.

To prevent the second spurious interrupt the driver needs to mask the
IRQ before reading and clearing it.

Signed-off-by: Maya Erez 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/ath/wil6210/interrupt.c | 65 
 1 file changed, 40 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/interrupt.c 
b/drivers/net/wireless/ath/wil6210/interrupt.c
index e41ba24011d8..b00a13d6d530 100644
--- a/drivers/net/wireless/ath/wil6210/interrupt.c
+++ b/drivers/net/wireless/ath/wil6210/interrupt.c
@@ -296,21 +296,24 @@ void wil_configure_interrupt_moderation(struct 
wil6210_priv *wil)
 static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err_ratelimited(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx(wil);
-
/* RX_DONE and RX_HTRSH interrupts are the same if interrupt
 * moderation is not used. Interrupt moderation may cause RX
 * buffer overflow while RX_DONE is delayed. The required
@@ -355,21 +358,24 @@ static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 static irqreturn_t wil6210_irq_rx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx_edma(wil);
-
if (likely(isr & BIT_RX_STATUS_IRQ)) {
wil_dbg_irq(wil, "RX status ring\n");
isr &= ~BIT_RX_STATUS_IRQ;
@@ -403,21 +409,24 @@ static irqreturn_t wil6210_irq_rx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_tx(isr);
wil_dbg_irq(wil, "ISR TX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: TX\n");
+   wil6210_unmask_irq_tx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_tx_edma(wil);
-
if (likely(isr & BIT_TX_STATUS_IRQ)) {
wil_dbg_irq(wil, "TX status ring\n");
isr &= ~BIT_TX_STATUS_IRQ;
@@ -446,21 +455,24 @@ static irqreturn_t wil6210_irq_tx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+

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

2019-07-15 Thread Sasha Levin
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 happen in case HW triggers an interrupt after the clear
and before the mask.

To prevent the second spurious interrupt the driver needs to mask the
IRQ before reading and clearing it.

Signed-off-by: Maya Erez 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/ath/wil6210/interrupt.c | 65 
 1 file changed, 40 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/interrupt.c 
b/drivers/net/wireless/ath/wil6210/interrupt.c
index e41ba24011d8..b00a13d6d530 100644
--- a/drivers/net/wireless/ath/wil6210/interrupt.c
+++ b/drivers/net/wireless/ath/wil6210/interrupt.c
@@ -296,21 +296,24 @@ void wil_configure_interrupt_moderation(struct 
wil6210_priv *wil)
 static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err_ratelimited(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx(wil);
-
/* RX_DONE and RX_HTRSH interrupts are the same if interrupt
 * moderation is not used. Interrupt moderation may cause RX
 * buffer overflow while RX_DONE is delayed. The required
@@ -355,21 +358,24 @@ static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 static irqreturn_t wil6210_irq_rx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx_edma(wil);
-
if (likely(isr & BIT_RX_STATUS_IRQ)) {
wil_dbg_irq(wil, "RX status ring\n");
isr &= ~BIT_RX_STATUS_IRQ;
@@ -403,21 +409,24 @@ static irqreturn_t wil6210_irq_rx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_tx(isr);
wil_dbg_irq(wil, "ISR TX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: TX\n");
+   wil6210_unmask_irq_tx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_tx_edma(wil);
-
if (likely(isr & BIT_TX_STATUS_IRQ)) {
wil_dbg_irq(wil, "TX status ring\n");
isr &= ~BIT_TX_STATUS_IRQ;
@@ -446,21 +455,24 @@ static irqreturn_t wil6210_irq_tx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+

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

2019-07-15 Thread Sasha Levin
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 happen in case HW triggers an interrupt after the clear
and before the mask.

To prevent the second spurious interrupt the driver needs to mask the
IRQ before reading and clearing it.

Signed-off-by: Maya Erez 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/ath/wil6210/interrupt.c | 65 
 1 file changed, 40 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/interrupt.c 
b/drivers/net/wireless/ath/wil6210/interrupt.c
index 5d287a8e1b45..0655cd884514 100644
--- a/drivers/net/wireless/ath/wil6210/interrupt.c
+++ b/drivers/net/wireless/ath/wil6210/interrupt.c
@@ -296,21 +296,24 @@ void wil_configure_interrupt_moderation(struct 
wil6210_priv *wil)
 static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err_ratelimited(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx(wil);
-
/* RX_DONE and RX_HTRSH interrupts are the same if interrupt
 * moderation is not used. Interrupt moderation may cause RX
 * buffer overflow while RX_DONE is delayed. The required
@@ -355,21 +358,24 @@ static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 static irqreturn_t wil6210_irq_rx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx_edma(wil);
-
if (likely(isr & BIT_RX_STATUS_IRQ)) {
wil_dbg_irq(wil, "RX status ring\n");
isr &= ~BIT_RX_STATUS_IRQ;
@@ -403,21 +409,24 @@ static irqreturn_t wil6210_irq_rx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_tx(isr);
wil_dbg_irq(wil, "ISR TX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: TX\n");
+   wil6210_unmask_irq_tx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_tx_edma(wil);
-
if (likely(isr & BIT_TX_STATUS_IRQ)) {
wil_dbg_irq(wil, "TX status ring\n");
isr &= ~BIT_TX_STATUS_IRQ;
@@ -446,21 +455,24 @@ static irqreturn_t wil6210_irq_tx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+

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

2019-07-15 Thread Sasha Levin
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 happen in case HW triggers an interrupt after the clear
and before the mask.

To prevent the second spurious interrupt the driver needs to mask the
IRQ before reading and clearing it.

Signed-off-by: Maya Erez 
Signed-off-by: Kalle Valo 
Signed-off-by: Sasha Levin 
---
 drivers/net/wireless/ath/wil6210/interrupt.c | 65 
 1 file changed, 40 insertions(+), 25 deletions(-)

diff --git a/drivers/net/wireless/ath/wil6210/interrupt.c 
b/drivers/net/wireless/ath/wil6210/interrupt.c
index e41ba24011d8..b00a13d6d530 100644
--- a/drivers/net/wireless/ath/wil6210/interrupt.c
+++ b/drivers/net/wireless/ath/wil6210/interrupt.c
@@ -296,21 +296,24 @@ void wil_configure_interrupt_moderation(struct 
wil6210_priv *wil)
 static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err_ratelimited(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx(wil);
-
/* RX_DONE and RX_HTRSH interrupts are the same if interrupt
 * moderation is not used. Interrupt moderation may cause RX
 * buffer overflow while RX_DONE is delayed. The required
@@ -355,21 +358,24 @@ static irqreturn_t wil6210_irq_rx(int irq, void *cookie)
 static irqreturn_t wil6210_irq_rx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_RX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_rx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_RX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_rx(isr);
wil_dbg_irq(wil, "ISR RX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: RX\n");
+   wil6210_unmask_irq_rx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_rx_edma(wil);
-
if (likely(isr & BIT_RX_STATUS_IRQ)) {
wil_dbg_irq(wil, "RX status ring\n");
isr &= ~BIT_RX_STATUS_IRQ;
@@ -403,21 +409,24 @@ static irqreturn_t wil6210_irq_rx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx_edma(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_INT_GEN_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx_edma(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_INT_GEN_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+
trace_wil6210_irq_tx(isr);
wil_dbg_irq(wil, "ISR TX 0x%08x\n", isr);
 
if (unlikely(!isr)) {
wil_err(wil, "spurious IRQ: TX\n");
+   wil6210_unmask_irq_tx_edma(wil);
return IRQ_NONE;
}
 
-   wil6210_mask_irq_tx_edma(wil);
-
if (likely(isr & BIT_TX_STATUS_IRQ)) {
wil_dbg_irq(wil, "TX status ring\n");
isr &= ~BIT_TX_STATUS_IRQ;
@@ -446,21 +455,24 @@ static irqreturn_t wil6210_irq_tx_edma(int irq, void 
*cookie)
 static irqreturn_t wil6210_irq_tx(int irq, void *cookie)
 {
struct wil6210_priv *wil = cookie;
-   u32 isr = wil_ioread32_and_clear(wil->csr +
-HOSTADDR(RGF_DMA_EP_TX_ICR) +
-offsetof(struct RGF_ICR, ICR));
+   u32 isr;
bool need_unmask = true;
 
+   wil6210_mask_irq_tx(wil);
+
+   isr = wil_ioread32_and_clear(wil->csr +
+HOSTADDR(RGF_DMA_EP_TX_ICR) +
+offsetof(struct RGF_ICR, ICR));
+

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

2019-04-27 Thread Ben Hutchings
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 turned out that U-Boot left
the DMAC interrupts enabled while the Linux driver  didn't use those.
The SDHI driver's interrupt handler somehow assumes that, even if an
SDIO interrupt didn't happen, it should return IRQ_HANDLED.  I think
that if none of the enabled interrupts happened and got handled, we
should return IRQ_NONE -- that way the kernel IRQ code recoginizes
a spurious interrupt and masks it off pretty quickly...

Fixes: 7729c7a232a9 ("mmc: tmio: Provide separate interrupt handlers")
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Wolfram Sang 
Tested-by: Wolfram Sang 
Reviewed-by: Simon Horman 
Signed-off-by: Ulf Hansson 
[bwh: Backported to 3.16:
 - tmio_mmc_sdio_irq() can be used directly as an interrupt handler, so
   make it return IRQ_NONE for unhandled interrupts
 - Adjust filename]
Signed-off-by: Ben Hutchings 
---
--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -639,7 +639,7 @@ irqreturn_t tmio_mmc_sdio_irq(int irq, v
unsigned int ireg, status;
 
if (!(pdata->flags & TMIO_MMC_SDIO_IRQ))
-   return IRQ_HANDLED;
+   return IRQ_NONE;
 
status = sd_ctrl_read16(host, CTL_SDIO_STATUS);
ireg = status & TMIO_SDIO_MASK_ALL & ~host->sdcard_irq_mask;
@@ -649,7 +649,7 @@ irqreturn_t tmio_mmc_sdio_irq(int irq, v
if (mmc->caps & MMC_CAP_SDIO_IRQ && ireg & TMIO_SDIO_STAT_IOIRQ)
mmc_signal_sdio_irq(mmc);
 
-   return IRQ_HANDLED;
+   return ireg ? IRQ_HANDLED : IRQ_NONE;
 }
 EXPORT_SYMBOL(tmio_mmc_sdio_irq);
 
@@ -666,9 +666,7 @@ irqreturn_t tmio_mmc_irq(int irq, void *
if (__tmio_mmc_sdcard_irq(host, ireg, status))
return IRQ_HANDLED;
 
-   tmio_mmc_sdio_irq(irq, devid);
-
-   return IRQ_HANDLED;
+   return tmio_mmc_sdio_irq(irq, devid);
 }
 EXPORT_SYMBOL(tmio_mmc_irq);
 



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

2019-04-01 Thread Greg Kroah-Hartman
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 turned out that U-Boot left
the DMAC interrupts enabled while the Linux driver  didn't use those.
The SDHI driver's interrupt handler somehow assumes that, even if an
SDIO interrupt didn't happen, it should return IRQ_HANDLED.  I think
that if none of the enabled interrupts happened and got handled, we
should return IRQ_NONE -- that way the kernel IRQ code recoginizes
a spurious interrupt and masks it off pretty quickly...

Fixes: 7729c7a232a9 ("mmc: tmio: Provide separate interrupt handlers")
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Wolfram Sang 
Tested-by: Wolfram Sang 
Reviewed-by: Simon Horman 
Cc: sta...@vger.kernel.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mmc/host/tmio_mmc_pio.c |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -714,7 +714,7 @@ irqreturn_t tmio_mmc_sdio_irq(int irq, v
unsigned int sdio_status;
 
if (!(pdata->flags & TMIO_MMC_SDIO_IRQ))
-   return IRQ_HANDLED;
+   return IRQ_NONE;
 
status = sd_ctrl_read16(host, CTL_SDIO_STATUS);
ireg = status & TMIO_SDIO_MASK_ALL & ~host->sdcard_irq_mask;
@@ -728,7 +728,7 @@ irqreturn_t tmio_mmc_sdio_irq(int irq, v
if (mmc->caps & MMC_CAP_SDIO_IRQ && ireg & TMIO_SDIO_STAT_IOIRQ)
mmc_signal_sdio_irq(mmc);
 
-   return IRQ_HANDLED;
+   return IRQ_RETVAL(ireg);
 }
 EXPORT_SYMBOL(tmio_mmc_sdio_irq);
 
@@ -745,9 +745,7 @@ irqreturn_t tmio_mmc_irq(int irq, void *
if (__tmio_mmc_sdcard_irq(host, ireg, status))
return IRQ_HANDLED;
 
-   tmio_mmc_sdio_irq(irq, devid);
-
-   return IRQ_HANDLED;
+   return tmio_mmc_sdio_irq(irq, devid);
 }
 EXPORT_SYMBOL(tmio_mmc_irq);
 




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

2019-04-01 Thread Greg Kroah-Hartman
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 turned out that U-Boot left
the DMAC interrupts enabled while the Linux driver  didn't use those.
The SDHI driver's interrupt handler somehow assumes that, even if an
SDIO interrupt didn't happen, it should return IRQ_HANDLED.  I think
that if none of the enabled interrupts happened and got handled, we
should return IRQ_NONE -- that way the kernel IRQ code recoginizes
a spurious interrupt and masks it off pretty quickly...

Fixes: 7729c7a232a9 ("mmc: tmio: Provide separate interrupt handlers")
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Wolfram Sang 
Tested-by: Wolfram Sang 
Reviewed-by: Simon Horman 
Cc: sta...@vger.kernel.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mmc/host/tmio_mmc_pio.c |8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -716,7 +716,7 @@ irqreturn_t tmio_mmc_sdio_irq(int irq, v
unsigned int sdio_status;
 
if (!(pdata->flags & TMIO_MMC_SDIO_IRQ))
-   return IRQ_HANDLED;
+   return IRQ_NONE;
 
status = sd_ctrl_read16(host, CTL_SDIO_STATUS);
ireg = status & TMIO_SDIO_MASK_ALL & ~host->sdcard_irq_mask;
@@ -730,7 +730,7 @@ irqreturn_t tmio_mmc_sdio_irq(int irq, v
if (mmc->caps & MMC_CAP_SDIO_IRQ && ireg & TMIO_SDIO_STAT_IOIRQ)
mmc_signal_sdio_irq(mmc);
 
-   return IRQ_HANDLED;
+   return IRQ_RETVAL(ireg);
 }
 EXPORT_SYMBOL(tmio_mmc_sdio_irq);
 
@@ -747,9 +747,7 @@ irqreturn_t tmio_mmc_irq(int irq, void *
if (__tmio_mmc_sdcard_irq(host, ireg, status))
return IRQ_HANDLED;
 
-   tmio_mmc_sdio_irq(irq, devid);
-
-   return IRQ_HANDLED;
+   return tmio_mmc_sdio_irq(irq, devid);
 }
 EXPORT_SYMBOL(tmio_mmc_irq);
 




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

2019-03-18 Thread Greg Kroah-Hartman
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 turned out that U-Boot left
the DMAC interrupts enabled while the Linux driver  didn't use those.
The SDHI driver's interrupt handler somehow assumes that, even if an
SDIO interrupt didn't happen, it should return IRQ_HANDLED.  I think
that if none of the enabled interrupts happened and got handled, we
should return IRQ_NONE -- that way the kernel IRQ code recoginizes
a spurious interrupt and masks it off pretty quickly...

Fixes: 7729c7a232a9 ("mmc: tmio: Provide separate interrupt handlers")
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Wolfram Sang 
Tested-by: Wolfram Sang 
Reviewed-by: Simon Horman 
Cc: sta...@vger.kernel.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mmc/host/tmio_mmc_pio.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

--- a/drivers/mmc/host/tmio_mmc_pio.c
+++ b/drivers/mmc/host/tmio_mmc_pio.c
@@ -675,7 +675,7 @@ static bool __tmio_mmc_sdcard_irq(struct
return false;
 }
 
-static void tmio_mmc_sdio_irq(int irq, void *devid)
+static bool tmio_mmc_sdio_irq(int irq, void *devid)
 {
struct tmio_mmc_host *host = devid;
struct mmc_host *mmc = host->mmc;
@@ -684,7 +684,7 @@ static void tmio_mmc_sdio_irq(int irq, v
unsigned int sdio_status;
 
if (!(pdata->flags & TMIO_MMC_SDIO_IRQ))
-   return;
+   return false;
 
status = sd_ctrl_read16(host, CTL_SDIO_STATUS);
ireg = status & TMIO_SDIO_MASK_ALL & ~host->sdcard_irq_mask;
@@ -697,6 +697,8 @@ static void tmio_mmc_sdio_irq(int irq, v
 
if (mmc->caps & MMC_CAP_SDIO_IRQ && ireg & TMIO_SDIO_STAT_IOIRQ)
mmc_signal_sdio_irq(mmc);
+
+   return ireg;
 }
 
 irqreturn_t tmio_mmc_irq(int irq, void *devid)
@@ -718,9 +720,10 @@ irqreturn_t tmio_mmc_irq(int irq, void *
if (__tmio_mmc_sdcard_irq(host, ireg, status))
return IRQ_HANDLED;
 
-   tmio_mmc_sdio_irq(irq, devid);
+   if (tmio_mmc_sdio_irq(irq, devid))
+   return IRQ_HANDLED;
 
-   return IRQ_HANDLED;
+   return IRQ_NONE;
 }
 EXPORT_SYMBOL(tmio_mmc_irq);
 




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

2019-03-04 Thread Greg Kroah-Hartman
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 turned out that U-Boot left
the DMAC interrupts enabled while the Linux driver  didn't use those.
The SDHI driver's interrupt handler somehow assumes that, even if an
SDIO interrupt didn't happen, it should return IRQ_HANDLED.  I think
that if none of the enabled interrupts happened and got handled, we
should return IRQ_NONE -- that way the kernel IRQ code recoginizes
a spurious interrupt and masks it off pretty quickly...

Fixes: 7729c7a232a9 ("mmc: tmio: Provide separate interrupt handlers")
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Wolfram Sang 
Tested-by: Wolfram Sang 
Reviewed-by: Simon Horman 
Cc: sta...@vger.kernel.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mmc/host/tmio_mmc_core.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -688,7 +688,7 @@ static bool __tmio_mmc_sdcard_irq(struct
return false;
 }
 
-static void __tmio_mmc_sdio_irq(struct tmio_mmc_host *host)
+static bool __tmio_mmc_sdio_irq(struct tmio_mmc_host *host)
 {
struct mmc_host *mmc = host->mmc;
struct tmio_mmc_data *pdata = host->pdata;
@@ -696,7 +696,7 @@ static void __tmio_mmc_sdio_irq(struct t
unsigned int sdio_status;
 
if (!(pdata->flags & TMIO_MMC_SDIO_IRQ))
-   return;
+   return false;
 
status = sd_ctrl_read16(host, CTL_SDIO_STATUS);
ireg = status & TMIO_SDIO_MASK_ALL & ~host->sdio_irq_mask;
@@ -709,6 +709,8 @@ static void __tmio_mmc_sdio_irq(struct t
 
if (mmc->caps & MMC_CAP_SDIO_IRQ && ireg & TMIO_SDIO_STAT_IOIRQ)
mmc_signal_sdio_irq(mmc);
+
+   return ireg;
 }
 
 irqreturn_t tmio_mmc_irq(int irq, void *devid)
@@ -727,9 +729,10 @@ irqreturn_t tmio_mmc_irq(int irq, void *
if (__tmio_mmc_sdcard_irq(host, ireg, status))
return IRQ_HANDLED;
 
-   __tmio_mmc_sdio_irq(host);
+   if (__tmio_mmc_sdio_irq(host))
+   return IRQ_HANDLED;
 
-   return IRQ_HANDLED;
+   return IRQ_NONE;
 }
 EXPORT_SYMBOL_GPL(tmio_mmc_irq);
 




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

2019-03-04 Thread Greg Kroah-Hartman
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 turned out that U-Boot left
the DMAC interrupts enabled while the Linux driver  didn't use those.
The SDHI driver's interrupt handler somehow assumes that, even if an
SDIO interrupt didn't happen, it should return IRQ_HANDLED.  I think
that if none of the enabled interrupts happened and got handled, we
should return IRQ_NONE -- that way the kernel IRQ code recoginizes
a spurious interrupt and masks it off pretty quickly...

Fixes: 7729c7a232a9 ("mmc: tmio: Provide separate interrupt handlers")
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Wolfram Sang 
Tested-by: Wolfram Sang 
Reviewed-by: Simon Horman 
Cc: sta...@vger.kernel.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mmc/host/tmio_mmc_core.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -618,7 +618,7 @@ static bool __tmio_mmc_sdcard_irq(struct
return false;
 }
 
-static void __tmio_mmc_sdio_irq(struct tmio_mmc_host *host)
+static bool __tmio_mmc_sdio_irq(struct tmio_mmc_host *host)
 {
struct mmc_host *mmc = host->mmc;
struct tmio_mmc_data *pdata = host->pdata;
@@ -626,7 +626,7 @@ static void __tmio_mmc_sdio_irq(struct t
unsigned int sdio_status;
 
if (!(pdata->flags & TMIO_MMC_SDIO_IRQ))
-   return;
+   return false;
 
status = sd_ctrl_read16(host, CTL_SDIO_STATUS);
ireg = status & TMIO_SDIO_MASK_ALL & ~host->sdio_irq_mask;
@@ -639,6 +639,8 @@ static void __tmio_mmc_sdio_irq(struct t
 
if (mmc->caps & MMC_CAP_SDIO_IRQ && ireg & TMIO_SDIO_STAT_IOIRQ)
mmc_signal_sdio_irq(mmc);
+
+   return ireg;
 }
 
 irqreturn_t tmio_mmc_irq(int irq, void *devid)
@@ -657,9 +659,10 @@ irqreturn_t tmio_mmc_irq(int irq, void *
if (__tmio_mmc_sdcard_irq(host, ireg, status))
return IRQ_HANDLED;
 
-   __tmio_mmc_sdio_irq(host);
+   if (__tmio_mmc_sdio_irq(host))
+   return IRQ_HANDLED;
 
-   return IRQ_HANDLED;
+   return IRQ_NONE;
 }
 EXPORT_SYMBOL_GPL(tmio_mmc_irq);
 




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

2019-03-04 Thread Greg Kroah-Hartman
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 turned out that U-Boot left
the DMAC interrupts enabled while the Linux driver  didn't use those.
The SDHI driver's interrupt handler somehow assumes that, even if an
SDIO interrupt didn't happen, it should return IRQ_HANDLED.  I think
that if none of the enabled interrupts happened and got handled, we
should return IRQ_NONE -- that way the kernel IRQ code recoginizes
a spurious interrupt and masks it off pretty quickly...

Fixes: 7729c7a232a9 ("mmc: tmio: Provide separate interrupt handlers")
Signed-off-by: Sergei Shtylyov 
Reviewed-by: Wolfram Sang 
Tested-by: Wolfram Sang 
Reviewed-by: Simon Horman 
Cc: sta...@vger.kernel.org
Signed-off-by: Ulf Hansson 
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/mmc/host/tmio_mmc_core.c |   11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

--- a/drivers/mmc/host/tmio_mmc_core.c
+++ b/drivers/mmc/host/tmio_mmc_core.c
@@ -703,7 +703,7 @@ static bool __tmio_mmc_sdcard_irq(struct
return false;
 }
 
-static void __tmio_mmc_sdio_irq(struct tmio_mmc_host *host)
+static bool __tmio_mmc_sdio_irq(struct tmio_mmc_host *host)
 {
struct mmc_host *mmc = host->mmc;
struct tmio_mmc_data *pdata = host->pdata;
@@ -711,7 +711,7 @@ static void __tmio_mmc_sdio_irq(struct t
unsigned int sdio_status;
 
if (!(pdata->flags & TMIO_MMC_SDIO_IRQ))
-   return;
+   return false;
 
status = sd_ctrl_read16(host, CTL_SDIO_STATUS);
ireg = status & TMIO_SDIO_MASK_ALL & ~host->sdio_irq_mask;
@@ -724,6 +724,8 @@ static void __tmio_mmc_sdio_irq(struct t
 
if (mmc->caps & MMC_CAP_SDIO_IRQ && ireg & TMIO_SDIO_STAT_IOIRQ)
mmc_signal_sdio_irq(mmc);
+
+   return ireg;
 }
 
 irqreturn_t tmio_mmc_irq(int irq, void *devid)
@@ -742,9 +744,10 @@ irqreturn_t tmio_mmc_irq(int irq, void *
if (__tmio_mmc_sdcard_irq(host, ireg, status))
return IRQ_HANDLED;
 
-   __tmio_mmc_sdio_irq(host);
+   if (__tmio_mmc_sdio_irq(host))
+   return IRQ_HANDLED;
 
-   return IRQ_HANDLED;
+   return IRQ_NONE;
 }
 EXPORT_SYMBOL_GPL(tmio_mmc_irq);
 




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

2018-08-04 Thread Greg Kroah-Hartman
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 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: Dmitry Osipenko 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/memory/tegra/mc.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -252,8 +252,11 @@ static irqreturn_t tegra_mc_irq(int irq,
unsigned int bit;
 
/* mask all interrupts to avoid flooding */
-   status = mc_readl(mc, MC_INTSTATUS);
mask = mc_readl(mc, MC_INTMASK);
+   status = mc_readl(mc, MC_INTSTATUS) & mask;
+
+   if (!status)
+   return IRQ_NONE;
 
for_each_set_bit(bit, , 32) {
const char *error = status_names[bit] ?: "unknown";




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

2018-08-04 Thread Greg Kroah-Hartman
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 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: Dmitry Osipenko 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/memory/tegra/mc.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -252,8 +252,11 @@ static irqreturn_t tegra_mc_irq(int irq,
unsigned int bit;
 
/* mask all interrupts to avoid flooding */
-   status = mc_readl(mc, MC_INTSTATUS);
mask = mc_readl(mc, MC_INTMASK);
+   status = mc_readl(mc, MC_INTSTATUS) & mask;
+
+   if (!status)
+   return IRQ_NONE;
 
for_each_set_bit(bit, , 32) {
const char *error = status_names[bit] ?: "unknown";




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

2018-08-01 Thread Greg Kroah-Hartman
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 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: Dmitry Osipenko 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/memory/tegra/mc.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -252,8 +252,11 @@ static irqreturn_t tegra_mc_irq(int irq,
unsigned int bit;
 
/* mask all interrupts to avoid flooding */
-   status = mc_readl(mc, MC_INTSTATUS);
mask = mc_readl(mc, MC_INTMASK);
+   status = mc_readl(mc, MC_INTSTATUS) & mask;
+
+   if (!status)
+   return IRQ_NONE;
 
for_each_set_bit(bit, , 32) {
const char *error = status_names[bit] ?: "unknown";




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

2018-08-01 Thread Greg Kroah-Hartman
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 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: Dmitry Osipenko 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/memory/tegra/mc.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -252,8 +252,11 @@ static irqreturn_t tegra_mc_irq(int irq,
unsigned int bit;
 
/* mask all interrupts to avoid flooding */
-   status = mc_readl(mc, MC_INTSTATUS);
mask = mc_readl(mc, MC_INTMASK);
+   status = mc_readl(mc, MC_INTSTATUS) & mask;
+
+   if (!status)
+   return IRQ_NONE;
 
for_each_set_bit(bit, , 32) {
const char *error = status_names[bit] ?: "unknown";




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

2018-08-01 Thread Greg Kroah-Hartman
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 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: Dmitry Osipenko 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/memory/tegra/mc.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -252,8 +252,11 @@ static irqreturn_t tegra_mc_irq(int irq,
unsigned int bit;
 
/* mask all interrupts to avoid flooding */
-   status = mc_readl(mc, MC_INTSTATUS);
mask = mc_readl(mc, MC_INTMASK);
+   status = mc_readl(mc, MC_INTSTATUS) & mask;
+
+   if (!status)
+   return IRQ_NONE;
 
for_each_set_bit(bit, , 32) {
const char *error = status_names[bit] ?: "unknown";




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

2018-08-01 Thread Greg Kroah-Hartman
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 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: Dmitry Osipenko 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/memory/tegra/mc.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -252,8 +252,11 @@ static irqreturn_t tegra_mc_irq(int irq,
unsigned int bit;
 
/* mask all interrupts to avoid flooding */
-   status = mc_readl(mc, MC_INTSTATUS);
mask = mc_readl(mc, MC_INTMASK);
+   status = mc_readl(mc, MC_INTSTATUS) & mask;
+
+   if (!status)
+   return IRQ_NONE;
 
for_each_set_bit(bit, , 32) {
const char *error = status_names[bit] ?: "unknown";




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

2018-08-01 Thread Greg Kroah-Hartman
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 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: Dmitry Osipenko 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/memory/tegra/mc.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -252,8 +252,11 @@ static irqreturn_t tegra_mc_irq(int irq,
unsigned int bit;
 
/* mask all interrupts to avoid flooding */
-   status = mc_readl(mc, MC_INTSTATUS);
mask = mc_readl(mc, MC_INTMASK);
+   status = mc_readl(mc, MC_INTSTATUS) & mask;
+
+   if (!status)
+   return IRQ_NONE;
 
for_each_set_bit(bit, , 32) {
const char *error = status_names[bit] ?: "unknown";




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

2018-08-01 Thread Greg Kroah-Hartman
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 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: Dmitry Osipenko 
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/memory/tegra/mc.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -252,8 +252,11 @@ static irqreturn_t tegra_mc_irq(int irq,
unsigned int bit;
 
/* mask all interrupts to avoid flooding */
-   status = mc_readl(mc, MC_INTSTATUS);
mask = mc_readl(mc, MC_INTMASK);
+   status = mc_readl(mc, MC_INTSTATUS) & mask;
+
+   if (!status)
+   return IRQ_NONE;
 
for_each_set_bit(bit, , 32) {
const char *error = status_names[bit] ?: "unknown";




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

2018-05-08 Thread Greg Kroah-Hartman
4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Agustin Vega-Frias <agust...@codeaurora.org>

commit 1bc2463cee92ef0e2034c813d5e511adeb58b5fd upstream.

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 changelog ]

Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Agustin Vega-Frias <agust...@codeaurora.org>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: Jason Cooper <ja...@lakedaemon.net>
Cc: Marc Zyngier <marc.zyng...@arm.com>
Cc: ti...@codeaurora.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: sta...@vger.kernel.org
Link: 
https://lkml.kernel.org/r/1525184090-26143-1-git-send-email-agust...@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 drivers/irqchip/qcom-irq-combiner.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
@@ -68,7 +68,7 @@ static void combiner_handle_irq(struct i
 
bit = readl_relaxed(combiner->regs[reg].addr);
status = bit & combiner->regs[reg].enabled;
-   if (!status)
+   if (bit && !status)
pr_warn_ratelimited("Unexpected IRQ on CPU%d: (%08x 
%08lx %p)\n",
smp_processor_id(), bit,
combiner->regs[reg].enabled,




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

2018-05-08 Thread Greg Kroah-Hartman
4.16-stable review patch.  If anyone has any objections, please let me know.

--

From: Agustin Vega-Frias 

commit 1bc2463cee92ef0e2034c813d5e511adeb58b5fd upstream.

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 changelog ]

Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Agustin Vega-Frias 
Signed-off-by: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: ti...@codeaurora.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: sta...@vger.kernel.org
Link: 
https://lkml.kernel.org/r/1525184090-26143-1-git-send-email-agust...@codeaurora.org
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/irqchip/qcom-irq-combiner.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
@@ -68,7 +68,7 @@ static void combiner_handle_irq(struct i
 
bit = readl_relaxed(combiner->regs[reg].addr);
status = bit & combiner->regs[reg].enabled;
-   if (!status)
+   if (bit && !status)
pr_warn_ratelimited("Unexpected IRQ on CPU%d: (%08x 
%08lx %p)\n",
smp_processor_id(), bit,
combiner->regs[reg].enabled,




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

2018-05-08 Thread Greg Kroah-Hartman
4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Agustin Vega-Frias <agust...@codeaurora.org>

commit 1bc2463cee92ef0e2034c813d5e511adeb58b5fd upstream.

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 changelog ]

Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Agustin Vega-Frias <agust...@codeaurora.org>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: Jason Cooper <ja...@lakedaemon.net>
Cc: Marc Zyngier <marc.zyng...@arm.com>
Cc: ti...@codeaurora.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: sta...@vger.kernel.org
Link: 
https://lkml.kernel.org/r/1525184090-26143-1-git-send-email-agust...@codeaurora.org
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 drivers/irqchip/qcom-irq-combiner.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
@@ -68,7 +68,7 @@ static void combiner_handle_irq(struct i
 
bit = readl_relaxed(combiner->regs[reg].addr);
status = bit & combiner->regs[reg].enabled;
-   if (!status)
+   if (bit && !status)
pr_warn_ratelimited("Unexpected IRQ on CPU%d: (%08x 
%08lx %p)\n",
smp_processor_id(), bit,
combiner->regs[reg].enabled,




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

2018-05-08 Thread Greg Kroah-Hartman
4.14-stable review patch.  If anyone has any objections, please let me know.

--

From: Agustin Vega-Frias 

commit 1bc2463cee92ef0e2034c813d5e511adeb58b5fd upstream.

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 changelog ]

Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Agustin Vega-Frias 
Signed-off-by: Thomas Gleixner 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: ti...@codeaurora.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: sta...@vger.kernel.org
Link: 
https://lkml.kernel.org/r/1525184090-26143-1-git-send-email-agust...@codeaurora.org
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/irqchip/qcom-irq-combiner.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
@@ -68,7 +68,7 @@ static void combiner_handle_irq(struct i
 
bit = readl_relaxed(combiner->regs[reg].addr);
status = bit & combiner->regs[reg].enabled;
-   if (!status)
+   if (bit && !status)
pr_warn_ratelimited("Unexpected IRQ on CPU%d: (%08x 
%08lx %p)\n",
smp_processor_id(), bit,
combiner->regs[reg].enabled,




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

2018-05-02 Thread tip-bot for Agustin Vega-Frias
Commit-ID:  1bc2463cee92ef0e2034c813d5e511adeb58b5fd
Gitweb: https://git.kernel.org/tip/1bc2463cee92ef0e2034c813d5e511adeb58b5fd
Author: Agustin Vega-Frias <agust...@codeaurora.org>
AuthorDate: Tue, 1 May 2018 10:14:50 -0400
Committer:  Thomas Gleixner <t...@linutronix.de>
CommitDate: 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 leads to false positive warnings.

[ tglx: Massaged changelog ]

Fixes: f20cc9b00c7b ("irqchip/qcom: Add IRQ combiner driver")
Signed-off-by: Agustin Vega-Frias <agust...@codeaurora.org>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: Jason Cooper <ja...@lakedaemon.net>
Cc: Marc Zyngier <marc.zyng...@arm.com>
Cc: ti...@codeaurora.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: sta...@vger.kernel.org
Link: 
https://lkml.kernel.org/r/1525184090-26143-1-git-send-email-agust...@codeaurora.org

---
 drivers/irqchip/qcom-irq-combiner.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/qcom-irq-combiner.c 
b/drivers/irqchip/qcom-irq-combiner.c
index f31265937439..7f0c0be322e0 100644
--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
@@ -68,7 +68,7 @@ static void combiner_handle_irq(struct irq_desc *desc)
 
bit = readl_relaxed(combiner->regs[reg].addr);
status = bit & combiner->regs[reg].enabled;
-   if (!status)
+   if (bit && !status)
pr_warn_ratelimited("Unexpected IRQ on CPU%d: (%08x 
%08lx %p)\n",
smp_processor_id(), bit,
combiner->regs[reg].enabled,


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

2018-05-02 Thread tip-bot for Agustin Vega-Frias
Commit-ID:  1bc2463cee92ef0e2034c813d5e511adeb58b5fd
Gitweb: https://git.kernel.org/tip/1bc2463cee92ef0e2034c813d5e511adeb58b5fd
Author: Agustin Vega-Frias 
AuthorDate: Tue, 1 May 2018 10:14:50 -0400
Committer:  Thomas Gleixner 
CommitDate: 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 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 
Cc: Jason Cooper 
Cc: Marc Zyngier 
Cc: ti...@codeaurora.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: sta...@vger.kernel.org
Link: 
https://lkml.kernel.org/r/1525184090-26143-1-git-send-email-agust...@codeaurora.org

---
 drivers/irqchip/qcom-irq-combiner.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/qcom-irq-combiner.c 
b/drivers/irqchip/qcom-irq-combiner.c
index f31265937439..7f0c0be322e0 100644
--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
@@ -68,7 +68,7 @@ static void combiner_handle_irq(struct irq_desc *desc)
 
bit = readl_relaxed(combiner->regs[reg].addr);
status = bit & combiner->regs[reg].enabled;
-   if (!status)
+   if (bit && !status)
pr_warn_ratelimited("Unexpected IRQ on CPU%d: (%08x 
%08lx %p)\n",
smp_processor_id(), bit,
combiner->regs[reg].enabled,


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

2018-05-01 Thread Agustin Vega-Frias
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 changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/qcom-irq-combiner.c 
b/drivers/irqchip/qcom-irq-combiner.c
index f312659..7f0c0be 100644
--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
@@ -68,7 +68,7 @@ static void combiner_handle_irq(struct irq_desc *desc)
 
bit = readl_relaxed(combiner->regs[reg].addr);
status = bit & combiner->regs[reg].enabled;
-   if (!status)
+   if (bit && !status)
pr_warn_ratelimited("Unexpected IRQ on CPU%d: (%08x 
%08lx %p)\n",
smp_processor_id(), bit,
combiner->regs[reg].enabled,
-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.



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

2018-05-01 Thread Agustin Vega-Frias
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 deletions(-)

diff --git a/drivers/irqchip/qcom-irq-combiner.c 
b/drivers/irqchip/qcom-irq-combiner.c
index f312659..7f0c0be 100644
--- a/drivers/irqchip/qcom-irq-combiner.c
+++ b/drivers/irqchip/qcom-irq-combiner.c
@@ -1,4 +1,4 @@
-/* Copyright (c) 2015-2016, The Linux Foundation. All rights reserved.
+/* Copyright (c) 2015-2018, The Linux Foundation. All rights reserved.
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 and
@@ -68,7 +68,7 @@ static void combiner_handle_irq(struct irq_desc *desc)
 
bit = readl_relaxed(combiner->regs[reg].addr);
status = bit & combiner->regs[reg].enabled;
-   if (!status)
+   if (bit && !status)
pr_warn_ratelimited("Unexpected IRQ on CPU%d: (%08x 
%08lx %p)\n",
smp_processor_id(), bit,
combiner->regs[reg].enabled,
-- 
Qualcomm Datacenter Technologies, Inc. on behalf of the Qualcomm Technologies, 
Inc.
Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux 
Foundation Collaborative Project.



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

2018-04-27 Thread Thierry Reding
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. This would happen only in a case of a very severe bug.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/memory/tegra/mc.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature


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

2018-04-27 Thread Thierry Reding
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. This would happen only in a case of a very severe bug.
> 
> Signed-off-by: Dmitry Osipenko 
> ---
>  drivers/memory/tegra/mc.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

Applied, thanks.

Thierry


signature.asc
Description: PGP signature


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

2018-04-09 Thread Dmitry Osipenko
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: Dmitry Osipenko 
---
 drivers/memory/tegra/mc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index a4803ac192bb..d2005b995821 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -252,8 +252,11 @@ static irqreturn_t tegra_mc_irq(int irq, void *data)
unsigned int bit;
 
/* mask all interrupts to avoid flooding */
-   status = mc_readl(mc, MC_INTSTATUS);
mask = mc_readl(mc, MC_INTMASK);
+   status = mc_readl(mc, MC_INTSTATUS) & mask;
+
+   if (!status)
+   return IRQ_NONE;
 
for_each_set_bit(bit, , 32) {
const char *error = status_names[bit] ?: "unknown";
-- 
2.16.3



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

2018-04-09 Thread Dmitry Osipenko
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: Dmitry Osipenko 
---
 drivers/memory/tegra/mc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index a4803ac192bb..d2005b995821 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -252,8 +252,11 @@ static irqreturn_t tegra_mc_irq(int irq, void *data)
unsigned int bit;
 
/* mask all interrupts to avoid flooding */
-   status = mc_readl(mc, MC_INTSTATUS);
mask = mc_readl(mc, MC_INTMASK);
+   status = mc_readl(mc, MC_INTSTATUS) & mask;
+
+   if (!status)
+   return IRQ_NONE;
 
for_each_set_bit(bit, , 32) {
const char *error = status_names[bit] ?: "unknown";
-- 
2.16.3



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

2018-03-17 Thread Dmitry Osipenko
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 a/drivers/staging/media/tegra-vde/tegra-vde.c 
b/drivers/staging/media/tegra-vde/tegra-vde.c
index 94b4db55cdb5..9e542c6288f1 100644
--- a/drivers/staging/media/tegra-vde/tegra-vde.c
+++ b/drivers/staging/media/tegra-vde/tegra-vde.c
@@ -935,6 +935,9 @@ static irqreturn_t tegra_vde_isr(int irq, void *data)
 {
struct tegra_vde *vde = data;
 
+   if (completion_done(>decode_completion))
+   return IRQ_NONE;
+
tegra_vde_set_bits(vde, 0, vde->frameid + 0x208);
complete(>decode_completion);
 
-- 
2.16.1



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

2018-03-17 Thread Dmitry Osipenko
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 a/drivers/staging/media/tegra-vde/tegra-vde.c 
b/drivers/staging/media/tegra-vde/tegra-vde.c
index 94b4db55cdb5..9e542c6288f1 100644
--- a/drivers/staging/media/tegra-vde/tegra-vde.c
+++ b/drivers/staging/media/tegra-vde/tegra-vde.c
@@ -935,6 +935,9 @@ static irqreturn_t tegra_vde_isr(int irq, void *data)
 {
struct tegra_vde *vde = data;
 
+   if (completion_done(>decode_completion))
+   return IRQ_NONE;
+
tegra_vde_set_bits(vde, 0, vde->frameid + 0x208);
complete(>decode_completion);
 
-- 
2.16.1



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

2018-02-20 Thread Dmitry Osipenko
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: Dmitry Osipenko 
---
 drivers/memory/tegra/mc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index a4803ac192bb..d2005b995821 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -252,8 +252,11 @@ static irqreturn_t tegra_mc_irq(int irq, void *data)
unsigned int bit;
 
/* mask all interrupts to avoid flooding */
-   status = mc_readl(mc, MC_INTSTATUS);
mask = mc_readl(mc, MC_INTMASK);
+   status = mc_readl(mc, MC_INTSTATUS) & mask;
+
+   if (!status)
+   return IRQ_NONE;
 
for_each_set_bit(bit, , 32) {
const char *error = status_names[bit] ?: "unknown";
-- 
2.16.1



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

2018-02-20 Thread Dmitry Osipenko
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: Dmitry Osipenko 
---
 drivers/memory/tegra/mc.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/memory/tegra/mc.c b/drivers/memory/tegra/mc.c
index a4803ac192bb..d2005b995821 100644
--- a/drivers/memory/tegra/mc.c
+++ b/drivers/memory/tegra/mc.c
@@ -252,8 +252,11 @@ static irqreturn_t tegra_mc_irq(int irq, void *data)
unsigned int bit;
 
/* mask all interrupts to avoid flooding */
-   status = mc_readl(mc, MC_INTSTATUS);
mask = mc_readl(mc, MC_INTMASK);
+   status = mc_readl(mc, MC_INTSTATUS) & mask;
+
+   if (!status)
+   return IRQ_NONE;
 
for_each_set_bit(bit, , 32) {
const char *error = status_names[bit] ?: "unknown";
-- 
2.16.1



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

2017-10-24 Thread Greg Kroah-Hartman
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 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 for detached
state. If the interrupt hits while the device is in detached state it
passes the safe guard and dereferences the event handler call back which is
NULL.

Add the missing state check.

Fixes: 8f9327cbb6e8 ("clockevents/drivers/cs5535: Migrate to new 'set-state' 
interface")
Suggested-by: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: David Kozub <z...@linux.fjfi.cvut.cz>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: Daniel Lezcano <daniel.lezc...@linaro.org>
Link: https://lkml.kernel.org/r/20171020093103.3317f60...@linux.fjfi.cvut.cz
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 drivers/clocksource/cs5535-clockevt.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/clocksource/cs5535-clockevt.c
+++ b/drivers/clocksource/cs5535-clockevt.c
@@ -117,7 +117,8 @@ static irqreturn_t mfgpt_tick(int irq, v
/* Turn off the clock (and clear the event) */
disable_timer(cs5535_event_clock);
 
-   if (clockevent_state_shutdown(_clockevent))
+   if (clockevent_state_detached(_clockevent) ||
+   clockevent_state_shutdown(_clockevent))
return IRQ_HANDLED;
 
/* Clear the counter */




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

2017-10-24 Thread Greg Kroah-Hartman
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 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 for detached
state. If the interrupt hits while the device is in detached state it
passes the safe guard and dereferences the event handler call back which is
NULL.

Add the missing state check.

Fixes: 8f9327cbb6e8 ("clockevents/drivers/cs5535: Migrate to new 'set-state' 
interface")
Suggested-by: Thomas Gleixner 
Signed-off-by: David Kozub 
Signed-off-by: Thomas Gleixner 
Cc: Daniel Lezcano 
Link: https://lkml.kernel.org/r/20171020093103.3317f60...@linux.fjfi.cvut.cz
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/clocksource/cs5535-clockevt.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/clocksource/cs5535-clockevt.c
+++ b/drivers/clocksource/cs5535-clockevt.c
@@ -117,7 +117,8 @@ static irqreturn_t mfgpt_tick(int irq, v
/* Turn off the clock (and clear the event) */
disable_timer(cs5535_event_clock);
 
-   if (clockevent_state_shutdown(_clockevent))
+   if (clockevent_state_detached(_clockevent) ||
+   clockevent_state_shutdown(_clockevent))
return IRQ_HANDLED;
 
/* Clear the counter */




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

2017-10-24 Thread Greg Kroah-Hartman
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 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 for detached
state. If the interrupt hits while the device is in detached state it
passes the safe guard and dereferences the event handler call back which is
NULL.

Add the missing state check.

Fixes: 8f9327cbb6e8 ("clockevents/drivers/cs5535: Migrate to new 'set-state' 
interface")
Suggested-by: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: David Kozub <z...@linux.fjfi.cvut.cz>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: Daniel Lezcano <daniel.lezc...@linaro.org>
Link: https://lkml.kernel.org/r/20171020093103.3317f60...@linux.fjfi.cvut.cz
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 drivers/clocksource/cs5535-clockevt.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/clocksource/cs5535-clockevt.c
+++ b/drivers/clocksource/cs5535-clockevt.c
@@ -117,7 +117,8 @@ static irqreturn_t mfgpt_tick(int irq, v
/* Turn off the clock (and clear the event) */
disable_timer(cs5535_event_clock);
 
-   if (clockevent_state_shutdown(_clockevent))
+   if (clockevent_state_detached(_clockevent) ||
+   clockevent_state_shutdown(_clockevent))
return IRQ_HANDLED;
 
/* Clear the counter */




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

2017-10-24 Thread Greg Kroah-Hartman
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 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 for detached
state. If the interrupt hits while the device is in detached state it
passes the safe guard and dereferences the event handler call back which is
NULL.

Add the missing state check.

Fixes: 8f9327cbb6e8 ("clockevents/drivers/cs5535: Migrate to new 'set-state' 
interface")
Suggested-by: Thomas Gleixner 
Signed-off-by: David Kozub 
Signed-off-by: Thomas Gleixner 
Cc: Daniel Lezcano 
Link: https://lkml.kernel.org/r/20171020093103.3317f60...@linux.fjfi.cvut.cz
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/clocksource/cs5535-clockevt.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/clocksource/cs5535-clockevt.c
+++ b/drivers/clocksource/cs5535-clockevt.c
@@ -117,7 +117,8 @@ static irqreturn_t mfgpt_tick(int irq, v
/* Turn off the clock (and clear the event) */
disable_timer(cs5535_event_clock);
 
-   if (clockevent_state_shutdown(_clockevent))
+   if (clockevent_state_detached(_clockevent) ||
+   clockevent_state_shutdown(_clockevent))
return IRQ_HANDLED;
 
/* Clear the counter */




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

2017-10-24 Thread Greg Kroah-Hartman
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 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 for detached
state. If the interrupt hits while the device is in detached state it
passes the safe guard and dereferences the event handler call back which is
NULL.

Add the missing state check.

Fixes: 8f9327cbb6e8 ("clockevents/drivers/cs5535: Migrate to new 'set-state' 
interface")
Suggested-by: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: David Kozub <z...@linux.fjfi.cvut.cz>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: Daniel Lezcano <daniel.lezc...@linaro.org>
Link: https://lkml.kernel.org/r/20171020093103.3317f60...@linux.fjfi.cvut.cz
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>

---
 drivers/clocksource/cs5535-clockevt.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/clocksource/cs5535-clockevt.c
+++ b/drivers/clocksource/cs5535-clockevt.c
@@ -117,7 +117,8 @@ static irqreturn_t mfgpt_tick(int irq, v
/* Turn off the clock (and clear the event) */
disable_timer(cs5535_event_clock);
 
-   if (clockevent_state_shutdown(_clockevent))
+   if (clockevent_state_detached(_clockevent) ||
+   clockevent_state_shutdown(_clockevent))
return IRQ_HANDLED;
 
/* Clear the counter */




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

2017-10-24 Thread Greg Kroah-Hartman
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 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 for detached
state. If the interrupt hits while the device is in detached state it
passes the safe guard and dereferences the event handler call back which is
NULL.

Add the missing state check.

Fixes: 8f9327cbb6e8 ("clockevents/drivers/cs5535: Migrate to new 'set-state' 
interface")
Suggested-by: Thomas Gleixner 
Signed-off-by: David Kozub 
Signed-off-by: Thomas Gleixner 
Cc: Daniel Lezcano 
Link: https://lkml.kernel.org/r/20171020093103.3317f60...@linux.fjfi.cvut.cz
Signed-off-by: Greg Kroah-Hartman 

---
 drivers/clocksource/cs5535-clockevt.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/clocksource/cs5535-clockevt.c
+++ b/drivers/clocksource/cs5535-clockevt.c
@@ -117,7 +117,8 @@ static irqreturn_t mfgpt_tick(int irq, v
/* Turn off the clock (and clear the event) */
disable_timer(cs5535_event_clock);
 
-   if (clockevent_state_shutdown(_clockevent))
+   if (clockevent_state_detached(_clockevent) ||
+   clockevent_state_shutdown(_clockevent))
return IRQ_HANDLED;
 
/* Clear the counter */




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

2017-10-20 Thread David Kozub

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 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 
Signed-off-by: David Kozub 
---


Thank for sending this fix.

Can you check if the commit 8f9327cbb is the one introducing 

the

regression ? So we can add the proper tags and propagate the fix to
stable.


No it's not.

-   if (cs5535_tick_mode == CLOCK_EVT_MODE_SHUTDOWN)
+   if (clockevent_state_shutdown(_clockevent))

This particular problem of the missing detached state check has been
there
forever and went unnoticed for whatever reason.


The detached condition was artificially caught by the initialized
variable:

-static unsigned int cs5535_tick_mode = CLOCK_EVT_MODE_SHUTDOWN;

The patch 8f9327cbb removes the variable, so very likely this is where
the problem appeared.


I will try to test that. But I won't have access to the device till
Sunday evening. I've had big trouble trying to run kernels > 4.1-rc5 on
the device and if I'm looking correctly the commit was introduced in
4.3-rc1. But I'll try to figure something out.


David,

thanks again for taking the time to report and investigate this issue.
Usually people just give up and drop the legacy hardware without letting
us know the kernel is broken with it. So don't spend too much time with
it, just check if the commit before works, if not, just add in the log
the kernel version you noticed the breakage.

In case you are interested in doing some debugging to narrow down the
offending commit and you know the versions working and not working, you
can try the command git-bisect. It will use a dichotomy approach to find
out the culprit.


Hi Daniel,

I originally didn't see this issue simply because 4.1-rc7 would not output 
anything on the serial on the device. For kernels >= 4.1-rc7 the kernel 
either reboots immediatelly or freezes, in both cases without giving any 
output in the serial. I tried to find the cause of this with git bisect 
but in the end I was none the wiser. I also suspected my build 
environment.


Eventually I found out the following:
* 4.1-rc6 boots OK
* 4.1-rc7 restarts immediatelly, but if I revert f18c34e48 it works but I 
have no idea why would this commit break anything, the commit looks OK

* 4.1 - works if I revert f18c34e48
* e75c73ad6 feeezes even after reverting f18c34e48
* 4.2-rc1 - reboots, even after reverting f18c34e48

Only recently I tried a current kernel and I was more lucky: it gave me 
some useful output on the serial.


To verify 8f9327cbb I was thinking I could take it and apply it onto 
4.1-rc6 (if that was possible), but as Thomas suggested it might not be 
worth it, then I forget about that.


Thanks for all the help to you and to Thomas.

Best regards,
David

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

2017-10-20 Thread David Kozub

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 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 
Signed-off-by: David Kozub 
---


Thank for sending this fix.

Can you check if the commit 8f9327cbb is the one introducing 

the

regression ? So we can add the proper tags and propagate the fix to
stable.


No it's not.

-   if (cs5535_tick_mode == CLOCK_EVT_MODE_SHUTDOWN)
+   if (clockevent_state_shutdown(_clockevent))

This particular problem of the missing detached state check has been
there
forever and went unnoticed for whatever reason.


The detached condition was artificially caught by the initialized
variable:

-static unsigned int cs5535_tick_mode = CLOCK_EVT_MODE_SHUTDOWN;

The patch 8f9327cbb removes the variable, so very likely this is where
the problem appeared.


I will try to test that. But I won't have access to the device till
Sunday evening. I've had big trouble trying to run kernels > 4.1-rc5 on
the device and if I'm looking correctly the commit was introduced in
4.3-rc1. But I'll try to figure something out.


David,

thanks again for taking the time to report and investigate this issue.
Usually people just give up and drop the legacy hardware without letting
us know the kernel is broken with it. So don't spend too much time with
it, just check if the commit before works, if not, just add in the log
the kernel version you noticed the breakage.

In case you are interested in doing some debugging to narrow down the
offending commit and you know the versions working and not working, you
can try the command git-bisect. It will use a dichotomy approach to find
out the culprit.


Hi Daniel,

I originally didn't see this issue simply because 4.1-rc7 would not output 
anything on the serial on the device. For kernels >= 4.1-rc7 the kernel 
either reboots immediatelly or freezes, in both cases without giving any 
output in the serial. I tried to find the cause of this with git bisect 
but in the end I was none the wiser. I also suspected my build 
environment.


Eventually I found out the following:
* 4.1-rc6 boots OK
* 4.1-rc7 restarts immediatelly, but if I revert f18c34e48 it works but I 
have no idea why would this commit break anything, the commit looks OK

* 4.1 - works if I revert f18c34e48
* e75c73ad6 feeezes even after reverting f18c34e48
* 4.2-rc1 - reboots, even after reverting f18c34e48

Only recently I tried a current kernel and I was more lucky: it gave me 
some useful output on the serial.


To verify 8f9327cbb I was thinking I could take it and apply it onto 
4.1-rc6 (if that was possible), but as Thomas suggested it might not be 
worth it, then I forget about that.


Thanks for all the help to you and to Thomas.

Best regards,
David

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

2017-10-20 Thread tip-bot for David Kozub
Commit-ID:  eb39a7c0355393c5a8d930f342ad7a6231b552c4
Gitweb: https://git.kernel.org/tip/eb39a7c0355393c5a8d930f342ad7a6231b552c4
Author: David Kozub <z...@linux.fjfi.cvut.cz>
AuthorDate: Thu, 19 Oct 2017 22:57:02 +0200
Committer:  Thomas Gleixner <t...@linutronix.de>
CommitDate: 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 guard against spurious interrupts solely checks
for the clockevents shutdown state, but lacks a check for detached
state. If the interrupt hits while the device is in detached state it
passes the safe guard and dereferences the event handler call back which is
NULL.

Add the missing state check.

Fixes: 8f9327cbb6e8 ("clockevents/drivers/cs5535: Migrate to new 'set-state' 
interface")
Suggested-by: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: David Kozub <z...@linux.fjfi.cvut.cz>
Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Cc: Daniel Lezcano <daniel.lezc...@linaro.org>
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/20171020093103.3317f60...@linux.fjfi.cvut.cz

---
 drivers/clocksource/cs5535-clockevt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/cs5535-clockevt.c 
b/drivers/clocksource/cs5535-clockevt.c
index a1df588..1de8cac 100644
--- a/drivers/clocksource/cs5535-clockevt.c
+++ b/drivers/clocksource/cs5535-clockevt.c
@@ -117,7 +117,8 @@ static irqreturn_t mfgpt_tick(int irq, void *dev_id)
/* Turn off the clock (and clear the event) */
disable_timer(cs5535_event_clock);
 
-   if (clockevent_state_shutdown(_clockevent))
+   if (clockevent_state_detached(_clockevent) ||
+   clockevent_state_shutdown(_clockevent))
return IRQ_HANDLED;
 
/* Clear the counter */


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

2017-10-20 Thread tip-bot for David Kozub
Commit-ID:  eb39a7c0355393c5a8d930f342ad7a6231b552c4
Gitweb: https://git.kernel.org/tip/eb39a7c0355393c5a8d930f342ad7a6231b552c4
Author: David Kozub 
AuthorDate: Thu, 19 Oct 2017 22:57:02 +0200
Committer:  Thomas Gleixner 
CommitDate: 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 guard against spurious interrupts solely checks
for the clockevents shutdown state, but lacks a check for detached
state. If the interrupt hits while the device is in detached state it
passes the safe guard and dereferences the event handler call back which is
NULL.

Add the missing state check.

Fixes: 8f9327cbb6e8 ("clockevents/drivers/cs5535: Migrate to new 'set-state' 
interface")
Suggested-by: Thomas Gleixner 
Signed-off-by: David Kozub 
Signed-off-by: Thomas Gleixner 
Cc: Daniel Lezcano 
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/20171020093103.3317f60...@linux.fjfi.cvut.cz

---
 drivers/clocksource/cs5535-clockevt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/cs5535-clockevt.c 
b/drivers/clocksource/cs5535-clockevt.c
index a1df588..1de8cac 100644
--- a/drivers/clocksource/cs5535-clockevt.c
+++ b/drivers/clocksource/cs5535-clockevt.c
@@ -117,7 +117,8 @@ static irqreturn_t mfgpt_tick(int irq, void *dev_id)
/* Turn off the clock (and clear the event) */
disable_timer(cs5535_event_clock);
 
-   if (clockevent_state_shutdown(_clockevent))
+   if (clockevent_state_detached(_clockevent) ||
+   clockevent_state_shutdown(_clockevent))
return IRQ_HANDLED;
 
/* Clear the counter */


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

2017-10-20 Thread Daniel Lezcano
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 particular issue. We already
> know that the commit which made the spurious detection weaker. So we just
> add that as Fixes tag and be done with it.

Yes, I'm fine with that.



-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog



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

2017-10-20 Thread Daniel Lezcano
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 particular issue. We already
> know that the commit which made the spurious detection weaker. So we just
> add that as Fixes tag and be done with it.

Yes, I'm fine with that.



-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog



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

2017-10-20 Thread Thomas Gleixner
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 made the spurious detection weaker. So we just
add that as Fixes tag and be done with it.

Thanks,

tglx





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

2017-10-20 Thread Thomas Gleixner
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 made the spurious detection weaker. So we just
add that as Fixes tag and be done with it.

Thanks,

tglx





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

2017-10-20 Thread Daniel Lezcano
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 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 
> Signed-off-by: David Kozub 
> ---

 Thank for sending this fix.

 Can you check if the commit 8f9327cbb is the one introducing the
 regression ? So we can add the proper tags and propagate the fix to
 stable.
>>>
>>> No it's not.
>>>
>>> -   if (cs5535_tick_mode == CLOCK_EVT_MODE_SHUTDOWN)
>>> +   if (clockevent_state_shutdown(_clockevent))
>>>
>>> This particular problem of the missing detached state check has been
>>> there
>>> forever and went unnoticed for whatever reason.
>>
>> The detached condition was artificially caught by the initialized
>> variable:
>>
>> -static unsigned int cs5535_tick_mode = CLOCK_EVT_MODE_SHUTDOWN;
>>
>> The patch 8f9327cbb removes the variable, so very likely this is where
>> the problem appeared.
> 
> I will try to test that. But I won't have access to the device till
> Sunday evening. I've had big trouble trying to run kernels > 4.1-rc5 on
> the device and if I'm looking correctly the commit was introduced in
> 4.3-rc1. But I'll try to figure something out.

David,

thanks again for taking the time to report and investigate this issue.
Usually people just give up and drop the legacy hardware without letting
us know the kernel is broken with it. So don't spend too much time with
it, just check if the commit before works, if not, just add in the log
the kernel version you noticed the breakage.

In case you are interested in doing some debugging to narrow down the
offending commit and you know the versions working and not working, you
can try the command git-bisect. It will use a dichotomy approach to find
out the culprit.

For example:
Let's say you have v4.1-rc5 working and v4.1-rc6 not working and in
between there are 1024 changes. The dichotomy approach will find out the
patch introducing the regression in ln(1024)/ln(2) = 10 iterations.

It's usage is:

git bisect start v4.1-rc6 v4.1-rc5 (bad goes always first)
make && test (the test is ok)
git bisect good
make && test (the test is ok)
git bisect good
make && test (the test fails)
git bisect bad
...

...

And it ends up to the bad commit (assuming there are no compilation
broken patches in the process).

Once it is finished, use git bisect reset

  -- Daniel

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog



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

2017-10-20 Thread Daniel Lezcano
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 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 
> Signed-off-by: David Kozub 
> ---

 Thank for sending this fix.

 Can you check if the commit 8f9327cbb is the one introducing the
 regression ? So we can add the proper tags and propagate the fix to
 stable.
>>>
>>> No it's not.
>>>
>>> -   if (cs5535_tick_mode == CLOCK_EVT_MODE_SHUTDOWN)
>>> +   if (clockevent_state_shutdown(_clockevent))
>>>
>>> This particular problem of the missing detached state check has been
>>> there
>>> forever and went unnoticed for whatever reason.
>>
>> The detached condition was artificially caught by the initialized
>> variable:
>>
>> -static unsigned int cs5535_tick_mode = CLOCK_EVT_MODE_SHUTDOWN;
>>
>> The patch 8f9327cbb removes the variable, so very likely this is where
>> the problem appeared.
> 
> I will try to test that. But I won't have access to the device till
> Sunday evening. I've had big trouble trying to run kernels > 4.1-rc5 on
> the device and if I'm looking correctly the commit was introduced in
> 4.3-rc1. But I'll try to figure something out.

David,

thanks again for taking the time to report and investigate this issue.
Usually people just give up and drop the legacy hardware without letting
us know the kernel is broken with it. So don't spend too much time with
it, just check if the commit before works, if not, just add in the log
the kernel version you noticed the breakage.

In case you are interested in doing some debugging to narrow down the
offending commit and you know the versions working and not working, you
can try the command git-bisect. It will use a dichotomy approach to find
out the culprit.

For example:
Let's say you have v4.1-rc5 working and v4.1-rc6 not working and in
between there are 1024 changes. The dichotomy approach will find out the
patch introducing the regression in ln(1024)/ln(2) = 10 iterations.

It's usage is:

git bisect start v4.1-rc6 v4.1-rc5 (bad goes always first)
make && test (the test is ok)
git bisect good
make && test (the test is ok)
git bisect good
make && test (the test fails)
git bisect bad
...

...

And it ends up to the bad commit (assuming there are no compilation
broken patches in the process).

Once it is finished, use git bisect reset

  -- Daniel

-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog



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

2017-10-20 Thread David Kozub
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 for
detached state. If the interrupt hits while the device is in detached
state it passes the safe guard and dereferences the event handler call
back which is NULL.

Add the missing state check.

Suggested-by: Thomas Gleixner <t...@linutronix.de>
Signed-off-by: David Kozub <z...@linux.fjfi.cvut.cz>
---
Changes in v2:
  - Use commit message suggested by Thomas Gleixner
  - Fix formatting of multi-line if condition

 drivers/clocksource/cs5535-clockevt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/cs5535-clockevt.c 
b/drivers/clocksource/cs5535-clockevt.c
index a1df588343f2..1de8cac99a0e 100644
--- a/drivers/clocksource/cs5535-clockevt.c
+++ b/drivers/clocksource/cs5535-clockevt.c
@@ -117,7 +117,8 @@ static irqreturn_t mfgpt_tick(int irq, void *dev_id)
/* Turn off the clock (and clear the event) */
disable_timer(cs5535_event_clock);
 
-   if (clockevent_state_shutdown(_clockevent))
+   if (clockevent_state_detached(_clockevent) ||
+   clockevent_state_shutdown(_clockevent))
return IRQ_HANDLED;
 
/* Clear the counter */
-- 
2.14.2



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

2017-10-20 Thread David Kozub
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 for
detached state. If the interrupt hits while the device is in detached
state it passes the safe guard and dereferences the event handler call
back which is NULL.

Add the missing state check.

Suggested-by: Thomas Gleixner 
Signed-off-by: David Kozub 
---
Changes in v2:
  - Use commit message suggested by Thomas Gleixner
  - Fix formatting of multi-line if condition

 drivers/clocksource/cs5535-clockevt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/cs5535-clockevt.c 
b/drivers/clocksource/cs5535-clockevt.c
index a1df588343f2..1de8cac99a0e 100644
--- a/drivers/clocksource/cs5535-clockevt.c
+++ b/drivers/clocksource/cs5535-clockevt.c
@@ -117,7 +117,8 @@ static irqreturn_t mfgpt_tick(int irq, void *dev_id)
/* Turn off the clock (and clear the event) */
disable_timer(cs5535_event_clock);
 
-   if (clockevent_state_shutdown(_clockevent))
+   if (clockevent_state_detached(_clockevent) ||
+   clockevent_state_shutdown(_clockevent))
return IRQ_HANDLED;
 
/* Clear the counter */
-- 
2.14.2



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

2017-10-20 Thread Thomas Gleixner
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 analyzing the problem in the first
place.

Thanks,

tglx


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

2017-10-20 Thread Thomas Gleixner
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 analyzing the problem in the first
place.

Thanks,

tglx


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

2017-10-20 Thread David Kozub

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 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 
Signed-off-by: David Kozub 
---


Thank for sending this fix.

Can you check if the commit 8f9327cbb is the one introducing the
regression ? So we can add the proper tags and propagate the fix to stable.


No it's not.

-   if (cs5535_tick_mode == CLOCK_EVT_MODE_SHUTDOWN)
+   if (clockevent_state_shutdown(_clockevent))

This particular problem of the missing detached state check has been there
forever and went unnoticed for whatever reason.


The detached condition was artificially caught by the initialized variable:

-static unsigned int cs5535_tick_mode = CLOCK_EVT_MODE_SHUTDOWN;

The patch 8f9327cbb removes the variable, so very likely this is where
the problem appeared.


I will try to test that. But I won't have access to the device till Sunday 
evening. I've had big trouble trying to run kernels > 4.1-rc5 on the 
device and if I'm looking correctly the commit was introduced in 4.3-rc1. 
But I'll try to figure something out.


Best regards,
David


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

2017-10-20 Thread David Kozub

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 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 
Signed-off-by: David Kozub 
---


Thank for sending this fix.

Can you check if the commit 8f9327cbb is the one introducing the
regression ? So we can add the proper tags and propagate the fix to stable.


No it's not.

-   if (cs5535_tick_mode == CLOCK_EVT_MODE_SHUTDOWN)
+   if (clockevent_state_shutdown(_clockevent))

This particular problem of the missing detached state check has been there
forever and went unnoticed for whatever reason.


The detached condition was artificially caught by the initialized variable:

-static unsigned int cs5535_tick_mode = CLOCK_EVT_MODE_SHUTDOWN;

The patch 8f9327cbb removes the variable, so very likely this is where
the problem appeared.


I will try to test that. But I won't have access to the device till Sunday 
evening. I've had big trouble trying to run kernels > 4.1-rc5 on the 
device and if I'm looking correctly the commit was introduced in 4.3-rc1. 
But I'll try to figure something out.


Best regards,
David


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

2017-10-20 Thread David Kozub

On Fri, 20 Oct 2017, Thomas Gleixner wrote:


On Thu, 19 Oct 2017, 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 suggesting a solution.


Thanks for sending this! Though I have two minor issues with this:

1) The changelog.

We try to structure changelogs by explaining the context, the problem and
its consequences and the fix. If the fix is non obvious it wants an
elaborate 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 shutdown state, but lacks a check for
  detached state. If the interrupt hits while the device is in detached
  state it passes the safe guard and dereferences the event handler call
  back which is NULL.

  Add the missing state check.

See?


Thanks for the feedback. Yes, that is better.

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.



-   if (clockevent_state_shutdown(_clockevent))
+   if (clockevent_state_detached(_clockevent) ||
+   clockevent_state_shutdown(_clockevent))


Please do not use random indentation for multiline conditionals

if (clockevent_state_detached(_clockevent) ||
clockevent_state_shutdown(_clockevent))

is the style we use through out the code.


OK. I noticed the four spaces. I was swayed by process/coding-style.rst:

Outside of comments, documentation and except in Kconfig, spaces are never 
used for indentation,


But now I think I just misunderstood that. The spaces on the second line 
of the "if" are not regarded as ident.



Best regards,
David


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

2017-10-20 Thread David Kozub

On Fri, 20 Oct 2017, Thomas Gleixner wrote:


On Thu, 19 Oct 2017, 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 suggesting a solution.


Thanks for sending this! Though I have two minor issues with this:

1) The changelog.

We try to structure changelogs by explaining the context, the problem and
its consequences and the fix. If the fix is non obvious it wants an
elaborate 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 shutdown state, but lacks a check for
  detached state. If the interrupt hits while the device is in detached
  state it passes the safe guard and dereferences the event handler call
  back which is NULL.

  Add the missing state check.

See?


Thanks for the feedback. Yes, that is better.

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.



-   if (clockevent_state_shutdown(_clockevent))
+   if (clockevent_state_detached(_clockevent) ||
+   clockevent_state_shutdown(_clockevent))


Please do not use random indentation for multiline conditionals

if (clockevent_state_detached(_clockevent) ||
clockevent_state_shutdown(_clockevent))

is the style we use through out the code.


OK. I noticed the four spaces. I was swayed by process/coding-style.rst:

Outside of comments, documentation and except in Kconfig, spaces are never 
used for indentation,


But now I think I just misunderstood that. The spaces on the second line 
of the "if" are not regarded as ident.



Best regards,
David


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

2017-10-20 Thread Daniel Lezcano
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 pointer.
>>>
>>> Thanks to Daniel Lezcano and Thomas Gleixner for helping me analyze this
>>> and suggesting a solution.
>>>
>>> Suggested-by: Thomas Gleixner 
>>> Signed-off-by: David Kozub 
>>> ---
>>
>> Thank for sending this fix.
>>
>> Can you check if the commit 8f9327cbb is the one introducing the
>> regression ? So we can add the proper tags and propagate the fix to stable.
> 
> No it's not.
> 
> -   if (cs5535_tick_mode == CLOCK_EVT_MODE_SHUTDOWN)
> +   if (clockevent_state_shutdown(_clockevent))
> 
> This particular problem of the missing detached state check has been there
> forever and went unnoticed for whatever reason.

The detached condition was artificially caught by the initialized variable:

-static unsigned int cs5535_tick_mode = CLOCK_EVT_MODE_SHUTDOWN;

The patch 8f9327cbb removes the variable, so very likely this is where
the problem appeared.


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog



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

2017-10-20 Thread Daniel Lezcano
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 pointer.
>>>
>>> Thanks to Daniel Lezcano and Thomas Gleixner for helping me analyze this
>>> and suggesting a solution.
>>>
>>> Suggested-by: Thomas Gleixner 
>>> Signed-off-by: David Kozub 
>>> ---
>>
>> Thank for sending this fix.
>>
>> Can you check if the commit 8f9327cbb is the one introducing the
>> regression ? So we can add the proper tags and propagate the fix to stable.
> 
> No it's not.
> 
> -   if (cs5535_tick_mode == CLOCK_EVT_MODE_SHUTDOWN)
> +   if (clockevent_state_shutdown(_clockevent))
> 
> This particular problem of the missing detached state check has been there
> forever and went unnoticed for whatever reason.

The detached condition was artificially caught by the initialized variable:

-static unsigned int cs5535_tick_mode = CLOCK_EVT_MODE_SHUTDOWN;

The patch 8f9327cbb removes the variable, so very likely this is where
the problem appeared.


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog



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

2017-10-19 Thread Thomas Gleixner
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 Thomas Gleixner for helping me analyze this
> > and suggesting a solution.
> > 
> > Suggested-by: Thomas Gleixner 
> > Signed-off-by: David Kozub 
> > ---
> 
> Thank for sending this fix.
> 
> Can you check if the commit 8f9327cbb is the one introducing the
> regression ? So we can add the proper tags and propagate the fix to stable.

No it's not.

-   if (cs5535_tick_mode == CLOCK_EVT_MODE_SHUTDOWN)
+   if (clockevent_state_shutdown(_clockevent))

This particular problem of the missing detached state check has been there
forever and went unnoticed for whatever reason.

Thanks,

tglx


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

2017-10-19 Thread Thomas Gleixner
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 Thomas Gleixner for helping me analyze this
> > and suggesting a solution.
> > 
> > Suggested-by: Thomas Gleixner 
> > Signed-off-by: David Kozub 
> > ---
> 
> Thank for sending this fix.
> 
> Can you check if the commit 8f9327cbb is the one introducing the
> regression ? So we can add the proper tags and propagate the fix to stable.

No it's not.

-   if (cs5535_tick_mode == CLOCK_EVT_MODE_SHUTDOWN)
+   if (clockevent_state_shutdown(_clockevent))

This particular problem of the missing detached state check has been there
forever and went unnoticed for whatever reason.

Thanks,

tglx


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

2017-10-19 Thread Thomas Gleixner
On Thu, 19 Oct 2017, 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 suggesting a solution.

Thanks for sending this! Though I have two minor issues with this:

1) The changelog.

We try to structure changelogs by explaining the context, the problem and
its consequences and the fix. If the fix is non obvious it wants an
elaborate 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 shutdown state, but lacks a check for
   detached state. If the interrupt hits while the device is in detached
   state it passes the safe guard and dereferences the event handler call
   back which is NULL.

   Add the missing state check.

See?


> Suggested-by: Thomas Gleixner <t...@linutronix.de>
> Signed-off-by: David Kozub <z...@linux.fjfi.cvut.cz>
> ---
>  drivers/clocksource/cs5535-clockevt.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clocksource/cs5535-clockevt.c 
> b/drivers/clocksource/cs5535-clockevt.c
> index a1df588343f2..56100506b933 100644
> --- a/drivers/clocksource/cs5535-clockevt.c
> +++ b/drivers/clocksource/cs5535-clockevt.c
> @@ -117,7 +117,8 @@ static irqreturn_t mfgpt_tick(int irq, void *dev_id)
>   /* Turn off the clock (and clear the event) */
>   disable_timer(cs5535_event_clock);
>  
> - if (clockevent_state_shutdown(_clockevent))
> + if (clockevent_state_detached(_clockevent) ||
> + clockevent_state_shutdown(_clockevent))

Please do not use random indentation for multiline conditionals

if (clockevent_state_detached(_clockevent) ||
clockevent_state_shutdown(_clockevent))

is the style we use through out the code.

Thanks,

tglx


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

2017-10-19 Thread Thomas Gleixner
On Thu, 19 Oct 2017, 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 suggesting a solution.

Thanks for sending this! Though I have two minor issues with this:

1) The changelog.

We try to structure changelogs by explaining the context, the problem and
its consequences and the fix. If the fix is non obvious it wants an
elaborate 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 shutdown state, but lacks a check for
   detached state. If the interrupt hits while the device is in detached
   state it passes the safe guard and dereferences the event handler call
   back which is NULL.

   Add the missing state check.

See?


> Suggested-by: Thomas Gleixner 
> Signed-off-by: David Kozub 
> ---
>  drivers/clocksource/cs5535-clockevt.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/clocksource/cs5535-clockevt.c 
> b/drivers/clocksource/cs5535-clockevt.c
> index a1df588343f2..56100506b933 100644
> --- a/drivers/clocksource/cs5535-clockevt.c
> +++ b/drivers/clocksource/cs5535-clockevt.c
> @@ -117,7 +117,8 @@ static irqreturn_t mfgpt_tick(int irq, void *dev_id)
>   /* Turn off the clock (and clear the event) */
>   disable_timer(cs5535_event_clock);
>  
> - if (clockevent_state_shutdown(_clockevent))
> + if (clockevent_state_detached(_clockevent) ||
> + clockevent_state_shutdown(_clockevent))

Please do not use random indentation for multiline conditionals

if (clockevent_state_detached(_clockevent) ||
clockevent_state_shutdown(_clockevent))

is the style we use through out the code.

Thanks,

tglx


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

2017-10-19 Thread Daniel Lezcano
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 suggesting a solution.
> 
> Suggested-by: Thomas Gleixner 
> Signed-off-by: David Kozub 
> ---

Thank for sending this fix.

Can you check if the commit 8f9327cbb is the one introducing the
regression ? So we can add the proper tags and propagate the fix to stable.

Thanks.

 -- Daniel


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog



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

2017-10-19 Thread Daniel Lezcano
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 suggesting a solution.
> 
> Suggested-by: Thomas Gleixner 
> Signed-off-by: David Kozub 
> ---

Thank for sending this fix.

Can you check if the commit 8f9327cbb is the one introducing the
regression ? So we can add the proper tags and propagate the fix to stable.

Thanks.

 -- Daniel


-- 
  Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog



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

2017-10-19 Thread David Kozub
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 
Signed-off-by: David Kozub 
---
 drivers/clocksource/cs5535-clockevt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/cs5535-clockevt.c 
b/drivers/clocksource/cs5535-clockevt.c
index a1df588343f2..56100506b933 100644
--- a/drivers/clocksource/cs5535-clockevt.c
+++ b/drivers/clocksource/cs5535-clockevt.c
@@ -117,7 +117,8 @@ static irqreturn_t mfgpt_tick(int irq, void *dev_id)
/* Turn off the clock (and clear the event) */
disable_timer(cs5535_event_clock);
 
-   if (clockevent_state_shutdown(_clockevent))
+   if (clockevent_state_detached(_clockevent) ||
+   clockevent_state_shutdown(_clockevent))
return IRQ_HANDLED;
 
/* Clear the counter */
-- 
2.14.2



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

2017-10-19 Thread David Kozub
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 
Signed-off-by: David Kozub 
---
 drivers/clocksource/cs5535-clockevt.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/cs5535-clockevt.c 
b/drivers/clocksource/cs5535-clockevt.c
index a1df588343f2..56100506b933 100644
--- a/drivers/clocksource/cs5535-clockevt.c
+++ b/drivers/clocksource/cs5535-clockevt.c
@@ -117,7 +117,8 @@ static irqreturn_t mfgpt_tick(int irq, void *dev_id)
/* Turn off the clock (and clear the event) */
disable_timer(cs5535_event_clock);
 
-   if (clockevent_state_shutdown(_clockevent))
+   if (clockevent_state_detached(_clockevent) ||
+   clockevent_state_shutdown(_clockevent))
return IRQ_HANDLED;
 
/* Clear the counter */
-- 
2.14.2



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

2017-03-13 Thread Florian Fainelli
On 03/13/2017 05:41 PM, Doug Berger wrote:
> 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 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

2017-03-13 Thread Florian Fainelli
On 03/13/2017 05:41 PM, Doug Berger wrote:
> 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 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

2017-03-13 Thread Doug Berger
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 is unmasked at a later time.

Signed-off-by: Doug Berger <open...@gmail.com>
---
 drivers/net/ethernet/broadcom/genet/bcmgenet.c | 21 -
 1 file changed, 20 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/broadcom/genet/bcmgenet.c 
b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
index 661ca1b39c89..1f94ba1773dd 100644
--- a/drivers/net/ethernet/broadcom/genet/bcmgenet.c
+++ b/drivers/net/ethernet/broadcom/genet/bcmgenet.c
@@ -1174,6 +1174,14 @@ static unsigned int __bcmgenet_tx_reclaim(struct 
net_device *dev,
unsigned int txbds_ready;
unsigned int txbds_processed = 0;
 
+   /* Clear status before servicing to reduce spurious interrupts */
+   if (ring->index == DESC_INDEX)
+   bcmgenet_intrl2_0_writel(priv, UMAC_IRQ_TXDMA_DONE,
+INTRL2_CPU_CLEAR);
+   else
+   bcmgenet_intrl2_1_writel(priv, (1 << ring->index),
+INTRL2_CPU_CLEAR);
+
/* Compute how many buffers are transmitted since last xmit call */
c_index = bcmgenet_tdma_ring_readl(priv, ring->index, TDMA_CONS_INDEX)
& DMA_C_INDEX_MASK;
@@ -1584,10 +1592,21 @@ static unsigned int bcmgenet_desc_rx(struct 
bcmgenet_rx_ring *ring,
unsigned long dma_flag;
int len;
unsigned int rxpktprocessed = 0, rxpkttoprocess;
-   unsigned int p_index;
+   unsigned int p_index, mask;
unsigned int discards;
unsigned int chksum_ok = 0;
 
+   /* Clear status before servicing to reduce spurious interrupts */
+   if (ring->index == DESC_INDEX) {
+   bcmgenet_intrl2_0_writel(priv, UMAC_IRQ_RXDMA_DONE,
+INTRL2_CPU_CLEAR);
+   } else {
+   mask = 1 << (UMAC_IRQ1_RX_INTR_SHIFT + ring->index);
+   bcmgenet_intrl2_1_writel(priv,
+mask,
+INTRL2_CPU_CLEAR);
+   }
+
p_index = bcmgenet_rdma_ring_readl(priv, ring->index, RDMA_PROD_INDEX);
 
discards = (p_index >> DMA_P_INDEX_DISCARD_CNT_SHIFT) &
-- 
2.11.1



  1   2   3   >