- 16 Sep, 2015 19 commits
-
-
Rob Herring authored
set_irq_flags is ARM specific with custom flags which have genirq equivalents. Convert drivers to use the genirq interfaces directly, so we can kill off set_irq_flags. The translation of flags is as follows: IRQF_VALID -> !IRQ_NOREQUEST IRQF_PROBE -> !IRQ_NOPROBE IRQF_NOAUTOEN -> IRQ_NOAUTOEN For IRQs managed by an irqdomain, the irqdomain core code handles clearing and setting IRQ_NOREQUEST already, so there is no need to do this in .map() functions and we can simply remove the set_irq_flags calls. Some users also modify IRQ_NOPROBE and this has been maintained although it is not clear that is really needed. There appears to be a great deal of blind copy and paste of this code. Signed-off-by:
Rob Herring <robh@kernel.org> Cc: linux-arm-kernel@lists.infradead.org Cc: Russell King <linux@arm.linux.org.uk> Cc: David Airlie <airlied@linux.ie> Cc: dri-devel@lists.freedesktop.org Signed-off-by:
Thomas Gleixner <tglx@linutronix.de>
-
Thomas Gleixner authored
Most interrupt flow handlers do not use the irq argument. Those few which use it can retrieve the irq number from the irq descriptor. Remove the argument. Search and replace was done with coccinelle and some extra helper scripts around it. Thanks to Julia for her help! Signed-off-by: -
Jiang Liu authored
MSI descriptors are per-irq instead of per irqchip, so move it into struct irq_common_data. Signed-off-by:
Jiang Liu <jiang.liu@linux.intel.com> Cc: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Cc: Tony Luck <tony.luck@intel.com> Cc: Bjorn Helgaas <bhelgaas@google.com> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Randy Dunlap <rdunlap@infradead.org> Cc: Yinghai Lu <yinghai@kernel.org> Cc: Borislav Petkov <bp@alien8.de> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Kevin Cernekee <cernekee@gmail.com> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Marc Zyngier <marc.zyngier@arm.com> Link: http://lkml.kernel.org/r/1433145945-789-35-git-send-email-jiang.liu@linux.intel.comSigned-off-by:
-
Jiang Liu authored
Irq affinity mask is per-irq instead of per irqchip, so move it into struct irq_common_data. Signed-off-by:
-
Jiang Liu authored
Handler data (handler_data) is per-irq instead of per irqchip, so move it into struct irq_common_data. Signed-off-by:
-
Jiang Liu authored
NUMA node information is per-irq instead of per-irqchip, so move it into struct irq_common_data. Also use CONFIG_NUMA to guard irq_common_data.node. Signed-off-by:
-
Thomas Gleixner authored
Get rid of the handler_data abuse. Signed-off-by:
Marc Zyngier <marc.zyngier@arm.com>
-
Thomas Gleixner authored
Get rid of the handler_data abuse. Signed-off-by:
-
Thomas Gleixner authored
Provide a irq data flag to mark an irq forwarded to a VCPU along with the accessor functions. Signed-off-by:
-
Thomas Gleixner authored
Avoid the lookup of irq_desc and use the same mechanism for hierarchical and flat irqdomains. Based-on-a-patch-from: Jiang Liu <jiang.liu@linux.intel.com> Signed-off-by: -
Thomas Gleixner authored
All users converted to irq_set_handler_locked() Signed-off-by: -
Thomas Gleixner authored
Use irq_set_handler_locked() as it avoids a redundant lookup of the irq descriptor. Search and replacement was done with coccinelle: Signed-off-by: -
Thomas Gleixner authored
Use irq_set_handler_locked() as it avoids a redundant lookup of the irq descriptor. Search and replacement was done with coccinelle: Signed-off-by: -
Thomas Gleixner authored
Use irq_set_handler_locked() as it avoids a redundant lookup of the irq descriptor. Search and replacement was done with coccinelle: @@ struct irq_data *d; expression E1; @@ -__irq_set_handler_locked(d->irq, E1); +irq_set_handler_locked(d, E1); Signed-off-by: -
Thomas Gleixner authored
Use irq_set_handler_locked() as it avoids a redundant lookup of the irq descriptor. Search and replacement was done with coccinelle: @@ struct irq_data *d; expression E1; @@ -__irq_set_handler_locked(d->irq, E1); +irq_set_handler_locked(d, E1); Signed-off-by: -
Thomas Gleixner authored
Use irq_set_handler_locked() as it avoids a redundant lookup of the irq descriptor. Search and replacement was done with coccinelle: @@ struct irq_data *d; expression E1; @@ -__irq_set_handler_locked(d->irq, E1); +irq_set_handler_locked(d, E1); Signed-off-by: -
Thomas Gleixner authored
Use irq_set_handler_locked() as it avoids a redundant lookup of the irq descriptor. Search and replacement was done with coccinelle: @@ struct irq_data *d; expression E1; @@ -__irq_set_handler_locked(d->irq, E1); +irq_set_handler_locked(d, E1); Signed-off-by: -
Thomas Gleixner authored
All users converted to irq_set_chip_handler_name_locked() Signed-off-by: -
Thomas Gleixner authored
__irq_set_chip_handler_name_locked() is about to be replaced. Use irq_set_chip_handler_name_locked() instead. Signed-off-by:
-
- 15 Sep, 2015 12 commits
-
-
Huang Shijie authored
__do_IRQ() was removed by commit 1c77ff22 "genirq: Remove __do_IRQ", but the comment referring to __do_IRQ() was left. Update the comment for generic_handle_irq_desc(). Signed-off-by:
Huang Shijie <shijie.huang@arm.com> Cc: jiang.liu@linux.intel.com Cc: peterz@infradead.org Cc: rafael.j.wysocki@intel.com Cc: jason@lakedaemon.net Cc: marc.zyngier@arm.com Link: http://lkml.kernel.org/r/1441074950-3893-1-git-send-email-shijie.huang@arm.comSigned-off-by:
-
Thomas Gleixner authored
Signed-off-by: -
Geert Uytterhoeven authored
The renesas-irqc interrupt controller is cascaded to the GIC, but its driver doesn't propagate wake-up settings to the parent interrupt controller. Since commit aec89ef7 ("irqchip/gic: Enable SKIP_SET_WAKE and MASK_ON_SUSPEND"), the GIC driver masks interrupts during suspend, and wake-up through gpio-keys now fails on r8a73a4/ape6evm. Fix this by propagating wake-up settings to the parent interrupt controller. There's no need to handle irq_set_irq_wake() failures, as the renesas-irqc interrupt controller is always cascaded to a GIC, and the GIC driver always sets SKIP_SET_WAKE since the aforementioned commit. Signed-off-by:
Geert Uytterhoeven <geert+renesas@glider.be> Cc: Sudeep Holla <sudeep.holla@arm.com> Cc: Magnus Damm <magnus.damm@gmail.com> Cc: Jason Cooper <jason@lakedaemon.net> Cc: Marc Zyngier <marc.zyngier@arm.com> Link: http://lkml.kernel.org/r/1441731636-17610-3-git-send-email-geert%2Brenesas@glider.beSigned-off-by:
-
Geert Uytterhoeven authored
The renesas-intc-irqpin interrupt controller is cascaded to the GIC, but its driver doesn't propagate wake-up settings to the parent interrupt controller. Since commit aec89ef7 ("irqchip/gic: Enable SKIP_SET_WAKE and MASK_ON_SUSPEND"), the GIC driver masks interrupts during suspend, and wake-up through gpio-keys now fails on r8a7740/armadillo and sh73a0/kzm9g. Fix this by propagating wake-up settings to the parent interrupt controller. There's no need to handle irq_set_irq_wake() failures, as the renesas-intc-irqpin interrupt controller is always cascaded to a GIC, and the GIC driver always sets SKIP_SET_WAKE since the aforementioned commit. Signed-off-by:
-
Geert Uytterhoeven authored
The renesas-intc-irqpin interrupt controller is cascaded to the GIC. Hence when propagating wake-up settings to its parent interrupt controller, the following lockdep warning is printed: ============================================= [ INFO: possible recursive locking detected ] 4.2.0-armadillo-10725-g50fcd7643c034198 #781 Not tainted --------------------------------------------- s2ram/1179 is trying to acquire lock: (&irq_desc_lock_class){-.-...}, at: [<c005bb54>] __irq_get_desc_lock+0x78/0x94 but task is already holding lock: (&irq_desc_lock_class){-.-...}, at: [<c005bb54>] __irq_get_desc_lock+0x78/0x94 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&irq_desc_lock_class); lock(&irq_desc_lock_class); *** DEADLOCK *** May be due to missing lock nesting notation 7 locks held by s2ram/1179: #0: (sb_writers#7){.+.+.+}, at: [<c00c9708>] __sb_start_write+0x64/0xb8 #1: (&of->mutex){+.+.+.}, at: [<c0125a00>] kernfs_fop_write+0x78/0x1a0 #2: (s_active#23){.+.+.+}, at: [<c0125a08>] kernfs_fop_write+0x80/0x1a0 #3: (autosleep_lock){+.+.+.}, at: [<c0058244>] pm_autosleep_lock+0x18/0x20 #4: (pm_mutex){+.+.+.}, at: [<c0057e50>] pm_suspend+0x54/0x248 #5: (&dev->mutex){......}, at: [<c0243a20>] __device_suspend+0xdc/0x240 #6: (&irq_desc_lock_class){-.-...}, at: [<c005bb54>] __irq_get_desc_lock+0x78/0x94 stack backtrace: CPU: 0 PID: 1179 Comm: s2ram Not tainted 4.2.0-armadillo-10725-g50fcd7643c034198 Hardware name: Generic R8A7740 (Flattened Device Tree) [<c00129f4>] (dump_backtrace) from [<c0012bec>] (show_stack+0x18/0x1c) [<c0012bd4>] (show_stack) from [<c03f5d94>] (dump_stack+0x20/0x28) [<c03f5d74>] (dump_stack) from [<c00514d4>] (__lock_acquire+0x67c/0x1b88) [<c0050e58>] (__lock_acquire) from [<c0052df8>] (lock_acquire+0x9c/0xbc) [<c0052d5c>] (lock_acquire) from [<c03fb068>] (_raw_spin_lock_irqsave+0x44/0x58) [<c03fb024>] (_raw_spin_lock_irqsave) from [<c005bb54>] (__irq_get_desc_lock+0x78/0x94 [<c005badc>] (__irq_get_desc_lock) from [<c005c3d8>] (irq_set_irq_wake+0x28/0x100) [<c005c3b0>] (irq_set_irq_wake) from [<c01e50d0>] (intc_irqpin_irq_set_wake+0x24/0x4c) [<c01e50ac>] (intc_irqpin_irq_set_wake) from [<c005c17c>] (set_irq_wake_real+0x3c/0x50 [<c005c140>] (set_irq_wake_real) from [<c005c414>] (irq_set_irq_wake+0x64/0x100) [<c005c3b0>] (irq_set_irq_wake) from [<c02a19b4>] (gpio_keys_suspend+0x60/0xa0) [<c02a1954>] (gpio_keys_suspend) from [<c023b750>] (platform_pm_suspend+0x3c/0x5c) Avoid this false positive by using a separate lockdep class for INTC External IRQ Pin interrupts. Signed-off-by: -
Geert Uytterhoeven authored
The renesas-irqc interrupt controller is cascaded to the GIC. Hence when propagating wake-up settings to its parent interrupt controller, the following lockdep warning is printed: ============================================= [ INFO: possible recursive locking detected ] 4.2.0-ape6evm-10725-g50fcd7643c034198 #280 Not tainted --------------------------------------------- s2ram/1072 is trying to acquire lock: (&irq_desc_lock_class){-.-...}, at: [<c008d3fc>] __irq_get_desc_lock+0x58/0x98 but task is already holding lock: (&irq_desc_lock_class){-.-...}, at: [<c008d3fc>] __irq_get_desc_lock+0x58/0x98 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&irq_desc_lock_class); lock(&irq_desc_lock_class); *** DEADLOCK *** May be due to missing lock nesting notation 6 locks held by s2ram/1072: #0: (sb_writers#7){.+.+.+}, at: [<c012eb14>] __sb_start_write+0xa0/0xa8 #1: (&of->mutex){+.+.+.}, at: [<c019396c>] kernfs_fop_write+0x4c/0x1bc #2: (s_active#24){.+.+.+}, at: [<c0193974>] kernfs_fop_write+0x54/0x1bc #3: (pm_mutex){+.+.+.}, at: [<c008213c>] pm_suspend+0x10c/0x510 #4: (&dev->mutex){......}, at: [<c02af3c4>] __device_suspend+0xdc/0x2cc #5: (&irq_desc_lock_class){-.-...}, at: [<c008d3fc>] __irq_get_desc_lock+0x58/0x98 stack backtrace: CPU: 0 PID: 1072 Comm: s2ram Not tainted 4.2.0-ape6evm-10725-g50fcd7643c034198 #280 Hardware name: Generic R8A73A4 (Flattened Device Tree) [<c0018078>] (unwind_backtrace) from [<c00144f0>] (show_stack+0x10/0x14) [<c00144f0>] (show_stack) from [<c0451f14>] (dump_stack+0x88/0x98) [<c0451f14>] (dump_stack) from [<c007b29c>] (__lock_acquire+0x15cc/0x20e4) [<c007b29c>] (__lock_acquire) from [<c007c6e0>] (lock_acquire+0xac/0x12c) [<c007c6e0>] (lock_acquire) from [<c0457c00>] (_raw_spin_lock_irqsave+0x40/0x54) [<c0457c00>] (_raw_spin_lock_irqsave) from [<c008d3fc>] (__irq_get_desc_lock+0x58/0x98) [<c008d3fc>] (__irq_get_desc_lock) from [<c008ebbc>] (irq_set_irq_wake+0x20/0xf8) [<c008ebbc>] (irq_set_irq_wake) from [<c0260770>] (irqc_irq_set_wake+0x20/0x4c) [<c0260770>] (irqc_irq_set_wake) from [<c008ec28>] (irq_set_irq_wake+0x8c/0xf8) [<c008ec28>] (irq_set_irq_wake) from [<c02cb8c0>] (gpio_keys_suspend+0x74/0xc0) [<c02cb8c0>] (gpio_keys_suspend) from [<c02ae8cc>] (dpm_run_callback+0x54/0x124) Avoid this false positive by using a separate lockdep class for IRQC interrupts. Signed-off-by: -
Pavel Fedin authored
After GICv2m was enabled for 32-bit ARM kernel, a warning popped up: drivers/irqchip/irq-gic-v2m.c: In function gicv2m_compose_msi_msg: drivers/irqchip/irq-gic-v2m.c:100:2: warning: right shift count >= width of type [enabled by default] msg->address_hi = (u32) (addr >> 32); ^ This patch fixes it by using proper macros for splitting up the value. Signed-off-by:
Pavel Fedin <p.fedin@samsung.com> Reviewed-by:
-
Marc Zyngier authored
When the ITS is configured for non-cacheable transactions, make sure that the allocated, zeroed memory is flushed to the Point of Coherency, allowing the ITS to observe the zeros instead of random garbage (or even get its own data overwritten by zeros being evicted from the cache...). Fixes: 241a386c "irqchip: gicv3-its: Use non-cacheable accesses when no shareability" Reported-and-tested-by:
Stuart Yoder <stuart.yoder@freescale.com> Signed-off-by:
-
Marc Zyngier authored
The GICv2 architecture mandates that the two 4kB GIC regions are contiguous, and on two separate physical pages (so that access to the second page can be trapped by a hypervisor). This doesn't work very well when PAGE_SIZE is 64kB. A relatively common hack^Wway to work around this is to alias each 4kB region over its own 64kB page. Of course in this case, the base address you want to use is not really the begining of the region, but base + 60kB (so that you get a contiguous 8kB region over two distinct pages). Normally, this would be described in DT with a new property, but some HW is already out there, and the firmware makes sure that it will override whatever you put in the GIC node. Duh. And of course, said firmware source code is not available, despite being based on u-boot. The workaround is to detect the case where the CPU interface size is set to 128kB, and verify the aliasing by checking that the ID register for GIC400 (which is the only GIC wired this way so far) is the same at base and base + 0xF000. In this case, we update the GIC base address and let it roll. And if you feel slightly sick by looking at this, rest assured that I do too... Reported-by:
Julien Grall <julien.grall@citrix.com> Signed-off-by:
-
Marc Zyngier authored
The current implementation of platform MSI caches the msi_desc pointer in irq_data::handler_data. This is a bit silly, as we also have irq_data::msi_desc, which is perfectly valid. Remove the useless assignment and simplify the whole flow. Reported-by:
Ma Jun <majun258@huawei.com> Signed-off-by:
-
Thomas Gleixner authored
This is a preparatory patch for moving irq_data struct members. Search and replace was done with coccinelle Signed-off-by: -
Jiang Liu authored
Use access helper irq_data_get_affinity_mask() so we can move the affinity mask to irq_common_data. Signed-off-by:
-
- 14 Sep, 2015 5 commits
-
-
Thomas Gleixner authored
The irq argument of most interrupt flow handlers is unused or merily used instead of a local variable. The handlers which need the irq argument can retrieve the irq number from the irq descriptor. Search and update was done with coccinelle and the invaluable help of Julia Lawall. Signed-off-by: -
Thomas Gleixner authored
Search and replace done with coccinelle Signed-off-by: -
Thomas Gleixner authored
The irq argument of most interrupt flow handlers is unused or merily used instead of a local variable. The handlers which need the irq argument can retrieve the irq number from the irq descriptor. Search and update was done with coccinelle and the invaluable help of Julia Lawall. Signed-off-by: -
Thomas Gleixner authored
The irq argument of most interrupt flow handlers is unused or merily used instead of a local variable. The handlers which need the irq argument can retrieve the irq number from the irq descriptor. Search and update was done with coccinelle and the invaluable help of Julia Lawall. Signed-off-by: -
Thomas Gleixner authored
The irq argument of most interrupt flow handlers is unused or merily used instead of a local variable. The handlers which need the irq argument can retrieve the irq number from the irq descriptor. Search and update was done with coccinelle and the invaluable help of Julia Lawall. Signed-off-by:
-
- 12 Sep, 2015 4 commits
-
-
Linus Torvalds authored
-
git://git.kernel.org/pub/scm/linux/kernel/git/jesper/crisLinus Torvalds authored
Pull CRIS updates from Jesper Nilsson: "Mostly removal of old cruft of which we can use a generic version, or fixes for code not commonly run in the cris port, but also additions to enable some good debug" * tag 'cris-for-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/jesper/cris: (25 commits) CRISv10: delete unused lib/dmacopy.c CRISv10: delete unused lib/old_checksum.c CRIS: fix switch_mm() lockdep splat CRISv32: enable LOCKDEP_SUPPORT CRIS: add STACKTRACE_SUPPORT CRISv32: annotate irq enable in idle loop CRISv32: add support for irqflags tracing CRIS: UAPI: use generic types.h CRIS: UAPI: use generic shmbuf.h CRIS: UAPI: use generic msgbuf.h CRIS: UAPI: use generic socket.h CRIS: UAPI: use generic sembuf.h CRIS: UAPI: use generic sockios.h CRIS: UAPI: use generic auxvec.h CRIS: UAPI: use generic headers via Kbuild CRIS: UAPI: fix elf.h export CRIS: don't make asm/elf.h depend on asm/user.h CRIS: UAPI: fix ptrace.h CRISv32: Squash compile warnings for axisflashmap CRISv32: Add GPIO driver to the default configs ...
-
Linus Torvalds authored
rq_data_dir() returns either READ or WRITE (0 == READ, 1 == WRITE), not a boolean value. Now, admittedly the "!= 0" doesn't really change the value (0 stays as zero, 1 stays as one), but it's not only redundant, it confuses gcc, and causes gcc to warn about the construct switch (rq_data_dir(req)) { case READ: ... case WRITE: ... that we have in a few drivers. Now, the gcc warning is silly and stupid (it seems to warn not about the switch value having a different type from the case statements, but about _any_ boolean switch value), but in this case the code itself is silly and stupid too, so let's just change it, and get rid of warnings like this: drivers/block/hd.c: In function ‘hd_request’: drivers/block/hd.c:630:11: warning: switch condition has boolean value [-Wswitch-bool] switch (rq_data_dir(req)) { The odd '!= 0' came in when "cmd_flags" got turned into a "u64" in commit 5953316d ("block: make rq->cmd_flags be 64-bit") and is presumably because the old code (that just did a logical 'and' with 1) would then end up making the type of rq_data_dir() be u64 too. But if we want to retain the old regular integer type, let's just cast the result to 'int' rather than use that rather odd '!= 0'. Signed-off-by:Linus Torvalds <torvalds@linux-foundation.org>
-
Linus Torvalds authored
Fix up the writeback plugging introduced in commit d353d758 ("writeback: plug writeback at a high level") that then caused problems due to the unplug happening with a spinlock held. * writeback-plugging: writeback: plug writeback in wb_writeback() and writeback_inodes_wb() Revert "writeback: plug writeback at a high level"
-
