- 05 Mar, 2014 2 commits
-
-
Thomas Gleixner authored
Compiling last minute changes without setting the proper config options is not really clever. Reported-by:
Fengguang Wu <fengguang.wu@intel.com> Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Thomas Gleixner authored
commit: 8f945a33 (genirq: Move kstat_incr_irqs_this_cpu() to core) unearthed the following: arch/m68k/kernel/ints.c:34:15: error: variable 'auto_irq_chip' has initializer but incomplete type arch/m68k/kernel/ints.c:35:2: error: unknown field 'name' specified in initializer arch/m68k/kernel/ints.c:35:2: warning: excess elements in struct initializer [enabled by default] The reason is that this file requires linux/irq.h and magically pulled that in via linux/kernel_stat.h The commit above got rid of the pointless include of linux/irq.h in linux/kernel_stat.h and therefor broke the build. Include linux/irq.h Reported-by: fengguang.wu@intel.com Signed-off-by:
-
- 04 Mar, 2014 30 commits
-
-
Thomas Gleixner authored
Commit b8a9a11b (powerpc: eeh: Kill another abuse of irq_desc) is missing some brackets ..... It's not a good idea to write patches in grumpy mode and then forget to at least compile test them or rely on the few eyeballs discussing that patch to spot it..... Reported-by: fengguang.wu@intel.com Signed-off-by:
-
Thomas Gleixner authored
commit: 8f945a33 (genirq: Move kstat_incr_irqs_this_cpu() to core) unearthed the following: arch/s390/kernel/irq.c: In function 'init_IRQ': >> arch/s390/kernel/irq.c:93:2: error: implicit declaration of function 'irq_reserve_irqs' [-Werror=implicit-function-declaration] .... cc1: some warnings being treated as errors -- drivers/s390/cio/cio.c: In function 'init_cio_interrupts': >> drivers/s390/cio/cio.c:594:2: error: implicit declaration of function 'irq_set_chip_and_handler' [-Werror=implicit-function-declaration] [-Werror=implicit-function-declaration] .... cc1: some warnings being treated as errors The reason is that those files require linux/irq.h and magically pulled that in via linux/kernel_stat.h The commit above got rid of the pointless include of linux/irq.h in linux/kernel_stat.h and therefor broke the build. Include linux/irq.h Reported-by: fengguang.wu@intel.com Signed-off-by:
-
Thomas Gleixner authored
Reported-by: fengguang.wu@intel.com Signed-off-by: -
Thomas Gleixner authored
Commit 1aec1696 (x86: Hyperv: Cleanup the irq mess) removed the ability to build the hyperv stuff as a module. Bring it back. Reported-by: fengguang.wu@intel.com Signed-off-by:
-
Michael Opdenacker authored
This patch removes the IRQF_DISABLED flag from x86 architecture code. It's a NOOP since 2.6.35 and it will be removed one day. Signed-off-by:
Michael Opdenacker <michael.opdenacker@free-electrons.com> Cc: venki@google.com Link: http://lkml.kernel.org/r/1393965305-17248-1-git-send-email-michael.opdenacker@free-electrons.comSigned-off-by:
-
Michael Opdenacker authored
This patch removes the IRQF_DISABLED flag from mn10300 architecture code. It's a NOOP since 2.6.35 and it will be removed one day. Signed-off-by:
-
Michael Opdenacker authored
This patch removes the IRQF_DISABLED flag from ia64 architecture code. It's a NOOP since 2.6.35 and it will be removed one day. Signed-off-by:
-
Thomas Gleixner authored
There is no point in having an incomplete copy of irq_set_affinity() for the hotplug irq migration code. Use the core function instead and while at it switch to for_each_active_irq() Signed-off-by:
-
Thomas Gleixner authored
The user space interface does not filter out offline cpus. It merily verifies that the mask contains at least one online cpu. So the selector in the irq chip implementation needs to make sure to pick only an online cpu because otherwise: Offline Core 1 Set affinity to 0xe Selector will pick first set bit, i.e. core 1 Signed-off-by: -
Thomas Gleixner authored
There is no point in having an incomplete copy of irq_set_affinity() for the hotplug irq migration code. Use the core function instead. Signed-off-by:
-
Thomas Gleixner authored
No more users outside the core code. Put it into the poison cabinet. That also gets rid of the linux/irq.h include in kernel_stat.h Signed-off-by:
-
Thomas Gleixner authored
The vmbus/hyperv interrupt handling is another complete trainwreck and probably the worst of all currently in tree. If CONFIG_HYPERV=y then the interrupt delivery to the vmbus happens via the direct HYPERVISOR_CALLBACK_VECTOR. So far so good, but: The driver requests first a normal device interrupt. The only reason to do so is to increment the interrupt stats of that device interrupt. For no reason it also installs a private flow handler. We have proper accounting mechanisms for direct vectors, but of course it's too much effort to add that 5 lines of code. Aside of that the alloc_intr_gate() is not protected against reallocation which makes module reload impossible. Solution to the problem is simple to rip out the whole mess and implement it correctly. First of all move all that code to arch/x86/kernel/cpu/mshyperv.c and merily install the HYPERVISOR_CALLBACK_VECTOR with proper reallocation protection and use the proper direct vector accounting mechanism. Signed-off-by:
K. Y. Srinivasan <kys@microsoft.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: linuxdrivers <devel@linuxdriverproject.org> Cc: x86 <x86@kernel.org> Link: http://lkml.kernel.org/r/20140223212739.028307673@linutronix.deSigned-off-by:
-
Thomas Gleixner authored
Signed-off-by:
David Vrabel <david.vrabel@citrix.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Xen <xen-devel@lists.xenproject.org> Link: http://lkml.kernel.org/r/20140223212738.808648133@linutronix.deSigned-off-by:
-
Thomas Gleixner authored
HyperV abuses a device interrupt to account for the HYPERVISOR_CALLBACK_VECTOR. Provide proper accounting as we have for the other vectors as well. Signed-off-by:
-
Thomas Gleixner authored
Let the core do the irq_desc resolution. No functional change. Signed-off-by:
-
Thomas Gleixner authored
Let the core do the irq_desc resolution. No functional change. Signed-off-by:
-
Thomas Gleixner authored
Let the core do the irq_desc resolution. No functional change. Signed-off-by:
-
Thomas Gleixner authored
Let the core do the irq_desc resolution. No functional change. Signed-off-by:
-
Thomas Gleixner authored
Let the core do the irq_desc resolution. No functional change. Signed-off-by:
-
Thomas Gleixner authored
Let the core do the irq_desc resolution. No functional change. Signed-off-by:
-
Thomas Gleixner authored
There is a common pattern all over the place: kstat_incr_irqs_this_cpu(irq, irq_to_desc(irq)); This results in a call to core code anyway. So provide a function which does the same thing in core. While at it, replace the butt ugly macro with an inline. Signed-off-by: -
Thomas Gleixner authored
Warn if any PIRQ cannot be bound to an event channel. Remove the check for irq_desc->action. This hypercall never fails in practice so we can emit a warning unconditionally. Remove a check for a valid irq desc. The only caller of xen_destroy_irq() will only do so if the irq was previously fully setup, which means the descriptor has been allocated as well. Signed-off-by:
-
Thomas Gleixner authored
generic_handler_irq() already tests for !desc so use this instead of generic_handle_irq_desc(). Use irq_get_irq_data() instead of desc->irq_data. Signed-off-by:
-
Thomas Gleixner authored
The pm-mmp2 and pm-pxa910 power management related irq_set_wake callbacks fiddle pointlessly with the irq actions for no reason except for lack of understanding how the wakeup mechanism works. On supsend the core disables all interrupts lazily, i.e. it does not mask them at the irq controller level. So any interrupt which is firing during suspend will mark the corresponding interrupt line as pending. Just before the core powers down it checks whether there are interrupts pending from interrupt lines which are marked as wakeup sources and if so it aborts the suspend and resends the interrupts. If there was no interrupt at this point, the cpu goes into suspend with these interrupts unmasked. The IRQF_NO_SUSPEND flag for interrupt actions is a totally different mechanism. That allows the device driver to prevent the core from disabling the interrupt despite the fact that it is not marked as a wakeup source. This has nothing to do with the case at hand. It was introduced for special cases where lazy disable is not possible. Remove the nonsense along with the braindamaged boundary check. The core code does NOT call these functions out of boundary. Add a FIXME comment to an unhandled error path which merily printks some useless blurb instead of returning a proper error code. Signed-off-by:
-
Thomas Gleixner authored
Use the proper functions. There is no need to fiddle with irq_desc. Signed-off-by:
Tony Lindgren <tony@atomide.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: arm <linux-arm-kernel@lists.infradead.org> Cc: Russell King <rmk+kernel@arm.linux.org.uk> Link: http://lkml.kernel.org/r/20140223212737.099151500@linutronix.deSigned-off-by:
-
Thomas Gleixner authored
There is no reason to care about irq_desc in that context, escpecially as irq_data for that interrupt is retrieved as well. Use the proper accessor for the msi descriptor Signed-off-by:
Bjorn Helgaas <bhelgaas@google.com> Acked-by:
Jingoo Han <jg1.han@samsung.com> Cc: Mohit Kumar <mohit.kumar@st.com> Cc: pci <linux-pci@vger.kernel.org> Link: http://lkml.kernel.org/r/20140223212736.987803648@linutronix.deSigned-off-by:
-
Thomas Gleixner authored
commit 91150af3 (powerpc/eeh: Fix unbalanced enable for IRQ) is another brilliant example of trainwreck engineering. The patch "fixes" the issue of an unbalanced call to irq_enable() which causes a prominent warning by checking the disabled state of the interrupt line and call conditionally into the core code. This is wrong in two aspects: 1) The warning is there to tell users, that they need to fix their asymetric enable/disable patterns by finding the root cause and solving it there. It's definitely not meant to work around it by conditionally calling into the core code depending on the random state of the irq line. Asymetric irq_disable/enable calls are a clear sign of wrong usage of the interfaces which have to be cured at the root and not by somehow hacking around it. 2) The abuse of core internal data structure instead of using the proper interfaces for retrieving the information for the 'hack around' irq_desc is core internal and it's clear enough stated. Replace at least the irq_desc abuse with the proper functions and add a big fat comment why this is absurd and completely wrong. Signed-off-by:
-
Thomas Gleixner authored
No functional change Signed-off-by:
-
Thomas Gleixner authored
I'm really grumpy about this one. The line: #include "../../../kernel/irq/settings.h" should have been an alarm sign for all people who added their SOB to this trainwreck. When I cleaned up the mess people made with interrupt descriptors a few years ago, I warned that I'm going to hunt down new offenders and treat them with stinking trouts. In this case I'll use frozen shark for a better educational value. The whole idiocy which was done there could have been avoided with two lines of perfectly fine code. And do not complain about the lack of correct examples in tree. The solution is simple: Remove the brainfart and use the proper functions, which should have been used in the first place Signed-off-by:
-
Jason Cooper authored
This reverts commit 40b367d9. Russell King has raised the idea of creating a proper PMU driver for this SoC that would incorporate the functionality currently in this driver. It would also cover the use case for the graphics subsystem on this SoC. To prevent having to maintain the devicetree ABI for this limited interrupt-handler driver, we revert the driver before it hits a mainline tagged release (eg v3.15). Signed-off-by:
Jason Cooper <jason@lakedaemon.net> Cc: linux-arm-kernel@lists.infradead.org Cc: Andrew Lunn <andrew@lunn.ch> Cc: Sebastian Hesselbarth <sebastian.hesselbarth@googlemail.com> Cc: Gregory CLEMENT <gregory.clement@free-electrons.com> Cc: Russell King - ARM Linux <linux@arm.linux.org.uk> Link: http://lkml.kernel.org/r/1393911160-7688-1-git-send-email-jason@lakedaemon.netSigned-off-by:
-
- 22 Feb, 2014 4 commits
-
-
git://git.infradead.org/linux-mvebuThomas Gleixner authored
irqchip mvebu changes for v3.15 - armada-370-xp - add MSI helper - MPIC chained handler Signed-off-by: -
Ezequiel Garcia authored
The new Armada 375 and Armada 38x Marvell SoCs are based on Cortex-A9 CPU cores and use the ARM GIC as their main interrupt controller. However, for various purposes (wake-up from suspend, MSI interrupts), they have kept a separate MPIC interrupt controller, acting as a slave to the GIC. This MPIC was already used as the primary controller on previous Marvell SoCs, so this commit extends the existing driver to allow the MPIC to be used as a GIC slave. Reviewed-by:
Gregory CLEMENT <gregory.clement@free-electrons.com> Signed-off-by:
Ezequiel Garcia <ezequiel.garcia@free-electrons.com> Signed-off-by:
-
Ezequiel Garcia authored
Introduce a helper function to handle the MSI interrupts. This makes the code more readable. In addition, this will allow to introduce a chained IRQ handler mechanism, which is needed in situations where the MPIC is used as a slave to another interrupt controller. Reviewed-by:
-
Jason Cooper authored
mvebu irqchip fixes for v3.13 - armada-370-xp - fix races is MSI and IPI
-
- 19 Feb, 2014 4 commits
-
-
Chuansheng Liu authored
Change the comment "chasnge" to "change". Signed-off-by:
Chuansheng Liu <chuansheng.liu@intel.com> Link: http://lkml.kernel.org/r/1392020037-5484-2-git-send-email-chuansheng.liu@intel.comSigned-off-by:
-
Thomas Gleixner authored
Pull the functionality which is required to cleanup sdhci/sdio in. It's in a separate branch so it can be pulled from others Signed-off-by: -
Thomas Gleixner authored
In course of the sdhci/sdio discussion with Russell about killing the sdio kthread hackery we discovered the need to be able to wake an interrupt thread from software. The rationale for this is, that sdio hardware can lack proper interrupt support for certain features. So the driver needs to poll the status registers, but at the same time it needs to be woken up by an hardware interrupt. To be able to get rid of the home brewn kthread construct of sdio we need a way to wake an irq thread independent of an actual hardware interrupt. Provide an irq_wake_thread() function which wakes up the thread which is associated to a given dev_id. This allows sdio to invoke the irq thread from the hardware irq handler via the IRQ_WAKE_THREAD return value and provides a possibility to wake it via a timer for the polling scenarios. That allows to simplify the sdio logic significantly. Signed-off-by:
Peter Zijlstra <peterz@infradead.org> Link: http://lkml.kernel.org/r/20140215003823.772565780@linutronix.de
-
Thomas Gleixner authored
synchronize_irq() waits for hard irq and threaded handlers to complete before returning. For some special cases we only need to make sure that the hard interrupt part of the irq line is not in progress when we disabled the - possibly shared - interrupt at the device level. A proper use case for this was provided by Russell. The sdhci driver requires some irq triggered functions to be run in thread context. The current implementation of the thread context is a sdio private kthread construct, which has quite some shortcomings. These can be avoided when the thread is directly associated to the device interrupt via the generic threaded irq infrastructure. Though there is a corner case related to run time power management where one side disables the device interrupts at the device level and needs to make sure, that an already running hard interrupt handler has completed before proceeding further. Though that hard interrupt handler might wake the associated thread, which in turn can request the runtime PM to reenable the device. Using synchronize_irq() leads to an immediate deadlock of the irq thread waiting for the PM lock and the synchronize_irq() waiting for the irq thread to complete. Due to the fact that it is sufficient for this case to ensure that no hard irq handler is executing a new function which avoids the check for the thread is required. Add a function, which just monitors the hard irq parts and ignores the threaded handlers. Signed-off-by:
Russell King <linux@arm.linux.org.uk> Cc: Chris Ball <chris@printf.net> Acked-by:
-
