BMC/Intel-BMC/linux.git/drivers/irqchip, branch dev-4.6

irqchip: Add irq controller for Aspeed

2016-06-03T20:51:36+00:00

Signed-off-by: Benjamin Herrenschmidt Signed-off-by: Joel Stanley

irqchip/gic-v3: Configure all interrupts as non-secure Group-1

2016-06-01T19:17:59+00:00

commit 7c9b973061b03af62734f613f6abec46c0dd4a88 upstream. The GICv3 driver wrongly assumes that it runs on the non-secure side of a secure-enabled system, while it could be on a system with a single security state, or a GICv3 with GICD_CTLR.DS set. Either way, it is important to configure this properly, or interrupts will simply not be delivered on this HW. Reported-by: Peter Maydell Tested-by: Peter Maydell Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman

irqchip/gic: Ensure ordering between read of INTACK and shared data

2016-06-01T19:17:59+00:00

commit f86c4fbd930ff6fecf3d8a1c313182bd0f49f496 upstream. When an IPI is generated by a CPU, the pattern looks roughly like: smp_wmb(); On the receiving CPU we rely on the fact that, once we've taken the interrupt, then the freshly written shared data must be visible to us. Put another way, the CPU isn't going to speculate taking an interrupt. Unfortunately, this assumption turns out to be broken. Consider that CPUx wants to send an IPI to CPUy, which will cause CPUy to read some shared_data. Before CPUx has done anything, a random peripheral raises an IRQ to the GIC and the IRQ line on CPUy is raised. CPUy then takes the IRQ and starts executing the entry code, heading towards gic_handle_irq. Furthermore, let's assume that a bunch of the previous interrupts handled by CPUy were SGIs, so the branch predictor kicks in and speculates that irqnr will be <16 and we're likely to head into handle_IPI. The prefetcher then grabs a speculative copy of shared_data which contains a stale value. Meanwhile, CPUx gets round to updating shared_data and asking the GIC to send an SGI to CPUy. Internally, the GIC decides that the SGI is more important than the peripheral interrupt (which hasn't yet been ACKed) but doesn't need to do anything to CPUy, because the IRQ line is already raised. CPUy then reads the ACK register on the GIC, sees the SGI value which confirms the branch prediction and we end up with a stale shared_data value. This patch fixes the problem by adding an smp_rmb() to the IPI entry code in gic_handle_irq. As it turns out, the combination of a control dependency and an ISB instruction from the EOI in the GICv3 driver is enough to provide the ordering we need, so we add a comment there justifying the absence of an explicit smp_rmb(). Signed-off-by: Will Deacon Signed-off-by: Marc Zyngier Signed-off-by: Greg Kroah-Hartman

irqchip/mips-gic: Don't overrun pcpu_masks array

2016-04-21T19:04:29+00:00

Commit 2a0787051182 ("irqchip/mips-gic: Use gic_vpes instead of NR_CPUS") & commit 78930f09b940 ("irqchip/mips-gic: Clear percpu_masks correctly when mapping") both introduce code which accesses gic_vpes entries in the pcpu_masks array. However, this array has length NR_CPUS. If NR_CPUS is less than gic_vpes (ie. the kernel supports use of less CPUs than are present in the system) then we overrun the array, clobber some other data & generally die pretty promptly. Most notably this affects uniprocessor kernels running on any multicore or multithreaded Malta with a GIC (ie. the vast majority of real Malta boards). Fix this by only accessing up to min(gic_vpes, NR_CPUS) entries in the pcpu_masks array, preventing the array overrun. Fixes: 2a0787051182 ("irqchip/mips-gic: Use gic_vpes instead of NR_CPUS") Fixes: 78930f09b940 ("irqchip/mips-gic: Clear percpu_masks correctly when mapping") Signed-off-by: Paul Burton Cc: linux-mips@linux-mips.org Cc: Jason Cooper Cc: Marc Zyngier Cc: Ralf Baechle Link: http://lkml.kernel.org/r/1461234714-9975-1-git-send-email-paul.burton@imgtec.com Signed-off-by: Thomas Gleixner

irqchip/mbigen: Make CONFIG_HISILICON_IRQ_MBIGEN a hidden option

2016-03-23T11:02:29+00:00

This config is selected by CONFIG_ARCH_HISI, so there is no point to have it user configurable. While at it move the config option to the proper place in the alphabetically sorted option list. Requested-by: Thomas Gleixner Signed-off-by: Ma Jun Cc: mark.rutland@arm.com Cc: jason@lakedaemon.net Cc: marc.zyngier@arm.com Cc: Catalin.Marinas@arm.com Cc: guohanjun@huawei.com Cc: Will.Deacon@arm.com Cc: huxinwei@huawei.com Cc: lizefan@huawei.com Cc: dingtianhong@huawei.com Cc: zhaojunhua@hisilicon.com Cc: liguozhu@hisilicon.com Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1458723993-21044-3-git-send-email-majun258@huawei.com Signed-off-by: Thomas Gleixner

irqchip/mbigen: Handle multiple device nodes in a mbigen module

2016-03-21T10:24:11+00:00

Each mbigen device is represented as a independent platform device. If the devices belong to the same mbigen hardware module, then the register space for these devices is the same. That leads to a resource conflict. The solution for this is to represent the mbigen module as a platform device and make the mbigen devices subdevices of that. The register space is associated to the mbigen module and therefor the resource conflict is avoided. [ tglx: Massaged changelog, cleaned up the code and removed the silly printk ] Signed-off-by: Ma Jun Cc: mark.rutland@arm.com Cc: jason@lakedaemon.net Cc: marc.zyngier@arm.com Cc: Catalin.Marinas@arm.com Cc: guohanjun@huawei.com Cc: Will.Deacon@arm.com Cc: huxinwei@huawei.com Cc: lizefan@huawei.com Cc: dingtianhong@huawei.com Cc: zhaojunhua@hisilicon.com Cc: liguozhu@hisilicon.com Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1458203641-17172-3-git-send-email-majun258@huawei.com Signed-off-by: Thomas Gleixner

irqchip/tegra: Switch to use irq_domain_free_irqs_common

2016-03-20T19:08:28+00:00

Current code calls irq_domain_alloc_irqs_parent() in .alloc, so it should call irq_domain_free_irqs_parent() accordingly in .free. Fix it by switching to use irq_domain_free_irqs_common() instead of the open-coded private implementation. Signed-off-by: Axel Lin Cc: Alexandre Courbot Cc: Jason Cooper Cc: Stephen Warren Cc: Marc Zyngier Cc: Thierry Reding Cc: linux-tegra@vger.kernel.org Link: http://lkml.kernel.org/r/1458477845.28679.1.camel@ingics.com Signed-off-by: Thomas Gleixner

irqchip/irq-alpine-msi: Release the correct domain on error

2016-03-11T09:06:55+00:00

The "msi_domain" variable is NULL here so it leads to a NULL dereference. It looks like we actually intended to free "middle_domain". Fixes: e6b78f2c3e14 ('irqchip: Add the Alpine MSIX interrupt controller') Signed-off-by: Dan Carpenter Cc: Jason Cooper Cc: Marc Zyngier Cc: Antoine Tenart Cc: kernel-janitors@vger.kernel.org Cc: Tsahee Zidenberg Link: http://lkml.kernel.org/r/20160311081442.GE31887@mwanda Signed-off-by: Thomas Gleixner

irqchip/mxs: Fix error check of of_io_request_and_map()

2016-03-10T15:03:30+00:00

The of_io_request_and_map() returns a valid pointer in iomem region or ERR_PTR(), check for NULL always fails and may cause a NULL pointer dereference on error path. Fixes: 25e34b44313b ("irqchip/mxs: Prepare driver for hardware with different offsets") Signed-off-by: Vladimir Zapolskiy Cc: Jason Cooper Cc: Marc Zyngier Cc: Oleksij Rempel Cc: Sascha Hauer Cc: Shawn Guo Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1457486500-10237-1-git-send-email-vz@mleia.com Signed-off-by: Thomas Gleixner

irqchip/sunxi-nmi: Fix error check of of_io_request_and_map()

2016-03-10T15:03:30+00:00

The of_io_request_and_map() returns a valid pointer in iomem region or ERR_PTR(), check for NULL always fails and may cause a NULL pointer dereference on error path. Fixes: 0e841b04c829 ("irqchip/sunxi-nmi: Switch to of_io_request_and_map() from of_iomap()") Signed-off-by: Vladimir Zapolskiy Cc: Jason Cooper Cc: Marc Zyngier Cc: Chen-Yu Tsai Cc: Maxime Ripard Cc: linux-arm-kernel@lists.infradead.org Link: http://lkml.kernel.org/r/1457486489-10189-1-git-send-email-vz@mleia.com Signed-off-by: Thomas Gleixner