I rebased Kees' 'param: do not set store func without write perm'
on top of my 'params: cleanup sysfs allocation'.  However, my patch
uses krealloc which doesn't zero memory, leaving .store unset.

Reported-by: Sasha Levin <sasha.levin@oracle.com>
Cc: Kees Cook <keescook@chromium.org>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

The work queue couldn't reliably prevent the SW ring buffer from
overflowing, so dmesg was spammed by

 kfd kfd: Interrupt ring overflow, dropping interrupt.

messages when running e.g. the Atlantis Substance demo from
https://wiki.unrealengine.com/Linux_Demos on Kaveri.

Since the SW ring buffer doesn't actually do anything at this point, just
remove it for now. When actual interrupt processing code is added to
amdkfd, it should try to do things immediately and only defer to work
queues when necessary.

Signed-off-by: Michel Dänzer <michel.daenzer@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

We need to wait for the GPUVM flush to complete.  There
was some confusion as to how this mechanism was supposed
to work.  The operation is not atomic.  For GPU initiated
invalidations you need to read back a VM register to
introduce enough latency for the update to complete.

v2: drop gart changes
v3: just read back rather than polling

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

We need to wait for the GPUVM flush to complete.  There
was some confusion as to how this mechanism was supposed
to work.  The operation is not atomic.  For GPU initiated
invalidations you need to read back a VM register to
introduce enough latency for the update to complete.

v2: drop gart changes
v3: just read back rather than polling

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

We need to wait for the GPUVM flush to complete.  There
was some confusion as to how this mechanism was supposed
to work.  The operation is not atomic.  For GPU initiated
invalidations you need to read back a VM register to
introduce enough latency for the update to complete.

v2: drop gart changes
v3: just read back rather than polling

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Signed-off-by: Oded Gabbay <oded.gabbay@amd.com>

Disable dpm on certain problematic boards rather than
disabling dpm for the entire chip family since most
boards work fine.

https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1386534
https://bugzilla.kernel.org/show_bug.cgi?id=83731

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

This code is unnecessary, because same logic is already included. Refer
this mail thread[1] for detail.

[1] http://lists.freedesktop.org/archives/dri-devel/2015-January/075132.html

Signed-off-by: Hyungwon Hwang <human.hwang@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

GEN8+ HW has the option to route PM interrupts to either the CPU or to
GT. For GEN8 this was already set correctly to routing to CPU, but not
for GEN9, so fix this. Note that when disabling RPS interrupts this was
set already correctly, though in that case it didn't matter much except
for the possibility of spurious interrupts.

Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

In

commit dbea3ce
Author: Imre Deak <imre.deak@intel.com>
Date:   Mon Dec 15 18:59:28 2014 +0200

    drm/i915: sanitize RPS resetting during GPU reset

we disable RPS interrupts during GPU resetting, but don't apply the
necessary GEN6 HW workaround. This leads to a HW lockup during a
subsequent "looping batchbuffer" workload. This is triggered by the
testcase that submits exactly this kind of workload after a simulated
GPU reset. I'm not sure how likely the bug would have triggered
otherwise, since we would have applied the workaround anyway shortly
after the GPU reset, when enabling GT powersaving from the deferred
work.

This may also fix unrelated issues, since during driver loading /
suspending we also disable RPS interrupts and so we also had a short
window during the rest of the loading / resuming where a similar
workload could run without the workaround applied.

v2:
- separate the fix to route RPS interrupts to the CPU on GEN9 too
  to a separate patch (Daniel)

Bisected-by: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
Testcase: igt/gem_reset_stats/ban-ctx-render
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87429
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

We apply the RPS interrupt workaround on VLV everywhere except when
writing the mask directly during idling the GPU. For consistency do this
also there.

While at it also extend the code comment about affected platforms.
I couldn't reproduce the issue on VLV fixed by this workaround, by
removing the workaround from everywhere, while it's 100% reproducible on
SNB using igt/gem_reset_stats/ban-ctx-render. So also add a note that
it hasn't been verified if the workaround really applies to VLV/CHV.

Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Like Ivybridge, we have reports that we get random hangs when flipping
with multiple pipes. Extend

commit 2a92d5b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jul 8 10:40:29 2014 +0100

    drm/i915: Disable RCS flips on Ivybridge

to also apply to Haswell.

Reported-and-tested-by: Scott Tsai <scottt.tw@gmail.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87759
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: stable@vger.kernel.org # 2a92d5b drm/i915: Disable RCS flips on Ivybridge
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

If CONFIG_DEBUG_MUTEXES is set, the mutex->owner field is only cleared
if the mutex debugging is enabled which introduces a race in our
mutex_is_locked_by() - i.e. we may inspect the old owner value before it
is acquired by the new task.

This is the root cause of this error:

 diff --git a/kernel/locking/mutex-debug.c b/kernel/locking/mutex-debug.c
 index 5cf6731..3ef3736 100644
 --- a/kernel/locking/mutex-debug.c
 +++ b/kernel/locking/mutex-debug.c
 @@ -80,13 +80,13 @@ void debug_mutex_unlock(struct mutex *lock)
 			DEBUG_LOCKS_WARN_ON(lock->owner != current);

 		DEBUG_LOCKS_WARN_ON(!lock->wait_list.prev && !lock->wait_list.next);
 -		mutex_clear_owner(lock);
 	}

 	/*
 	 * __mutex_slowpath_needs_to_unlock() is explicitly 0 for debug
 	 * mutexes so that we can do it here after we've verified state.
 	 */
 +	mutex_clear_owner(lock);
 	atomic_set(&lock->count, 1);
  }

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=87955
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>

Currently restore_user_regs deallocates the SVC stack early in
its execution and relies on no exception being taken between
the deallocation and the registers being restored. The introduction
of a default FIQ handler that also uses the SVC stack breaks this
assumption and can result in corrupted register state.

This patch works around the problem by removing the early
stack deallocation and using r2 as a temporary instead. I have
not found a way to do this without introducing an extra mov
instruction to the macro.

Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

If the overflow threshold for a counter is set above or near the
0xffffffff boundary then the kernel may lose track of the overflow
causing only events that occur *after* the overflow to be recorded.
Specifically the problem occurs when the value of the performance counter
overtakes its original programmed value due to wrap around.

Typical solutions to this problem are either to avoid programming in
values likely to be overtaken or to treat the overflow bit as the 33rd
bit of the counter.

Its somewhat fiddly to refactor the code to correctly handle the 33rd bit
during irqsave sections (context switches for example) so instead we take
the simpler approach of avoiding values likely to be overtaken.

We set the limit to half of max_period because this matches the limit
imposed in __hw_perf_event_init(). This causes a doubling of the interrupt
rate for large threshold values, however even with a very fast counter
ticking at 4GHz the interrupt rate would only be ~1Hz.

Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Acked-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

Signed-off-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

This adds a quirks list to fix stability problems with
certain SI boards.

bug:
https://bugs.freedesktop.org/show_bug.cgi?id=76490

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

…able

The regex matching on of_get_property and of_match_table cause Grant and
me to be copied on loads of drivers as well as be listed as maintainers
of those drivers. I believe the intent here was to check for documenting
of properties, but that has proven horribly ineffective. checkpatch now
at least partially covers this checking compatible strings. So remove
these regex's to reduce the firehose somewhat.

Cc: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>

Per Grant, secretlab.ca is defunct and he has moved his tree to
kernel.org so update the DT website and git tree. devicetree.org needs
work, but is better than "Internal Server Error" that secretlab.ca
returns.

Cc: Grant Likely <grant.likely@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>

Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be>
Cc: Stephen Warren <swarren@nvidia.com>
Cc: Rob Herring <robh+dt@kernel.org>
Signed-off-by: Rob Herring <robh@kernel.org>

Current vendor-prefixes.txt already has "ak" prefix for Asahi Kasei Corp
by ae8c420(of: Add vendor prefix for Asahi Kasei Corp.)

It went through the appropriate review process. But, almost all
Asahi Kasei chip drivers are using "asahi-kasei" prefix today.
(arch/arm/boot/dts/tegra20-seaboard.dts only is using "ak,ak8975",
 but there are instances of "asahi-kasei,ak8975" in other dts files.
 And drivers/iio/magnetometer/ak8975.c doesn't support "ak,ak8975" prefix)
So, we made a mistake there.

In addition, checkpatch.pl reports WARNING if it is using "asahi-kasei"
prerfix in DT file.
(DT compatible string vendor "asahi-kasei" appears un-documented)

Marking it deprecated and warning with checkpatch is certainly
preferable. So, this patch replace "ak" to "asahi-kasei" in
vendor-prefixes.txt. (and fixup tegra20-seaboard)

OTOH, Asahi Kasei is usually referred to as "AKM", but this patch
doesn't care about it. Because no DT is using that today.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Rob Herring <robh@kernel.org>

fix the dev_dbg to display the offset which is the calculated
dma_pfn_offset value and set later in the code.

Signed-off-by: Murali Karicheri <m-karicheri2@ti.com>
Signed-off-by: Rob Herring <robh@kernel.org>

Just fix a minor typo about the example path.

Signed-off-by: Kaixu Xia <xiakaixu@huawei.com>
Acked-by: Philipp Zabel <p.zabel@pengutronix.de>
Signed-off-by: Rob Herring <robh@kernel.org>

Peter Maydell suggested that we describe new devices / DTB nodes in the
kernel Documentation tree that we expose to arm "virt" guests in QEMU.

Although the kernel is not required to access the fw_cfg interface,
"Documentation/devicetree/bindings/arm" is probably the best central spot
to keep the fw_cfg description in.

Suggested-by: Peter Maydell <peter.maydell@linaro.org>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>

The QEMU open source machine emulator and virtualizer presents firmware
and operating systems running in virtual machines ("guests") with purely
virtual hardware (ie. hardware that has never existed in physical form).
Since QEMU exposes some of these devices in a DTB, it makes sense to
define "qemu" and "virtio" as vendor prefixes.

The qemu definition is from [1], revision 4451 (22:24, 25 November 2014).

The virtio definition is composed from [2] and [3].

[1] http://wiki.qemu.org/Main_Page
[2] http://docs.oasis-open.org/virtio/virtio/v1.0/csprd01/virtio-v1.0-csprd01.html
[3] http://en.wikipedia.org/wiki/OASIS_%28organization%29

Suggested-by: Mark Rutland <mark.rutland@arm.com>
Suggested-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Mark Rutland <mark.rutland@arm.com>
Signed-off-by: Rob Herring <robh@kernel.org>

Currently the signed COMPARE HALFWORD IMMEDIATE (chi) and COMPARE (c)
instructions are used to compare "A" with "K". This is not correct
because "A" and "K" are both unsigned. To fix this remove the
chi instruction (no unsigned analogon available) and use the
unsigned COMPARE LOGICAL (cl) instruction instead of COMPARE (c).

Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

The skb_copy_bits() function has the following signature:
int skb_copy_bits(const struct sk_buff *skb, int offset, void *to, int len)

Currently in bpf_jit.S the "to" and "len" parameters have been
exchanged. So fix this and call the function with the correct
parameters.

Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

Currently the offset parameter for skb_copy_bits is changed in
sk_load_word() and sk_load_half(). Therefore it is not correct when
calling skb_copy_bits(). Fix this and use the original offset
for the function call.

Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

In sk_load_byte_msh() sk_load_byte_slow() is called instead of
sk_load_byte_msh_slow(). Fix this and call the correct function.

Besides of this load only one byte instead of two and fix the comment.

Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

The s390x ABI requires to zero extend parameters before functions
are called.

Signed-off-by: Michael Holzheu <holzheu@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

This was accidently lost in 76a0df8.

Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

Enable a mechanism for devices to quirk that they do not behave when
doing a PCI bus reset.  We require a modest level of spec compliant
behavior in order to do a reset, for instance the device should come
out of reset without throwing errors and PCI config space should be
accessible after reset.  This is too much to ask for some devices.

Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.14+

Reports against the TL-WDN4800 card indicate that PCI bus reset of this
Atheros device cause system lock-ups and resets.  I've also been able to
confirm this behavior on multiple systems.  The device never returns from
reset and attempts to access config space of the device after reset result
in hangs.  Blacklist bus reset for the device to avoid this issue.

[bhelgaas: This regression appeared in v3.14.  Andreas bisected it to
425c1b2 ("PCI: Add Virtual Channel to save/restore support"), but we
don't understand the mechanism by which that commit affects the reset
path.]

[bhelgaas: changelog, references]
Link: http://lkml.kernel.org/r/20140923210318.498dacbd@dualc.maya.org
Reported-by: Andreas Hartmann <andihartmann@freenet.de>
Tested-by: Andreas Hartmann <andihartmann@freenet.de>
Signed-off-by: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.14+

pci_setup_bridge_io(), pci_setup_bridge_mmio(), and
pci_setup_bridge_mmio_pref() program the windows of PCI-PCI bridges.
Previously they accepted a pointer to the pci_bus of the secondary bus,
then looked up the bridge leading to that bus.  Pass the bridge directly,
which will make it more convenient for future callers.

No functional change.

[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.16+

Add pci_bus_clip_resource().  If a PCI-PCI bridge window overlaps an
upstream bridge window but is not completely contained by it, this clips
the downstream window so it fits inside the upstream one.

No functional change (this adds the function but no callers).

[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.16+

Add pci_claim_bridge_resource() to claim a PCI-PCI bridge window.  This is
like regular pci_claim_resource(), except that if we fail to claim the
window, we check to see if we can reduce the size of the window and try
again.

This is for scenarios like this:

  pci_bus 0000:00: root bus resource [mem 0xc0000000-0xffffffff]
  pci 0000:00:01.0:   bridge window [mem 0xbdf00000-0xddefffff 64bit pref]
  pci 0000:01:00.0: reg 0x10: [mem 0xc0000000-0xcfffffff pref]

The 00:01.0 window is illegal: it starts before the host bridge window, so
we have to assume the [0xbdf00000-0xbfffffff] region is inaccessible.  We
can make it legal by clipping it to [mem 0xc0000000-0xddefffff 64bit pref].

Previously we discarded the 00:01.0 window and tried to reassign that part
of the hierarchy from scratch.  That is a problem because Linux doesn't
always assign things optimally.  For example, in this case, BIOS put the
01:00.0 device in a prefetchable window below 4GB, but after 5b28541,
Linux puts the prefetchable window above 4GB where the 32-bit 01:00.0
device can't use it.

Clipping the 00:01.0 window is less intrusive than completely reassigning
things and is sufficient to let us use most of the BIOS configuration.  Of
course, it's possible that devices below 00:01.0 will no longer fit.  If
that's the case, we'll have to reassign things.  But that's a separate
problem.

[bhelgaas: changelog, split into separate patch]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: stable@vger.kernel.org	# v3.16+

Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge.  If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Tested-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Ingo Molnar <mingo@redhat.com>
CC: "H. Peter Anvin" <hpa@zytor.com>
CC: x86@kernel.org
CC: stable@vger.kernel.org	# v3.16+

Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge.  If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Richard Henderson <rth@twiddle.net>
CC: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
CC: Matt Turner <mattst88@gmail.com>
CC: linux-alpha@vger.kernel.org

Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge.  If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: David Howells <dhowells@redhat.com>
CC: Paul Gortmaker <paul.gortmaker@windriver.com>

Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge.  If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Tony Luck <tony.luck@intel.com>
CC: Fenghua Yu <fenghua.yu@intel.com>
CC: "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>
CC: linux-ia64@vger.kernel.org

Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge.  If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Michal Simek <monstr@monstr.eu>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Sebastian Ott <sebott@linux.vnet.ibm.com>

Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge.  If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: David Howells <dhowells@redhat.com>
CC: Koichi Yasutake <yasutake.koichi@jp.panasonic.com>
CC: linux-am33-list@redhat.com

Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge.  If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: "James E.J. Bottomley" <jejb@parisc-linux.org>
CC: Helge Deller <deller@gmx.de>
CC: linux-parisc@vger.kernel.org

Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge.  If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
CC: Benjamin Herrenschmidt <benh@kernel.crashing.org>
CC: Paul Mackerras <paulus@samba.org>
CC: Michael Ellerman <mpe@ellerman.id.au>
CC: Gavin Shan <gwshan@linux.vnet.ibm.com>
CC: Anton Blanchard <anton@samba.org>
CC: Sebastian Ott <sebott@linux.vnet.ibm.com>
CC: Wei Yang <weiyang@linux.vnet.ibm.com>
CC: Andrew Murray <amurray@embedded-bits.co.uk>
CC: linuxppc-dev@lists.ozlabs.org

Every PCI-PCI bridge window should fit inside an upstream bridge window
because orphaned address space is unreachable from the primary side of the
upstream bridge.  If we inherit invalid bridge windows that overlap an
upstream window from firmware, clip them to fit and update the bridge
accordingly.

[bhelgaas: changelog]
Link: https://bugzilla.kernel.org/show_bug.cgi?id=85491
Reported-by: Marek Kordik <kordikmarek@gmail.com>
Fixes: 5b28541 ("PCI: Restrict 64-bit prefetchable bridge windows to 64-bit resources")
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: David S. Miller <davem@davemloft.net>
CC: Paul Gortmaker <paul.gortmaker@windriver.com>
CC: Yijing Wang <wangyijing@huawei.com>
CC: Sam Ravnborg <sam@ravnborg.org>
CC: sparclinux@vger.kernel.org

There are several devices that expect to receive MIDI data only in the
first eight data blocks of a packet.  If the driver restricts the data
rate to the allowed rate (as mandated by the specification, but not yet
implemented by this driver), this happens naturally.  Therefore, there
is no reason to ever try to use more data packets with any device.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Do no send MIDI bytes at the full rate at which FireWire packets happen
to be sent, but restrict them to the actual rate of a real MIDI port.
This is required by the specification, and prevents data loss when the
device's buffer overruns.

Signed-off-by: Clemens Ladisch <clemens@ladisch.de>
Reviewed-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Tested-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

This fixes reset codes to support memory mapped hdmi phy as well as hdmi
phy dedicated i2c lines.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

In booting, we can see a below message.

[    3.241728] exynos-mixer 14450000.mixer: Unbalanced pm_runtime_enable!

Already pm_runtime_enable is called by probe function. Remove
pm_runtime_enable/disable from mixer_bind and mixer_unbind.

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

Prevented re-enabling the vblank interrupt by drm_vblank_off and
drm_vblank_get from mixer_wait_for_vblank returns error after
drm_vblank_off. We get below warnings without this error handling
because vblank reference count is mismatched by above sequence.

setting mode 1920x1080-60Hz@XR24 on connectors 16, crtc 13
[   19.900793] ------------[ cut here ]------------
[   19.903959] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/drm_irq.c:1072 exynos_drm_crtc_finish_pageflip+0xac/0xdc()
[   19.914076] Modules linked in:
[   19.917116] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.19.0-rc4-00040-g3d729789-dirty #46
[   19.925342] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
[   19.931437] [<c0014430>] (unwind_backtrace) from [<c001158c>] (show_stack+0x10/0x14)
[   19.939131] [<c001158c>] (show_stack) from [<c04cdd50>] (dump_stack+0x84/0xc4)
[   19.946329] [<c04cdd50>] (dump_stack) from [<c00226f4>] (warn_slowpath_common+0x80/0xb0)
[   19.954382] [<c00226f4>] (warn_slowpath_common) from [<c00227c0>] (warn_slowpath_null+0x1c/0x24)
[   19.963132] [<c00227c0>] (warn_slowpath_null) from [<c02c20cc>] (exynos_drm_crtc_finish_pageflip+0xac/0xdc)
[   19.972841] [<c02c20cc>] (exynos_drm_crtc_finish_pageflip) from [<c02cb7ec>] (mixer_irq_handler+0xdc/0x104)
[   19.982546] [<c02cb7ec>] (mixer_irq_handler) from [<c005c904>] (handle_irq_event_percpu+0x78/0x134)
[   19.991555] [<c005c904>] (handle_irq_event_percpu) from [<c005c9fc>] (handle_irq_event+0x3c/0x5c)
[   20.000395] [<c005c9fc>] (handle_irq_event) from [<c005f384>] (handle_fasteoi_irq+0xe0/0x1ac)
[   20.008885] [<c005f384>] (handle_fasteoi_irq) from [<c005bf88>] (generic_handle_irq+0x2c/0x3c)
[   20.017463] [<c005bf88>] (generic_handle_irq) from [<c005c254>] (__handle_domain_irq+0x7c/0xec)
[   20.026128] [<c005c254>] (__handle_domain_irq) from [<c0008698>] (gic_handle_irq+0x30/0x68)
[   20.034449] [<c0008698>] (gic_handle_irq) from [<c00120c0>] (__irq_svc+0x40/0x74)
[   20.041893] Exception stack(0xc06fff68 to 0xc06fffb0)
[   20.046923] ff60:                   00000000 00000000 000052f6 c001b460 c06fe000 c07064e8
[   20.055070] ff80: c04d743c c07392a2 c0739440 c06da340 ef7fca80 00000000 01000000 c06fffb0
[   20.063212] ffa0: c000f24c c000f250 60000013 ffffffff
[   20.068245] [<c00120c0>] (__irq_svc) from [<c000f250>] (arch_cpu_idle+0x38/0x3c)
[   20.075611] [<c000f250>] (arch_cpu_idle) from [<c0050948>] (cpu_startup_entry+0x108/0x16c)
[   20.083846] [<c0050948>] (cpu_startup_entry) from [<c06aec5c>] (start_kernel+0x3a0/0x3ac)
[   20.091980] ---[ end trace 2c76ee0500489d1b ]---

Signed-off-by: Joonyoung Shim <jy0922.shim@samsung.com>
Signed-off-by: Inki Dae <inki.dae@samsung.com>

Signed-off-by: Jason Lee Cragg <jcragg@gmail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

sparse complains about
include/trace/events/kvm.h:163:1: error: directive in argument list
include/trace/events/kvm.h:167:1: error: directive in argument list
include/trace/events/kvm.h:169:1: error: directive in argument list
and sparse is right. Preprocessing directives in an argument of a
macro are undefined behaviour as of C99 6.10.3p11.

Lets use an indirection to fix this.

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Compiling SH with gcc-4.8 fails due to the -m32 option not being
supported.

From http://buildd.debian-ports.org/status/fetch.php?pkg=linux&arch=sh4&ver=3.16.7-ckt4-1&stamp=1421425783

      CC      init/main.o
    gcc-4.8: error: unrecognized command line option '-m32'
    ld: cannot find init/.tmp_mc_main.o: No such file or directory
    objcopy: 'init/.tmp_mx_main.o': No such file
    rm: cannot remove 'init/.tmp_mx_main.o': No such file or directory
    rm: cannot remove 'init/.tmp_mc_main.o': No such file or directory

Link: http://lkml.kernel.org/r/1421537778-29001-1-git-send-email-kernel@mkarcher.dialup.fu-berlin.de
Link: http://lkml.kernel.org/r/54BCBDD4.10102@physik.fu-berlin.de

Cc: stable@vger.kernel.org
Cc: Matt Fleming <matt@console-pimps.org>
Reported-by: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Signed-off-by: Michael Karcher <kernel@mkarcher.dialup.fu-berlin.de>
Signed-off-by: Steven Rostedt <rostedt@goodmis.org>

The version merged to 3.19 did not handle errors from start_trancaction
and could pass an invalid pointer to commit_transaction.

Fixes: 6b5fe46 ("btrfs: do commit in sync_fs if there are pending changes")
Reported-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>

The address that should be freed is not 'ppath' but 'path'.

Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
Reviewed-by: Miao Xie <miaoxie@huawei.com>
Signed-off-by: Chris Mason <clm@fb.com>

When removing a block group we were deleting it from its space_info's
ro_bgs list without the correct protection - the space info's spinlock.
Fix this by doing the list delete while holding the spinlock of the
corresponding space info, which is the correct lock for any operation
on that list.

This issue was introduced in the 3.19 kernel by the following change:

    Btrfs: move read only block groups onto their own list V2
    commit 633c0aa

I ran into a kernel crash while a task was running statfs, which iterates
the space_info->ro_bgs list while holding the space info's spinlock,
and another task was deleting it from the same list, without holding that
spinlock, as part of the block group remove operation (while running the
function btrfs_remove_block_group). This happened often when running the
stress test xfstests/generic/038 I recently made.

Signed-off-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Chris Mason <clm@fb.com>

Suppress the following warning displayed on building 32bit (i686) kernel.

===============================================================================
...
   CC [M]  fs/btrfs/extent_io.o
fs/btrfs/extent_io.c: In function ‘btrfs_free_io_failure_record’:
fs/btrfs/extent_io.c:2193:13: warning: cast to pointer from integer of
different size [-Wint-to-pointer-cast]
    failrec = (struct io_failure_record *)state->private;
...
===============================================================================

Signed-off-by: Satoru Takeuchi <takeuchi_satoru@jp.fujitsu.com>
Reported-by: Chris Murphy <chris@colorremedies.com>
Signed-off-by: Chris Mason <clm@fb.com>

ignore_lockdep is uninitialized, and sysfs_attr_init() doesn't initialize
it, so memset to 0.

Reported-by: Huang Ying <ying.huang@intel.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

…init freed.

Archs have been abusing module_free() to clean up their arch-specific
allocations.  Since module_free() is also (ab)used by BPF and trace code,
let's keep it to simple allocations, and provide a hook called before
that.

This means that avr32, ia64, parisc and s390 no longer need to implement
their own module_free() at all.  avr32 doesn't need module_finalize()
either.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Cc: Chris Metcalf <cmetcalf@ezchip.com>
Cc: Haavard Skinnemoen <hskinnemoen@gmail.com>
Cc: Hans-Christian Egtvedt <egtvedt@samfundet.no>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Fenghua Yu <fenghua.yu@intel.com>
Cc: "James E.J. Bottomley" <jejb@parisc-linux.org>
Cc: Helge Deller <deller@gmx.de>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-ia64@vger.kernel.org
Cc: linux-parisc@vger.kernel.org
Cc: linux-s390@vger.kernel.org

Nothing needs the module pointer any more, and the next patch will
call it from RCU, where the module itself might no longer exist.
Removing the arg is the safest approach.

This just codifies the use of the module_alloc/module_free pattern
which ftrace and bpf use.

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Cc: Mikael Starvik <starvik@axis.com>
Cc: Jesper Nilsson <jesper.nilsson@axis.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Ley Foon Tan <lftan@altera.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Chris Metcalf <cmetcalf@ezchip.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: x86@kernel.org
Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
Cc: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: linux-cris-kernel@axis.com
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: nios2-dev@lists.rocketboards.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: sparclinux@vger.kernel.org
Cc: netdev@vger.kernel.org

The kallsyms routines (module_symbol_name, lookup_module_* etc) disable
preemption to walk the modules rather than taking the module_mutex:
this is because they are used for symbol resolution during oopses.

This works because there are synchronize_sched() and synchronize_rcu()
in the unload and failure paths.  However, there's one case which doesn't
have that: the normal case where module loading succeeds, and we free
the init section.

We don't want a synchronize_rcu() there, because it would slow down
module loading: this bug was introduced in 2009 to speed module
loading in the first place.

Thus, we want to do the free in an RCU callback.  We do this in the
simplest possible way by allocating a new rcu_head: if we put it in
the module structure we'd have to worry about that getting freed.

Reported-by: Rui Xiang <rui.xiang@huawei.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

As dts files have been reorganised under vendor subdirs, dtb files
cannot be removed with "make distclean" now. Thus, this patch moves
dtb files under archclean rule and removes unnecessary entries.

Cc: Robert Richter <rrichter@cavium.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Jungseok Lee <jungseoklee85@gmail.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

Allow multiple DA9052 regulators be registered by registering with
PLATFORM_DEVID_AUTO instead of PLATFORM_DEVID_NONE.

The subdevices are currently registered with PLATFORM_DEVID_NONE, which
will cause a name collision on the platform bus when multiple regulators
are registered:

[    0.128855] da9052-regulator da9052-regulator: invalid regulator ID specified
[    0.128973] da9052-regulator: probe of da9052-regulator failed with error -22
[    0.129148] ------------[ cut here ]------------
[    0.129200] WARNING: CPU: 0 PID: 1 at fs/sysfs/dir.c:31 sysfs_warn_dup+0x5c/0x7c()
[    0.129233] sysfs: cannot create duplicate filename '/devices/platform/soc/60000000.aips/63fc8000.i2c/i2c-0/0-0048/da9052-regulator
...
[    0.132891] ------------[ cut here ]------------
[    0.132924] WARNING: CPU: 0 PID: 1 at lib/kobject.c:240 kobject_add_internal+0x24c/0x2cc()
[    0.132957] kobject_add_internal failed for da9052-regulator with -EEXIST, don't try to register things with the same name in the same directory.
...
[    0.137000] da9052 0-0048: mfd_add_devices failed: -17
[    0.138486] da9052: probe of 0-0048 failed with error -17

Based on the fix done by Johan Hovold at commit b668422 ("mfd:
viperboard: Fix platform-device id collision").

Tested on a imx53-qsb board, where multiple DA9053 regulators can be
successfully probed.

Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

STATUS register can be modified by the HW, so we
should bypass cache because of that.

In the case of INT[12] registers, they are the ones
that actually clear the IRQ source at the time they
are read. If we rely on the cache for them, we will
never be able to clear the interrupt, which will cause
our IRQ line to be disabled due to IRQ throttling.

Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

If we don't tell regmap-irq that our first status
register is at offset 1, it will try to read offset
zero, which is the chipid register.

Fixes: 44b4dc6 mfd: tps65218: Add driver for the TPS65218 PMIC
Cc: <stable@vger.kernel.org> # v3.15+
Signed-off-by: Felipe Balbi <balbi@ti.com>
Signed-off-by: Lee Jones <lee.jones@linaro.org>

sd_set_power_mode() in derived module drivers/mmc/host/rtsx_usb_sdmmc.c
acquires dev_mutex and then calls pm_runtime_get_sync() to make sure the
device is awake while initializing a newly inserted card. Once it is
called during suspending state and explicitly before rtsx_usb_suspend()
acquires the same dev_mutex, both routine deadlock and further hang the
driver because pm_runtime_get_sync() waits the pending PM operations.

Fix this by using an empty suspend method. mmc_core always turns the
LED off after a request is done and thus it is ok to remove the only
rtsx_usb_turn_off_led() here.

Cc: <stable@vger.kernel.org> # v3.16+
Fixes: 730876b ("mfd: Add realtek USB card reader driver")
Signed-off-by: Roger Tseng <rogerable@realtek.com>
[Lee: Removed newly unused variable]
Signed-off-by: Lee Jones <lee.jones@linaro.org>

…linux into drm-fixes

Some radeon fixes for 3.19:
    - GPUVM stability fixes
    - SI dpm quirks
    - Regression fixes

* 'drm-fixes-3.19' of git://people.freedesktop.org/~agd5f/linux:
  drm/radeon: use rv515_ring_start on r5xx
  drm/radeon: add si dpm quirk list
  drm/radeon: don't print error on -ERESTARTSYS
  drm/radeon: add a dpm quirk list
  drm/radeon: fix VM flush on CIK (v3)
  drm/radeon: fix VM flush on SI (v3)
  drm/radeon: fix VM flush on cayman/aruba (v3)

…/kernel/git/daeinki/drm-exynos into drm-fixes

This pull request includes below fixups,

- Remove duplicated machine checking.
  . It seems that this code was added when you merged 'v3.18-rc7' into
    drm-next. commit id : e8115e7
- Fix hdmiphy reset.
  . Exynos hdmi has two interfaces to control hdmyphy, one is I2C, other
    is APB bus - memory mapped I/O. So this patch makes hdmiphy reset
    to be done according to interfaces, I2C or APB bus.
- And add some exception codes.

* 'exynos-drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos:
  drm/exynos: fix warning of vblank reference count
  drm/exynos: remove unnecessary runtime pm operations
  drm/exynos: fix reset codes for memory mapped hdmi phy
  drm/exynos: remove the redundant machine checking code

There are still some places in the fb helper that need to avoid
sleeping in panic context. Here's an example:

[   65.615496] bad: scheduling from the idle thread!
[   65.620747] CPU: 92 PID: 0 Comm: swapper/92 Tainted: G   M        E  3.18.0-rc4-7-default+ #20

[   65.630364] Hardware name: Intel Corporation BRICKLAND/BRICKLAND, BIOS
BRHSXSD1.86B.0056.R01.1409242327 09/24/2014
[   65.641923]  ffff88087f693d80 ffff88087f689878 ffffffff81566db9 0000000000000000
[   65.650226]  ffff88087f693d80 ffff88087f689898 ffffffff810871ff ffff88046eb3e0d0
[   65.658527]  ffff88087f693d80 ffff88087f6898c8 ffffffff8107c1fa 000000017f6898b8
[   65.666830] Call Trace:
[   65.669557]  <#MC>  [<ffffffff81566db9>] dump_stack+0x46/0x58
[   65.675994]  [<ffffffff810871ff>] dequeue_task_idle+0x2f/0x40
[   65.682412]  [<ffffffff8107c1fa>] dequeue_task+0x5a/0x80
[   65.688345]  [<ffffffff810804f3>] deactivate_task+0x23/0x30
[   65.694569]  [<ffffffff81569050>] __schedule+0x580/0x7f0
[   65.700502]  [<ffffffff81569739>] schedule_preempt_disabled+0x29/0x70
[   65.707696]  [<ffffffff8156abb6>] __ww_mutex_lock_slowpath+0xb8/0x162
[   65.714891]  [<ffffffff8156acb3>] __ww_mutex_lock+0x53/0x85
[   65.721125]  [<ffffffffa00b3a5d>] drm_modeset_lock+0x3d/0x110 [drm]
[   65.728132]  [<ffffffffa00b3c2a>] __drm_modeset_lock_all+0x8a/0x120 [drm]
[   65.735721]  [<ffffffffa00b3cd0>] drm_modeset_lock_all+0x10/0x30 [drm]
[   65.743015]  [<ffffffffa01af8bf>] drm_fb_helper_pan_display+0x2f/0xf0 [drm_kms_helper]
[   65.751857]  [<ffffffff8132bd21>] fb_pan_display+0xd1/0x1a0
[   65.758081]  [<ffffffff81326010>] bit_update_start+0x20/0x50
[   65.764400]  [<ffffffff813259f2>] fbcon_switch+0x3a2/0x550
[   65.770528]  [<ffffffff813a01c9>] redraw_screen+0x189/0x240
[   65.776750]  [<ffffffff81322f8a>] fbcon_blank+0x20a/0x2d0
[   65.782778]  [<ffffffff8137d359>] ? erst_writer+0x209/0x330
[   65.789002]  [<ffffffff810ba2f3>] ? internal_add_timer+0x63/0x80
[   65.795710]  [<ffffffff810bc137>] ? mod_timer+0x127/0x1e0
[   65.801740]  [<ffffffff813a0cd8>] do_unblank_screen+0xa8/0x1d0
[   65.808255]  [<ffffffff813a0e10>] unblank_screen+0x10/0x20
[   65.814381]  [<ffffffff812ca0d9>] bust_spinlocks+0x19/0x40
[   65.820508]  [<ffffffff81561ca7>] panic+0x106/0x1f5
[   65.825955]  [<ffffffff8102336c>] mce_panic+0x2ac/0x2e0
[   65.831789]  [<ffffffff812c796a>] ? delay_tsc+0x4a/0x80
[   65.837625]  [<ffffffff81024e1f>] do_machine_check+0xbaf/0xbf0
[   65.844138]  [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
[   65.850166]  [<ffffffff8156f03f>] machine_check+0x1f/0x30
[   65.856195]  [<ffffffff813365d7>] ? intel_idle+0xc7/0x150
[   65.862222]  <<EOE>>  [<ffffffff814283d5>] cpuidle_enter_state+0x55/0x170
[   65.869823]  [<ffffffff814285a7>] cpuidle_enter+0x17/0x20
[   65.875852]  [<ffffffff81097b08>] cpu_startup_entry+0x2d8/0x370
[   65.882467]  [<ffffffff8102fe29>] start_secondary+0x159/0x180

There's __drm_modeset_lock_all() which Daniel Vetter introduced for this
purpose. We can leverage that without reinventing anything. This patch
works with the latest kernel.

Reviewed-by: Rob Clark <robdclark@gmail.com>
Tested-by: Tony Luck <tony.luck@intel.com>
Signed-off-by: Rui Wang <rui.y.wang@intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>

…rg/drm-intel into drm-fixes

misc i915 fixes

* tag 'drm-intel-fixes-2015-01-15' of git://anongit.freedesktop.org/drm-intel:
  drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES
  drm/i915: Ban Haswell from using RCS flips
  drm/i915: vlv: sanitize RPS interrupt mask during GPU idling
  drm/i915: fix HW lockup due to missing RPS IRQ workaround on GEN6
  drm/i915: gen9: fix RPS interrupt routing to CPU vs. GT

…rg/~gabbayo/linux into drm-fixes

- Remove the interrupt SW ring buffer impl. as it is not used by any module
  in amdkfd.

- Fix a sparse warning

* tag 'drm-amdkfd-fixes-2015-01-13' of git://people.freedesktop.org/~gabbayo/linux:
  drm/amdkfd: Fix sparse warning (different address space)
  drm/amdkfd: Drop interrupt SW ring buffer

Fs_info->pending_changes is never cleared since the original code uses
cmpxchg(&fs_info->pending_changes, 0, 0), which will only clear it if
pending_changes is already 0.

This will cause a lot of problem when mount it with inode_cache mount
option.
If the btrfs is mounted as inode_cache, pending_changes will always be
1, even when the fs is frozen.

Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
Reviewed-by: David Sterba <dsterba@suse.cz>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>

…dlock.

Commit 6b5fe46 (btrfs: do commit in sync_fs if there are pending
changes) will call btrfs_start_transaction() in sync_fs(), to handle
some operations needed to be done in next transaction.

However this can cause deadlock if the filesystem is frozen, with the
following sys_r+w output:
[  143.255932] Call Trace:
[  143.255936]  [<ffffffff816c0e09>] schedule+0x29/0x70
[  143.255939]  [<ffffffff811cb7f3>] __sb_start_write+0xb3/0x100
[  143.255971]  [<ffffffffa040ec06>] start_transaction+0x2e6/0x5a0
[btrfs]
[  143.255992]  [<ffffffffa040f1eb>] btrfs_start_transaction+0x1b/0x20
[btrfs]
[  143.256003]  [<ffffffffa03dc0ba>] btrfs_sync_fs+0xca/0xd0 [btrfs]
[  143.256007]  [<ffffffff811f7be0>] sync_fs_one_sb+0x20/0x30
[  143.256011]  [<ffffffff811cbd01>] iterate_supers+0xe1/0xf0
[  143.256014]  [<ffffffff811f7d75>] sys_sync+0x55/0x90
[  143.256017]  [<ffffffff816c49d2>] system_call_fastpath+0x12/0x17
[  143.256111] Call Trace:
[  143.256114]  [<ffffffff816c0e09>] schedule+0x29/0x70
[  143.256119]  [<ffffffff816c3405>] rwsem_down_write_failed+0x1c5/0x2d0
[  143.256123]  [<ffffffff8133f013>] call_rwsem_down_write_failed+0x13/0x20
[  143.256131]  [<ffffffff811caae8>] thaw_super+0x28/0xc0
[  143.256135]  [<ffffffff811db3e5>] do_vfs_ioctl+0x3f5/0x540
[  143.256187]  [<ffffffff811db5c1>] SyS_ioctl+0x91/0xb0
[  143.256213]  [<ffffffff816c49d2>] system_call_fastpath+0x12/0x17

The reason is like the following:
(Holding s_umount)
VFS sync_fs staff:
|- btrfs_sync_fs()
   |- btrfs_start_transaction()
      |- sb_start_intwrite()
      (Waiting thaw_fs to unfreeze)
					VFS thaw_fs staff:
					thaw_fs()
					(Waiting sync_fs to release
					 s_umount)

So deadlock happens.
This can be easily triggered by fstest/generic/068 with inode_cache
mount option.

The fix is to check if the fs is frozen, if the fs is frozen, just
return and waiting for the next transaction.

Cc: David Sterba <dsterba@suse.cz>
Reported-by: Gui Hecheng <guihc.fnst@cn.fujitsu.com>
Signed-off-by: Qu Wenruo <quwenruo@cn.fujitsu.com>
[enhanced comment, changed to SB_FREEZE_WRITE]
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: Chris Mason <clm@fb.com>

…el/git/lee/mfd

Pull MFD fixes from Lee Jones:
 - Avoid platform ID collision in da9052
 - Skip caching volatile registers in tps65218
 - Use correct address base in tps65218
 - Repair deadlock on suspend in rtsx_usb

* tag 'mfd-fixes-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/lee/mfd:
  mfd: rtsx_usb: Fix runtime PM deadlock
  mfd: tps65218: Make INT1 our status_base register
  mfd: tps65218: Make INT[12] and STATUS registers volatile
  mfd: da9052-core: Fix platform-device id collision

Pull drm fixes from Dave Airlie:
 "Just back from LCA + some days off, had some fixes from the past 2 weeks,

  Some amdkfd code removal for a feature that wasn't ready, otherwise
  just one fix for core helper sleeping, exynos, i915, and radeon fixes.

  I thought I had some sti fixes but they were already in, and it
  confused me for a few mins this morning"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm: fb helper should avoid sleeping in panic context
  drm/exynos: fix warning of vblank reference count
  drm/exynos: remove unnecessary runtime pm operations
  drm/exynos: fix reset codes for memory mapped hdmi phy
  drm/radeon: use rv515_ring_start on r5xx
  drm/radeon: add si dpm quirk list
  drm/radeon: don't print error on -ERESTARTSYS
  drm/i915: Fix mutex->owner inspection race under DEBUG_MUTEXES
  drm/i915: Ban Haswell from using RCS flips
  drm/i915: vlv: sanitize RPS interrupt mask during GPU idling
  drm/i915: fix HW lockup due to missing RPS IRQ workaround on GEN6
  drm/i915: gen9: fix RPS interrupt routing to CPU vs. GT
  drm/exynos: remove the redundant machine checking code
  drm/radeon: add a dpm quirk list
  drm/amdkfd: Fix sparse warning (different address space)
  drm/radeon: fix VM flush on CIK (v3)
  drm/radeon: fix VM flush on SI (v3)
  drm/radeon: fix VM flush on cayman/aruba (v3)
  drm/amdkfd: Drop interrupt SW ring buffer

…el/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "This batch contains two fixes for FireWire lib module and a quirk for
  yet another Logitech WebCam.  The former is the fixes for MIDI
  handling I forgot to pick up during the merge window.  All the fixed
  code is pretty local and shouldn't give any regressions"

* tag 'sound-3.19-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: usb-audio: Add mic volume fix quirk for Logitech Webcam C210
  ALSA: firewire-lib: limit the MIDI data rate
  ALSA: firewire-lib: remove rx_blocks_for_midi quirk

The current rounding of "size" is wrong:

 - If "start" is sufficiently near the next page boundary, "size"
   is decremented by more than enough and the last page is lost.

 - If "size" is sufficiently small, it is wrapped around and gets
   a bogus value.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Acked-by: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

…l/git/rostedt/linux-trace

Pull superh tracing fix from Steven Rostedt:
 "It's been reported that function tracing does not work on the sh
  architecture because gcc 4.8 for superH does not support -m32, and the
  recordmcount.pl script adds "-m32" when re-compiling the object files
  with the mcount locations.

  I was not able to reproduce this problem, as it seems that -m32 works
  fine for my cross compiler gcc 4.6.3, but I have to assume that -m32
  was deprecated somewhere between 4.6 and 4.8.  As it still seems to
  compile fine without -m32, I have no reason not to add this patch, as
  having -m32 seems to cause trouble for others"

* tag 'trace-sh-3.19' of git://git.kernel.org/pub/scm/linux/kernel/git/rostedt/linux-trace:
  scripts/recordmcount.pl: There is no -m32 gcc option on Super-H anymore

James Bottomley points out that it will be -1 during unload.  It's
only used for diagnostics, so let's not hide that as it could be a
clue as to what's gone wrong.

Cc: Jason Wessel <jason.wessel@windriver.com>
Acked-and-documention-added-by: James Bottomley <James.Bottomley@HansenPartnership.com>
Reviewed-by: Masami Hiramatsu <maasami.hiramatsu.pt@hitachi.com>
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>

__kuser_sigtramp address should be 0x1044 instead of 0x1040.

Signed-off-by: Ley Foon Tan <lftan@altera.com>

During the course of the rewrites a bug sneaked in when dealing
with children nodes of overlays, which ends up duplicating
sub nodes.

Simply remove the duplicate traversal of child nodes to fix.

Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>

When using overlays with drivers calling of_populate the notifier
will try to create the device twice. Using the populated bit
before proceeding protects against this.

Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>

…nel/git/rusty/linux

Pull module and param fixes from Rusty Russell:
 "Surprising number of fixes this merge window :(

  The first two are minor fallout from the param rework which went in
  this merge window.

  The next three are a series which fixes a longstanding (but never
  previously reported and unlikely , so no CC stable) race between
  kallsyms and freeing the init section.

  Finally, a minor cleanup as our module refcount will now be -1 during
  unload"

* tag 'fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rusty/linux:
  module: make module_refcount() a signed integer.
  module: fix race in kallsyms resolution during module load success.
  module: remove mod arg from module_free, rename module_memfree().
  module_arch_freeing_init(): new hook for archs before module->module_init freed.
  param: fix uninitialized read with CONFIG_DEBUG_LOCK_ALLOC
  param: initialize store function to NULL if not available.

…-socfpga-next

Pull one arch/nios2 fix from Ley Foon Tan:
 "Fix kuser trampoline address"

* tag 'nios2-fixes-v3.19-rc6' of git://git.rocketboards.org/linux-socfpga-next:
  nios2: fix kuser trampoline address

…/git/s390/linux

Pull s390 fixes from Martin Schwidefsky:
 "Five more bug fixes from Michael for the s390 BPF jit"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux:
  s390/bpf: Zero extend parameters before calling C function
  s390/bpf: Fix sk_load_byte_msh()
  s390/bpf: Fix offset parameter for skb_copy_bits()
  s390/bpf: Fix skb_copy_bits() parameter passing
  s390/bpf: Fix JMP_JGE_K (A >= K) and JMP_JGT_K (A > K)

The old cryptic address bounces, fix it by using a properly working one.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Acked-by: Richard Zhu <Richard.Zhu@freescale.com>

Since c9465b4 (arm64: add support to dump the kernel page tables)
allmodconfig has failed to build on arm64 as a result of:

../arch/arm64/mm/dump.c:55:20: error: 'PCI_IOBASE' undeclared here (not in a function)

Fix this by explicitly including io.h to ensure that a definition is
present.

Signed-off-by: Mark Brown <broonie@kernel.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>

STR and SLDT with rip-relative operand can cause a host kernel oops.
Mark them as DstMem as well.

Cc: stable@vger.linux.org
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

SYSENTER emulation is broken in several ways:
1. It misses the case of 16-bit code segments completely (CVE-2015-0239).
2. MSR_IA32_SYSENTER_CS is checked in 64-bit mode incorrectly (bits 0 and 1 can
   still be set without causing #GP).
3. MSR_IA32_SYSENTER_EIP and MSR_IA32_SYSENTER_ESP are not masked in
   legacy-mode.
4. There is some unneeded code.

Fix it.

Cc: stable@vger.linux.org
Signed-off-by: Nadav Amit <namit@cs.technion.ac.il>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Introduce selftests for overlays using sub-devices present
in children nodes.

Signed-off-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
Signed-off-by: Grant Likely <grant.likely@linaro.org>

This reverts commit 3161293.

This interface was determined to be flawed and required too invasive a
fix for the RC cycle. This will be revisited in 3.20.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>

This reverts commit 02b2aaa.

This interface was determined to be flawed and required too invasive a
fix for the RC cycle. This will be revisited in 3.20.

Signed-off-by: Darren Hart <dvhart@linux.intel.com>

…git/arm64/linux

Pull two arm64 fixes from Will Deacon:
 "Arm64 fixes seem to come in pairs recently.  We've got a fix for
  removing device-tree blobs when doing a make clean and another one
  addressing a missing include, which fixes build failures in -next for
  allmodconfig (spotted by Mark's buildbot).

  Summary from signed tag:

   - fix cleaning of .dtbs following directory restructuring
   - fix allmodconfig build breakage in -next due to missing include"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: dump: Fix implicit inclusion of definition for PCI_IOBASE
  arm64: Add dtb files to archclean rule

Pull ARM fixes from Russell King:
 "Another round of small ARM fixes.

  restore_user_regs early stack deallocation is buggy in the presence of
  FIQs which switch to SVC mode, and could lead to corrupted registers
  being returned to a user process given an inopportune FIQ event.

  Another bug was spotted in the ARM perf code where it could lose track
  of perf counter overflows, leading to incorrect perf results.

  Lastly, a bug in arm_add_memory() was spotted where the memory sizes
  aren't properly rounded.  As most people pass properly rounded sizes,
  this hasn't been noticed"

* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  ARM: 8292/1: mm: fix size rounding-down of arm_add_memory() function
  ARM: 8255/1: perf: Prevent wraparound during overflow
  ARM: 8266/1: Remove early stack deallocation from restore_user_regs

Pull kvm fixes from Paolo Bonzini:
 "Three small fixes.

  Two for x86 and one avoids that sparse bails out"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: x86: SYSENTER emulation is broken
  KVM: x86: Fix of previously incomplete fix for CVE-2014-8480
  KVM: fix sparse warning in include/trace/events/kvm.h

…x/kernel/git/glikely/linux

Pull devicetree bug fixes and documentation updates from Grant Likely:
 "A few bugfixes for the new DT overlay feature, documentation updates,
  spelling corrections, and changes to MAINTAINERS.  Nothing earth
  shattering here"

* tag 'devicetree-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/glikely/linux:
  of/unittest: Overlays with sub-devices tests
  of/platform: Handle of_populate drivers in notifier
  of/overlay: Do not generate duplicate nodes
  devicetree: document the "qemu" and "virtio" vendor prefixes
  devicetree: document ARM bindings for QEMU's Firmware Config interface
  Documentation: of: fix typo in graph bindings
  dma-mapping: fix debug print to display correct dma_pfn_offset
  of: replace Asahi Kasei Corp vendor prefix
  ARM: dt: GIC: Spelling s/specific/specifier/, s/flaggs/flags/
  dt/bindings: arm-boards: Spelling s/pointong/pointing/
  MAINTAINERS: Update DT website and git repository
  MAINTAINERS: drop DT regex matching on of_get_property and of_match_table

…ernel/git/helgaas/pci

Pull PCI fixes from Bjorn Helgaas:
 "These are fixes for:

   - a resource management problem that causes a Radeon "Fatal error
     during GPU init" on machines where the BIOS programmed an invalid
     Root Port window.  This was a regression in v3.16.

   - an Atheros AR93xx device that doesn't handle PCI bus resets
     correctly.  This was a regression in v3.14.

   - an out-of-date email address"

* tag 'pci-v3.19-fixes-1' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci:
  MAINTAINERS: Update Richard Zhu's email address
  sparc/PCI: Clip bridge windows to fit in upstream windows
  powerpc/PCI: Clip bridge windows to fit in upstream windows
  parisc/PCI: Clip bridge windows to fit in upstream windows
  mn10300/PCI: Clip bridge windows to fit in upstream windows
  microblaze/PCI: Clip bridge windows to fit in upstream windows
  ia64/PCI: Clip bridge windows to fit in upstream windows
  frv/PCI: Clip bridge windows to fit in upstream windows
  alpha/PCI: Clip bridge windows to fit in upstream windows
  x86/PCI: Clip bridge windows to fit in upstream windows
  PCI: Add pci_claim_bridge_resource() to clip window if necessary
  PCI: Add pci_bus_clip_resource() to clip to fit upstream window
  PCI: Pass bridge device, not bus, when updating bridge windows
  PCI: Mark Atheros AR93xx to avoid bus reset
  PCI: Add flag for devices where we can't use bus reset