TI-Davinci 6446 oops on interrupts

Commit Message

Holger Freyther June 10, 2011, 6:47 p.m. UTC

On 06/06/2011 05:25 PM, Thomas Gleixner wrote:
> On Mon, 6 Jun 2011, Holger Freyther wrote:
>> On 06/06/2011 04:54 PM, Thomas Gleixner wrote:
>>
>> and both interrupts should be on REG1.. so for IRQ56 it looks like this method
>> is entered with bogus data. Again, I have no idea about the underlying code,
>> but could there be an issue with chained irq and the GC IRC code?
> 
> Crap, yes. The code which does the chained handler setup overwrites
> chip_data.


Hi Thomas,

I think the for loop above the one that was patched has the same kind of issue
(changing the irq_chip_data)? One needs to have a dm365.c for this code to
become active though.

In general what do you think about a patch like the one below, it is at least
boot tested on a qemu-system-i386.

From 8db6d163de33f41d0d9118b8207b8bd1e13c262d Mon Sep 17 00:00:00 2001
From: Holger Hans Peter Freyther <[e-mail]>
Date: Fri, 10 Jun 2011 20:38:43 +0200
Subject: [PATCH] irq: Check if someone is overwriting the irq chip data

This tries to establish the semantic that one can either
set the chip data to NULL or if it is NULL to some value
but never overwrite a non NULL value.

Signed-off-by: Holger Hans Peter Freyther <[e-mail]>
---
 kernel/irq/chip.c |    4 ++++
 1 files changed, 4 insertions(+), 0 deletions(-)

Patch

diff --git a/kernel/irq/chip.c b/kernel/irq/chip.c
index d5a3009..25e446d 100644
--- a/kernel/irq/chip.c
+++ b/kernel/irq/chip.c
@@ -123,6 +123,10 @@  int irq_set_chip_data(unsigned int irq, void *data)

 	if (!desc)
 		return -EINVAL;
+
+	BUG_ON(data && desc->irq_data.chip_data &&
+		data != desc->irq_data.chip_data);
+
 	desc->irq_data.chip_data = data;
 	irq_put_desc_unlock(desc, flags);
 	return 0;