On Thu, Apr 24, 2014 at 04:40:25PM +0200, Thomas Gleixner wrote: > On Thu, 24 Apr 2014, Linus Walleij wrote: > > On Thu, Apr 24, 2014 at 9:25 AM, Thomas Gleixner <t...@linutronix.de> wrote: > > > > > I'm traveling until friday, so please wait before you commit that > > > fugly hack. I'll have a closer look how we can handle that at the core > > > level. > > > > Thanks a *lot* Thomas, I'll stand by for action. > > Find an untested patch below. It should cure the issue. > > I went through all code which can be affected by this and except for > some other places, which might erroneously allocate inside the > hardwired space, I can't see any possible fallout. > > Thanks, > > tglx > > --------------------> > > Subject: genirq: x86: Ensure that dynamic irq allocation does not conflict > From: Thomas Gleixner <t...@linutronix.de> > Date: Thu, 24 Apr 2014 09:50:53 +0200 > > On x86 the allocation of irq descriptors may allocate interrupts which > are in the range of the GSI interrupts. That's wrong as those > interrupts are hardwired and we don't have the irq domain translation > like PPC. So one of these interrupts can be hooked up later to one of > the devices which are hard wired to it and the io_apic init code for > that particular interrupt line happily reuses that descriptor with a > completely different configuration so hell breaks lose. > > Inside x86 we allocate dynamic interrupts from above nr_gsi_irqs, > except for a few usage sites which have not yet blown up in our face > for whatever reason. But for drivers which need an irq range, like the > GPIO drivers, we have no limit in place and we don't want to expose > such a detail to a driver. > > To cure this introduce a function which an architecture can implement > to impose a lower bound on the dynamic interrupt allocations. > > Implement it for x86 and set the lower bound to nr_gsi_irqs, which is > the end of the hardwired interrupt space, so all dynamic allocations > happen above. > > That not only allows the GPIO driver to work sanely, it also protects > the bogus callsites of create_irq_nr() in hpet, uv, irq_remapping and > htirq code. They need to be cleaned up as well, but that's a separate > issue. > > Signed-off-by: Thomas Gleixner <t...@linutronix.de>
Works here on my T100, Tested-by: Mika Westerberg <mika.westerb...@linux.intel.com> -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
