Re: handle_bad_irq and locking

2017-05-15 Thread Gregory Fong
handle_bad_irq_desc() > > have proper locking in it and move all users (including do_bad_IRQ()) over > to it. I'm guessing the different name would be to avoid breaking existing users. Wouldn't it be better to just add locking in handle_bad_irq(), simultaneously removing the lock/unl

Re: handle_bad_irq and locking

2017-05-15 Thread Gregory Fong
() > > have proper locking in it and move all users (including do_bad_IRQ()) over > to it. I'm guessing the different name would be to avoid breaking existing users. Wouldn't it be better to just add locking in handle_bad_irq(), simultaneously removing the lock/unlock around in its invoca

Re: handle_bad_irq and locking

2017-05-12 Thread Thomas Gleixner
On Thu, 11 May 2017, Gregory Fong wrote: > Hi Thomas, > > I noticed that when you changed arm irq handling to use the generic > implementation back in 2006 that you changed do_bad_IRQ() to the > following: > > +#define do_bad_IRQ(irq,desc,regs) \ > +do {

Re: handle_bad_irq and locking

2017-05-12 Thread Thomas Gleixner
On Thu, 11 May 2017, Gregory Fong wrote: > Hi Thomas, > > I noticed that when you changed arm irq handling to use the generic > implementation back in 2006 that you changed do_bad_IRQ() to the > following: > > +#define do_bad_IRQ(irq,desc,regs) \ > +do {

handle_bad_irq and locking

2017-05-11 Thread Gregory Fong
Hi Thomas, I noticed that when you changed arm irq handling to use the generic implementation back in 2006 that you changed do_bad_IRQ() to the following: +#define do_bad_IRQ(irq,desc,regs) \ +do { \ + spin_lock(>lock);

handle_bad_irq and locking

2017-05-11 Thread Gregory Fong
Hi Thomas, I noticed that when you changed arm irq handling to use the generic implementation back in 2006 that you changed do_bad_IRQ() to the following: +#define do_bad_IRQ(irq,desc,regs) \ +do { \ + spin_lock(>lock);