aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2016-09-14Merge branch 'dt/irq-fix' into fixesArnd Bergmann11-44/+44
* dt/irq-fix: arm64: dts: Fix broken architected timer interrupt trigger
2016-09-14arm64: dts: Fix broken architected timer interrupt triggerMarc Zyngier11-44/+44
The ARM architected timer specification mandates that the interrupt associated with each timer is level triggered (which corresponds to the "counter >= comparator" condition). A number of DTs are being remarkably creative, declaring the interrupt to be edge triggered. A quick look at the TRM for the corresponding ARM CPUs clearly shows that this is wrong, and I've corrected those. For non-ARM designs (and in the absence of a publicly available TRM), I've made them active low as well, which can't be completely wrong as the GIC cannot disinguish between level low and level high. The respective maintainers are of course welcome to prove me wrong. While I was at it, I took the liberty to fix a couple of related issue, such as some spurious affinity bits on ThunderX, and their complete absence on ls1043a (both of which seem to be related to copy-pasting from other DTs). Acked-by: Duc Dang <[email protected]> Acked-by: Carlo Caione <[email protected]> Acked-by: Michal Simek <[email protected]> Acked-by: Krzysztof Kozlowski <[email protected]> Acked-by: Dinh Nguyen <[email protected]> Acked-by: Masahiro Yamada <[email protected]> Signed-off-by: Marc Zyngier <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2016-09-14ARM: multi_v7_defconfig: update XILINX_VDMAFabian Frederick1-1/+1
Commit fde57a7c4474 ("dmaengine: xilinx: Rename driver and config") renamed config XILINX_VDMA to config XILINX_DMA Update defconfig accordingly. Signed-off-by: Fabian Frederick <[email protected]> Signed-off-by: Arnd Bergmann <[email protected]>
2016-09-14Merge branch 'uaccess-fixes' of ↵Linus Torvalds26-170/+179
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs Pull uaccess fixes from Al Viro: "Fixes for broken uaccess primitives - mostly lack of proper zeroing in copy_from_user()/get_user()/__get_user(), but for several architectures there's more (broken clear_user() on frv and strncpy_from_user() on hexagon)" * 'uaccess-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (28 commits) avr32: fix copy_from_user() microblaze: fix __get_user() microblaze: fix copy_from_user() m32r: fix __get_user() blackfin: fix copy_from_user() sparc32: fix copy_from_user() sh: fix copy_from_user() sh64: failing __get_user() should zero score: fix copy_from_user() and friends score: fix __get_user/get_user s390: get_user() should zero on failure ppc32: fix copy_from_user() parisc: fix copy_from_user() openrisc: fix copy_from_user() nios2: fix __get_user() nios2: copy_from_user() should zero the tail of destination mn10300: copy_from_user() should zero on access_ok() failure... mn10300: failing __get_user() and get_user() should zero mips: copy_from_user() must zero the destination on access_ok() failure ARC: uaccess: get_user to zero out dest in cause of fault ...
2016-09-14Merge tag 'for-linus-4.8b-rc6-tag' of ↵Linus Torvalds1-4/+3
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip Pull xen regression fix from David Vrabel: "Fix SMP boot in arm guests" * tag 'for-linus-4.8b-rc6-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: arm/xen: fix SMP guests boot
2016-09-14arm/xen: fix SMP guests bootVitaly Kuznetsov1-4/+3
Commit 88e957d6e47f ("xen: introduce xen_vcpu_id mapping") broke SMP ARM guests on Xen. When FIFO-based event channels are in use (this is the default), evtchn_fifo_alloc_control_block() is called on CPU_UP_PREPARE event and this happens before we set up xen_vcpu_id mapping in xen_starting_cpu. Temporary fix the issue by setting direct Linux CPU id <-> Xen vCPU id mapping for all possible CPUs at boot. We don't currently support kexec/kdump on Xen/ARM so these ids always match. In future, we have several ways to solve the issue, e.g.: - Eliminate all hypercalls from CPU_UP_PREPARE, do them from the starting CPU. This can probably be done for both x86 and ARM and, if done, will allow us to get Xen's idea of vCPU id from CPUID/MPIDR on the starting CPU directly, no messing with ACPI/device tree required. - Save vCPU id information from ACPI/device tree on ARM and use it to initialize xen_vcpu_id mapping. This is the same trick we currently do on x86. Reported-by: Julien Grall <[email protected]> Tested-by: Wei Chen <[email protected]> Signed-off-by: Vitaly Kuznetsov <[email protected]> Acked-by: Stefano Stabellini <[email protected]> Signed-off-by: David Vrabel <[email protected]>
2016-09-14cpu/hotplug: Include linux/types.h in linux/cpuhotplug.hPaul Burton1-0/+2
The linux/cpuhotplug.h header makes use of the bool type, but wasn't including linux/types.h to ensure that type has been defined. Fix this by including linux/types.h in preparation for including linux/cpuhotplug.h in a file that doesn't do so already. Signed-off-by: Paul Burton <[email protected]> Cc: [email protected] Cc: Richard Cochran <[email protected]> Cc: Sebastian Andrzej Siewior <[email protected]> Cc: Ralf Baechle <[email protected]> Cc: Anna-Maria Gleixner <[email protected]> Link: http://lkml.kernel.org/r/[email protected] Signed-off-by: Thomas Gleixner <[email protected]>
2016-09-14mmc: omap: Initialize dma_slave_config to avoid random data in it's fieldsPeter Ujfalusi1-8/+10
It is wrong to use uninitialized dma_slave_config and configure only certain fields as the DMAengine driver might look at non initialized (random data) fields and tries to interpret it. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2016-09-14mmc: omap_hsmmc: Initialize dma_slave_config to avoid random dataPeter Ujfalusi1-8/+8
It is wrong to use uninitialized dma_slave_config and configure only certain fields as the DMAengine driver might look at non initialized (random data) fields and tries to interpret it. Signed-off-by: Peter Ujfalusi <[email protected]> Signed-off-by: Ulf Hansson <[email protected]>
2016-09-14drm/i915: Ignore OpRegion panel type except on select machinesVille Syrjälä1-0/+27
Turns out commit a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details") has regressed quite a few machines. So it looks like we can't use the panel type from OpRegion on all systems, and yet we absolutely must use it on some specific systems. Despite trying, I was unable to find any automagic way to determine if the OpRegion panel type is respectable or not. The only glimmer of hope I had was bit 8 in the SCIC response, but that turned out to not work either (it was always 0 on both types of systems). So, to fix the regressions without breaking the machine we know to need the OpRegion panel type, let's just add a quirk for this. Only specific machines known to require the OpRegion panel type will therefore use it. Everyone else will fall bck to the VBT panel type. The only known machine so far is a "Conrac GmbH IX45GM2". The PCI subsystem ID on this machine is just a generic 8086:2a42, so of no use. Instead we'll go with a DMI match. I suspect we can now also revert commit aeddda06c1a7 ("drm/i915: Ignore panel type from OpRegion on SKL") but let's leave that to a separate patch. v2: Do the DMI match in the opregion code directly, as dev_priv->quirks gets populated too late Cc: Rob Kramer <[email protected]> Cc: Martin van Es <[email protected]> Cc: Andrea Arcangeli <[email protected]> Cc: Dave Airlie <[email protected]> Cc: Marco Krüger <[email protected]> Cc: Sean Greenslade <[email protected]> Cc: Trudy Tective <[email protected]> Cc: Robin Müller <[email protected]> Cc: Alexander Kobel <[email protected]> Cc: Alexey Shumitsky <[email protected]> Cc: Emil Andersen Lauridsen <[email protected]> Cc: [email protected] Cc: James Hogan <[email protected]> Cc: James Bottomley <[email protected]> Cc: [email protected] References: https://lists.freedesktop.org/archives/intel-gfx/2016-August/105545.html References: https://lists.freedesktop.org/archives/dri-devel/2016-August/116888.html References: https://lists.freedesktop.org/archives/intel-gfx/2016-June/098826.html Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=94825 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97060 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97443 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97363 Fixes: a05628195a0d ("drm/i915: Get panel_type from OpRegion panel details") Tested-by: Marco Krüger <[email protected]> Tested-by: Alexey Shumitsky <[email protected]> Tested-by: Sean Greenslade <[email protected]> Tested-by: Emil Andersen Lauridsen <[email protected]> Tested-by: Robin Müller <[email protected]> Tested-by: [email protected] Tested-by: Rob Kramer <[email protected]> Signed-off-by: Ville Syrjälä <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] References: http://patchwork.freedesktop.org/patch/msgid/[email protected] Acked-by: Jani Nikula <[email protected]> (cherry picked from commit c8ebfad7a063fe665417fa0eeb0da7cfe987d8ed) Signed-off-by: Jani Nikula <[email protected]>
2016-09-14Revert "drm/i915/psr: Make idle_frames sensible again"Rodrigo Vivi1-7/+7
This reverts commit 1c80c25fb622973dd135878e98d172be20859049 Author: Daniel Vetter <[email protected]> Date: Wed May 18 18:47:12 2016 +0200 drm/i915/psr: Make idle_frames sensible again There are panels that needs 4 idle frames before entering PSR, but VBT is unproperly set. Also lately it was identified that idle frame count calculated at HW can be off by 1, what makes the minimum of 2, at least. Without the current vbt+1 we are with the risk of having HW calculating 0 idle frames and entering PSR when it shouldn't. Regardless the lack of link training. [Jani: there is some disagreement on the explanation, but the commit regresses so revert it is.] References: http://marc.info/[email protected] Cc: Dominik Brodowski <[email protected]> Cc: Jani Nikula <[email protected]> Cc: Daniel Vetter <[email protected]> Signed-off-by: Rodrigo Vivi <[email protected]> Fixes: 1c80c25fb622 ("drm/i915/psr: Make idle_frames sensible again") Cc: [email protected] # v4.8-rc1+ Signed-off-by: Jani Nikula <[email protected]> Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] (cherry picked from commit 40918e0bb81be02f507a941f8b2741f0dc1771b0) Signed-off-by: Jani Nikula <[email protected]>
2016-09-14drm/i915: Restore lost "Initialized i915" welcome messageChris Wilson1-0/+5
A side effect of removing the midlayer from driver loading was the loss of a useful message announcing to userspace that i915 had successfully started, e.g.: [drm] Initialized i915 1.6.0 20160425 for 0000:00:02.0 on minor 0 Reported-by: Timo Aaltonen <[email protected]> Signed-off-by: Chris Wilson <[email protected]> Fixes: 8f460e2c78f2 ("drm/i915: Demidlayer driver loading") Cc: Daniel Vetter <[email protected]> Cc: Ville Syrjälä <[email protected]> Cc: [email protected] Link: http://patchwork.freedesktop.org/patch/msgid/[email protected] Reviewed-by: Daniel Vetter <[email protected]> (cherry picked from commit bc5ca47c0af4f949ba889e666b7da65569e36093) Signed-off-by: Jani Nikula <[email protected]>
2016-09-14powerpc/powernv: Fix the state of root PEGavin Shan1-1/+11
The PE for root bus (root PE) can be removed because of PCI hot remove in EEH recovery path for fenced PHB error. We need update @phb->root_pe_populated accordingly so that the root PE can be populated again in forthcoming PCI hot add path. Also, the PE shouldn't be destroyed as it's global and reserved resource. Fixes: c5f7700bbd2e ("powerpc/powernv: Dynamically release PE") Reported-by: Frederic Barrat <[email protected]> Signed-off-by: Gavin Shan <[email protected]> Signed-off-by: Michael Ellerman <[email protected]>
2016-09-13avr32: fix copy_from_user()Al Viro3-4/+13
really ugly, but apparently avr32 compilers turns access_ok() into something so bad that they want it in assembler. Left that way, zeroing added in inline wrapper. Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13microblaze: fix __get_user()Al Viro1-1/+1
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13microblaze: fix copy_from_user()Al Viro1-3/+6
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13m32r: fix __get_user()Al Viro1-1/+1
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13blackfin: fix copy_from_user()Al Viro1-4/+5
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13sparc32: fix copy_from_user()Al Viro1-1/+3
Cc: [email protected] Acked-by: David S. Miller <[email protected]> Signed-off-by: Al Viro <[email protected]>
2016-09-13sh: fix copy_from_user()Al Viro1-1/+4
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13sh64: failing __get_user() should zeroAl Viro1-0/+1
It could be done in exception-handling bits in __get_user_b() et.al., but the surgery involved would take more knowledge of sh64 details than I have or _want_ to have. Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13score: fix copy_from_user() and friendsAl Viro1-21/+20
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13score: fix __get_user/get_userAl Viro1-1/+4
* should zero on any failure * __get_user() should use __copy_from_user(), not copy_from_user() Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13s390: get_user() should zero on failureAl Viro1-4/+4
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13ppc32: fix copy_from_user()Al Viro1-23/+2
should clear on access_ok() failures. Also remove the useless range truncation logics. Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13parisc: fix copy_from_user()Al Viro1-2/+4
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13openrisc: fix copy_from_user()Al Viro1-24/+11
... that should zero on faults. Also remove the <censored> helpful logics wrt range truncation copied from ppc32. Where it had ever been needed only in case of copy_from_user() *and* had not been merged into the mainline until a month after the need had disappeared. A decade before openrisc went into mainline, I might add... Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13nios2: fix __get_user()Al Viro1-2/+2
a) should not leave crap on fault b) should _not_ require access_ok() in any cases. Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13nios2: copy_from_user() should zero the tail of destinationAl Viro1-3/+6
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13mn10300: copy_from_user() should zero on access_ok() failure...Al Viro1-1/+3
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13mn10300: failing __get_user() and get_user() should zeroAl Viro1-0/+1
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13mips: copy_from_user() must zero the destination on access_ok() failureAl Viro1-0/+3
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13ARC: uaccess: get_user to zero out dest in cause of faultVineet Gupta1-2/+9
Al reported potential issue with ARC get_user() as it wasn't clearing out destination pointer in case of fault due to bad address etc. Verified using following | { | u32 bogus1 = 0xdeadbeef; | u64 bogus2 = 0xdead; | int rc1, rc2; | | pr_info("Orig values %x %llx\n", bogus1, bogus2); | rc1 = get_user(bogus1, (u32 __user *)0x40000000); | rc2 = get_user(bogus2, (u64 __user *)0x50000000); | pr_info("access %d %d, new values %x %llx\n", | rc1, rc2, bogus1, bogus2); | } | [ARCLinux]# insmod /mnt/kernel-module/qtn.ko | Orig values deadbeef dead | access -14 -14, new values 0 0 Reported-by: Al Viro <[email protected]> Cc: Linus Torvalds <[email protected]> Cc: [email protected] Cc: [email protected] Cc: [email protected] Signed-off-by: Vineet Gupta <[email protected]> Signed-off-by: Al Viro <[email protected]>
2016-09-13metag: copy_from_user() should zero the destination on access_ok() failureAl Viro1-1/+2
Cc: [email protected] Acked-by: James Hogan <[email protected]> Signed-off-by: Al Viro <[email protected]>
2016-09-13ia64: copy_from_user() should zero the destination on access_ok() failureAl Viro1-14/+11
Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13hexagon: fix strncpy_from_user() error returnAl Viro1-1/+2
It's -EFAULT, not -1 (and contrary to the comment in there, __strnlen_user() can return 0 - on faults). Cc: [email protected] Acked-by: Richard Kuo <[email protected]> Signed-off-by: Al Viro <[email protected]>
2016-09-13frv: fix clear_user()Al Viro1-3/+9
It should check access_ok(). Otherwise a bunch of places turn into trivially exploitable rootholes. Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13cris: buggered copy_from_user/copy_to_user/clear_userAl Viro1-39/+32
* copy_from_user() on access_ok() failure ought to zero the destination * none of those primitives should skip the access_ok() check in case of small constant size. Cc: [email protected] Acked-by: Jesper Nilsson <[email protected]> Signed-off-by: Al Viro <[email protected]>
2016-09-13asm-generic: make get_user() clear the destination on errorsAl Viro1-3/+7
both for access_ok() failures and for faults halfway through Cc: [email protected] Signed-off-by: Al Viro <[email protected]>
2016-09-13PCI: Fix bridge_d3 update on device removalLukas Wunner1-2/+1
Starting with v4.8, we allow a PCIe port to runtime suspend to D3hot if the port itself and its children satisfy a number of conditions. Once a child is removed, we recheck those conditions in case the removed device was blocking the port from suspending. The rechecking needs to happen *after* the device has been removed from the bus it resides on. Otherwise when walking the port's subordinate bus in pci_bridge_d3_update(), the device being removed would erroneously still be taken into account. However the device is removed from the bus_list in pci_destroy_dev() and we currently recheck *before* that. Fix it. Fixes: 9d26d3a8f1b0 ("PCI: Put PCIe ports into D3 during suspend") Signed-off-by: Lukas Wunner <[email protected]> Signed-off-by: Bjorn Helgaas <[email protected]> Reviewed-by: Mika Westerberg <[email protected]> Acked-by: Rafael J. Wysocki <[email protected]>
2016-09-13Merge branch 'x86-urgent-for-linus' of ↵Linus Torvalds3-7/+16
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Ingo Molnar: "Three fixes: - AMD microcode loading fix with randomization - an lguest tooling fix - and an APIC enumeration boundary condition fix" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/apic: Fix num_processors value in case of failure tools/lguest: Don't bork the terminal in case of wrong args x86/microcode/AMD: Fix load of builtin microcode with randomized memory
2016-09-13Merge branch 'sched-urgent-for-linus' of ↵Linus Torvalds1-0/+22
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull scheduler fix from Ingo Molnar: "A try_to_wake_up() memory ordering race fix causing a busy-loop in ttwu()" * 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: sched/core: Fix a race between try_to_wake_up() and a woken up task
2016-09-13Merge branch 'perf-urgent-for-linus' of ↵Linus Torvalds6-55/+180
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull perf fixes from Ingo Molnar: "This contains: - a set of fixes found by directed-random perf fuzzing efforts by Vince Weaver, Alexander Shishkin and Peter Zijlstra - a cqm driver crash fix - an AMD uncore driver use after free fix" * 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: perf/x86/intel: Fix PEBSv3 record drain perf/x86/intel/bts: Kill a silly warning perf/x86/intel/bts: Fix BTS PMI detection perf/x86/intel/bts: Fix confused ordering of PMU callbacks perf/core: Fix aux_mmap_count vs aux_refcount order perf/core: Fix a race between mmap_close() and set_output() of AUX events perf/x86/amd/uncore: Prevent use after free perf/x86/intel/cqm: Check cqm/mbm enabled state in event init perf/core: Remove WARN from perf_event_read()
2016-09-13Merge branch 'locking-urgent-for-linus' of ↵Linus Torvalds1-3/+4
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull locking fix from Ingo Molnar: "Another lockless_dereference() Sparse fix" * 'locking-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: locking/barriers: Don't use sizeof(void) in lockless_dereference()
2016-09-13Merge branch 'efi-urgent-for-linus' of ↵Linus Torvalds6-120/+283
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull EFI fixes from Ingo Molnar: "This contains a Xen fix, an arm64 fix and a race condition / robustization set of fixes related to ExitBootServices() usage and boundary conditions" * 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/efi: Use efi_exit_boot_services() efi/libstub: Use efi_exit_boot_services() in FDT efi/libstub: Introduce ExitBootServices helper efi/libstub: Allocate headspace in efi_get_memory_map() efi: Fix handling error value in fdt_find_uefi_params efi: Make for_each_efi_memory_desc_in_map() cope with running on Xen
2016-09-13Merge tag 'md/4.8-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/shli/mdLinus Torvalds3-41/+31
Pull MD fixes from Shaohua Li: "A few bug fixes for MD: - Guoqing fixed a bug compiling md-cluster in kernel - I fixed a potential deadlock in raid5-cache superblock write, a hang in raid5 reshape resume and a race condition introduced in rc4" * tag 'md/4.8-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/shli/md: raid5: fix a small race condition md-cluster: make md-cluster also can work when compiled into kernel raid5: guarantee enough stripes to avoid reshape hang raid5-cache: fix a deadlock in superblock write
2016-09-13Merge branch 'linus' of ↵Linus Torvalds1-2/+7
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6 Pull crypto bugfix from Herbert Xu: "Fix a bug in the cryptd code that may lead to crashes" * 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6: crypto: cryptd - initialize child shash_desc on import
2016-09-13irqchip/atmel-aic: Fix potential deadlock in ->xlate()Boris Brezillon2-4/+6
aic5_irq_domain_xlate() and aic_irq_domain_xlate() take the generic chip lock without disabling interrupts, which can lead to a deadlock if an interrupt occurs while the lock is held in one of these functions. Replace irq_gc_{lock,unlock}() calls by irq_gc_{lock_irqsave,unlock_irqrestore}() ones to prevent this bug from happening. Fixes: b1479ebb7720 ("irqchip: atmel-aic: Add atmel AIC/AIC5 drivers") Signed-off-by: Boris Brezillon <[email protected]> Acked-by: Marc Zyngier <[email protected]> Cc: Jason Cooper <[email protected]> Cc: Nicolas Ferre <[email protected]> Cc: [email protected] Cc: Alexandre Belloni <[email protected]> Link: http://lkml.kernel.org/r/1473775109-4192-2-git-send-email-boris.brezillon@free-electrons.com Signed-off-by: Thomas Gleixner <[email protected]>
2016-09-13genirq: Provide irq_gc_{lock_irqsave,unlock_irqrestore}() helpersBoris Brezillon1-0/+10
Some irqchip drivers need to take the generic chip lock outside of the irq context. Provide the irq_gc_{lock_irqsave,unlock_irqrestore}() helpers to allow one to disable irqs while entering a critical section protected by gc->lock. Note that we do not provide optimized version of these helpers for !SMP, because they are not called from the hot-path. [ tglx: Added a comment when these helpers should be [not] used ] Signed-off-by: Boris Brezillon <[email protected]> Cc: Jason Cooper <[email protected]> Cc: Marc Zyngier <[email protected]> Cc: Nicolas Ferre <[email protected]> Cc: [email protected] Cc: Alexandre Belloni <[email protected]> Link: http://lkml.kernel.org/r/1473775109-4192-1-git-send-email-boris.brezillon@free-electrons.com Signed-off-by: Thomas Gleixner <[email protected]>
2016-09-13Merge branch 'nvmf-4.8-rc' of git://git.infradead.org/nvme-fabrics into ↵Jens Axboe5-74/+83
for-linus Sagi writes: Here we have: - Kconfig dependencies fix from Arnd - nvme-rdma device removal fixes from Steve - possible bad deref fix from Colin