Hi Tony, On Tue, Aug 04, 2009 at 01:51:00PM +0300, Tony Lindgren wrote: > * Russell King <rmk@xxxxxxxxxxxxxxxx> [090803 20:26]: > > On Mon, Aug 03, 2009 at 06:36:12PM +0200, Samuel Ortiz wrote: > > > Hi Santosh, > > > > > > On Mon, Jul 27, 2009 at 11:30:48AM +0530, Santosh Shilimkar wrote: > > > > From: Russell King <rmk+kernel@xxxxxxxxxxxxxxxx> > > > > > > > > (Rebased on 2.6.31-rc4) > > > > > > > > The TWL4030 IRQ handler has a bug which leads to spinlock lock-up. It is > > > > calling the 'unmask' function in a process context. :The mask/unmask/ack > > > > functions are only designed to be called from the IRQ handler code, > > > > or the proper API interfaces found in linux/interrupt.h. > > > > > > > > Also there is no need to have IRQ chaining mechanism. The right way to > > > > handle this is to claim the parent interrupt as a standard interrupt > > > > and arrange for handle_twl4030_pih to take care of the rest of the devices. > > > I'd like this one to be split in 2 different patches as you're addressing 2 > > > different issues here. > > > > You'd like me to remove the IRQ handling entirely from this code as one > > patch, thereby breaking it, and then add the new IRQ handling as a > > separate patch? > > > > Are you sure? > > > > I really don't think so, and I suspect you haven't even read the patch. > > > > It's all _one_ issue, with two explainations of why the current code is > > wrong. > > > > So my reply is: unable to split patch. > > Yeah I guess the description "Also there is no need.." above could be > just "This is fixed by not using IRQ chaining mechanism" if anything. Yep, I was mislead by the description, but I also didnt look at the patch carefully enough. > Anyways would be nice to get this in as a fix. I applied it to my for-next branch for now, and I'll also try to have Linus pulling it. Cheers, Samuel. > Acked-by: Tony Lindgren <tony@xxxxxxxxxxx> -- Intel Open Source Technology Centre http://oss.intel.com/ -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
