hmp: dont attempt to pull tasks if affinity doesn't allow it

When looking for a task to be idle-pulled, don't consider tasks
where the affinity does not allow that task to be placed on the
target CPU. Also ensure that tasks with restricted affinity
do not block selecting other unrestricted busy tasks.

Use the knowledge of target CPU more effectively in idle pull
by passing to hmp_get_heaviest_task when we know it, otherwise
only checking for general affinity matches with any of the CPUs
in the bigger HMP domain.

We still need to explicitly check affinity is allowed in idle pull
since if we find no match in hmp_get_heaviest_task we will return
the current one, which may not be affine to the new CPU despite
having high enough load. In this case, there is nothing to move.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>

Revert "hmp: dont attempt to pull tasks if affinity doesn't allow it"

This reverts commit 95365d0a9ec7c16fbe25682998f898e400c27177.

sched: hmp: Change small task packing defaults for all platforms

All platforms other than TC2 default to enabling packing. Since TC2
shows no performance or energy degradation with this feature enabled
make it default enabled the same as everyone else.
Likewise, vendors have been including TC2 support in multi-machine
kernel builds so they expect the default thresholds to remain the
same when the TC2 #ifdef is removed.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>

hmp: dont attempt to pull tasks if affinity doesn't allow it

When looking for a task to be idle-pulled, don't consider tasks
where the affinity does not allow that task to be placed on the
target CPU. Also ensure that tasks with restricted affinity
do not block selecting other unrestricted busy tasks.

Use the knowledge of target CPU more effectively in idle pull
by passing to hmp_get_heaviest_task when we know it, otherwise
only checking for general affinity matches with any of the CPUs
in the bigger HMP domain.

We still need to explicitly check affinity is allowed in idle pull
since if we find no match in hmp_get_heaviest_task we will return
the current one, which may not be affine to the new CPU despite
having high enough load. In this case, there is nothing to move.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>

hmp: Use idle pull to perform forced up-migrations

When a normal forced up-migration takes place we stop the task to
be migrated while the target CPU becomes available. This delay can
range from 80us to 1500us on TC2 if the target CPU is in a deep idle
state.

Instead, interrupt the target CPU and ask it to pull a task.
This lets the current eligible task continue executing on the
original CPU while the target CPU wakes. Use a pinned timer to
prevent the pulling CPU going back into power-down with pending
up-migrations.

If we trigger for a nohz kick, it doesn't matter about triggering
for an idle pull since the idle_pull flag will be set when we
execute the softirq and we'll still do the idle pull.

If the target CPU is busy, we will not pull any tasks.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>
[ Rebased on top of 1.1-Juno-rc0 ]
[ Add missing this_cpu in run_rebalance_domains() ]
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Juri Lelli <juri.lelli@arm.com>

sched: hmp: unify active migration code

The HMP active migration code is functionally identical to the CFS
active migration code apart from one flag check. Share the code
and make the flag check optional.

Two wrapper functions allow the flag check to be present or not.

Thanks to tixy@linaro.org for pointing out the build break and a
good solution in an earlier version.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>
[ Rebased on top of 1.1-Juno-rc0 ]
Signed-off-by: Patrick Bellasi <patrick.bellasi@arm.com>
Signed-off-by: Juri Lelli <juri.lelli@arm.com>

hmp: sched: Clean up hmp_up_threshold checks into a utility fn

In anticipation of modifying the up_threshold handling, make all
instances use the same utility fn to check if a task is eligible
for up-migration. This also removes the previous difference in
threshold comparison where up-migration used '!<threshold' and
idle pull used '>threshold' to decide up-migration eligibility.
Make them both use '!<threshold' instead for consistency, although
this is unlikely to change any results.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>
Signed-off-by: Jon Medhurst <tixy@linaro.org>

usb: Fix H20AHB driver for big-endian

Signed-off-by: Robin Murphy <robin.murphy@arm.com>

Support PSCI reboot/shutdown

Hack in the extra function IDs in lieu of 'proper' PSCi 0.2 support.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>

Set the CEC I2C address based on the slave I2C address.

The two LSBs of the TDA998x's I2C address are set by pins
on the chip. The associated CEC peripheral's I2C address
is set in the same way, so base the CEC address on that
of the slave's address.

Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

Revert "drm: i2c: tda998x: Retry fetching the EDID if it fails first time."

This reverts commit 7d0d4cedd12513703239172eb9a7a3465cb8a6ec.

This was a stopgap solution until the real bug was properly understood.
Now that I2C transactions can be relied on, we don't need this anymore.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

i2c: designware: prevent early stop on TX FIFO empty

If the Designware core is configured with IC_EMPTYFIFO_HOLD_MASTER_EN
set to zero, allowing the TX FIFO to become empty causes a STOP
condition to be generated on the I2C bus. If the transmit FIFO
threshold is set too high, an erroneous STOP condition can be
generated on long transfers - particularly where the interrupt
latency is extended.

Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: Re-add DMT modes for monitors

Commit 196e077dc165a307efbd9e7569f81bbdbcf18f65
"drm: don't add inferred modes for monitors that don't support them"

It remove the call add_inferred_modes when DRM_EDID_FEATURE_DEFAULT_GTF
in feature support field is zero, this remove all inferred modes
come from GTF or CVT range information, and also remove DMT modes,
this make me lost some avaiable modes for my TV.

Signed-off-by: Wang YanQing <udknight@gmail.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

DRM: HDLCD: Enable compat IOCTL for 32-bit userspace.

32-bit userspace should be able to use double buffering in the
same way native binaries do, so enable it.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

arm64: Enable Heterogenous Multi Processing by default

HMP needs more tuning but its usefulness has been proved
so enable it by default. There might still be corner cases
where issues will crop up, but for demos and evaluation
is should be ready to use.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

sched: hmp: fix out-of-range CPU possible

If someone hotplugs all the little CPUs while another CPU is handling
a wakeup, we can potentially return new_cpu == NR_CPUS from
hmp_select_slower_cpu (which is called internally by
hmp_best_little_cpu as well). We will use this to deref the
per_cpu rq array in hmp_next_down_delay which can go boom.

Signed-off-by: Chris Redpath <chris.redpath@arm.com>

drm: hdlcd: Add debugfs entry for displaying current pixelclock value

When asking the hardware to set a new pixelclock value we might
timeout on values that are calculated during request and not
wait for the actual outcome of the clock setting. SCP could still
finish the brute force search for the best PLL settings and might
or might not set the requested resolution. To help track the
current value of the pixelclock, add a new entry in debugfs that
displays the HW programmed value vs the one that was requested
for the current running mode.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

juno: defconfig: Enable multi-touch HID devices in defconfig

mailbox: mhu: Acknowledge the interrupt only after data is pushed

According to the mailbox documentation the controller should ACK
the RX only after it has finished pushing the data up the link.

Signed-off-by: Punit Agrawal <Punit.Agrawal@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

mailbox: scpi: Free the mailbox channel when we fail to queue a message.

When sending an SCPI command we aquire a channel and queue the
message in the mailbox. If the queuing failed we were not releasing
the channel hence preventing everyone else from using it.

Signed-off-by: Punit Agrawal <Punit.Agrawal@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: hdlcd: Don't depend on VSYNC interrupt when setting new framebuffer.

VSYNC state is influenced by the DRM framework and cannot be relied
on when setting a new framebuffer base address and synchronising with
the hardware. Use the DMA_END interrupt as it is a more reliable way
of signaling the end of frame utilisation.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

mailbox: Pack SCPI structures used for messages.

The System Control Processor expects data sent in the messages
to be contiguos. When using unpacked structures to describe
the data being transmitted we increase the general size of the
message which leads to SCP rejecting our request.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

arm64: defconfig: Enable CPUidle driver by default.

Enable the arm64 CPUidle driver by default.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

arm64: Juno: Comment out the secondary HDLCD controller

The HDLCD controllers on Juno share the same PLL for the pixel
clock output. If the secondary output is not connected to a
monitor with the same resolution as the primary output, or
to a monitor with VGA resolution, it will cause the pixel
clock to be set to the wrong value for the primary output.
Comment out the secondary HDLCD controller for now.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: i2c: tda998x: Retry fetching the EDID if it fails first time.

Fetching the EDID from a connected monitor is an automated thing
with NXP TDA19988. But on some boards the fetching fails for the
first time silently without any indication that an error has occured.
More than that, subsequent fetches of the EDID succeed until the
monitor(s) are pluged out.

Add a function to validate the read EDID and retry if the block
retrieved is not valid.

Signed-off-by: Andrew Jackson <Andrew.Jackson@arm.com>
Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: hdlcd: Fix the picture tear when flipping framebuffers.

HDLCD contains logic in hardware to wait for VSYNC before updating
the start of framebuffer register, so we don't need to do it in
software. More than that, to remove any tearing we need to wait
for VSYNC after setting up a new framebuffer as releasing the old
fb while the hardware is still using it can cause artifacts.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

Update README.md in preparation for Beta release.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

arm64: Juno: Collect last remaining updates in preparation release.

Update the Mali device tree node label, register size resource,
update GICv2 register resource and remove UAS as a module from
defconfig. All small patches that were sitting in my inbox.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

arm64: Update defconfig to bump the CMA buffer size to 32MB and enable ION.

These changes are needed to enable the HDLCD to do double
buffering correctly with Android and Mali drivers.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

drm: arm: Add support for PRIME and dma_buf buffer sharing.

Add support for buffer sharing in HDLCD and implement proprietary
IOCTL from ARM Mali driver to get a file descriptor for the buffer.
This is used by the Mali kernel driver to import the buffers into
DDK and enable double buffering.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

staging: android: ion: Set the length of the DMA sg entries in buffer.

ion_buffer_create() will allocate a buffer and then create a DMA
mapping for it, but it forgot to set the length of the page entries.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

arm64: Juno: Disable CPU idle states for now.

CPU idle has not received enough testing to pass release status,
so we need to disable it for now.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

arm64: juno: Update defconfig to enable IPv6 options for Android

Android wants to use IPv6 features, so lets enable them.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

usb: fix hcd h20ahb driver depends

USB_EHCI_HCD_SYNOPSYS is not only dependent on USB_EHCI_HCD, but
also on USB_PHY. Otherwise kernel build has the following error:

  LD      init/built-in.o
drivers/built-in.o: In function `ehci_hcd_h20ahb_probe':
:(.text+0xb9bb4): undefined reference to `usb_add_phy_dev'

Signed-off-by: Alex Shi <alex.shi@linaro.org>

arm64: Juno: Carve out memory reserved for secure access.

Trusted Firmware 0.4 reserves the top 16MB of RAM available
in the first 4GB address space for the secure world use.
Carve out that memory from the device tree to avoid triggering
faults when accessing protected memory.

Signed-off-by: Liviu Dudau <Liviu.Dudau@arm.com>

Merge remote-tracking branch 'sudeep/juno_freq+idle' into juno-release

Conflicts:
arch/arm64/boot/dts/juno.dts
arch/arm64/configs/defconfig
arch/arm64/kernel/topology.c
drivers/clk/clk-scpi.c
drivers/cpufreq/scpi-cpufreq.c
drivers/input/serio/ambakmi.c
drivers/mailbox/arm_mhu.c
include/uapi/linux/audit.h

fixup! mailbox: add support for ARM Message Handling Unit(MHU) controller

TODO:
Yet to identify on what paths we need to clear the RX status if the
protocol timed out and frees the channel. For now have it in startup,
shutdown and interrupt...

juno: add untuned C-state details to device tree

Also add hack to workaround mmaped timer access issue

Merge branch 'arm64/unstable/arm64-cpuidle' of git://linux-arm.org/linux-2.6-lp into juno_mhu_clk_dvfs

* 'arm64/unstable/arm64-cpuidle' of git://linux-arm.org/linux-2.6-lp:
  arm64: boot: dts: update rtsm aemv8 dts with PSCI and idle states
  drivers: cpuidle: CPU idle ARM64 driver
  arm64: add PSCI CPU_SUSPEND based cpu_suspend support
  drivers: cpuidle: implement OF based idle states infrastructure

Temp commit to add Juno DTS and additional configs

cpufreq: [HORRIBLE DIRTY HACK] get arm_big_little compiling on arm64

*******!!!!!!!!****** ONLY FOR TESTING *************!!!!!!!!!***************

Currently the addition of switcher code has created too much dependencies
to get this driver compiling on ARM64. For time being add dirty compilation
hacks to test CPUFreq on Juno.

****!!!!!!!***** THIS NEEDS TO BE REWORKED *********!!!!!!!!****************

Not-at-all-Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

cpufreq: arm_big_little: add SPCI interface driver

On some ARM based systems, a separate Cortex-M based System Control
Processor(SCP) provides the overall power, clock, reset and system
control including CPU DVFS. SCPI Message Protocol is used to
communicate with the SCPI.

This patch adds a interface driver for adding OPPs and registering
the arm_big_little cpufreq driver for such systems.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

clk: add support for clocks provided by system control processor

On some ARM based systems, a separate Cortex-M based System Control
Processor(SCP) provides the overall power, clock, reset and system
control. System Control and Power Interface(SCPI) Message Protocol
is defined for the communication between the Application Cores(AP)
and the SCP.

This patch adds support for the clocks provided by SCP using SCPI
protocol.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

mailbox: add support for System Control and Power Interface(SCPI) protocol

This patch add supports for System Control and Power Interface (SCPI)
Message Protocol used between the Application Cores(AP) and the System
Control Processor(SCP). The MHU peripheral provides a mechanism for
inter-processor communication between SCP's M3 processor and AP.

SCP offers control and management of the core/cluster power states,
various power domain DVFS including the core/cluster, certain system
clocks configuration, thermal sensors and many others.

This protocol library provides interface for all the client drivers using
SCPI to make use of the features offered by the SCP.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

mailbox: add support for ARM Message Handling Unit(MHU) controller

This patch adds support for ARM Message Handling Unit(MHU) controller
that provides control logic and interrupt generation to support
inter-processor communication between the Application Processor and
the System Control Processor(SCP).

This support is built on the existing common mailbox framework for
client/protocol drivers and controller drivers of Inter Processor
Communication(IPC). SCP controls most of the power management on the
Application Processors.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

arm64: add ARCH_HAS_OPP to allow enabling OPP library

The Operating Performance Point (OPP) Layer library is a generic
library used by CPUFREQ and DEVFREQ. It can be enabled only on the
platforms that specify ARCH_HAS_OPP option.

This patch selects that option in order to allow ARM64 based platforms
to use OPP library.

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

arm64: restore alphabetic order in Kconfig

Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>

Merge branches 'cpu_topology' and 'mailbox' into juno_mhu_clk_dvfs

* cpu_topology:
  arm64: topology: Provide relative power numbers for cores
  arm64: topology: Tell the scheduler about the relative power of cores
  arm64: topology: add MPIDR-based detection
  arm64: topology: Add support for topology DT bindings
  arm64: topology: Initialise default topology state immediately
  arm64: sched: Remove unused mc_capable() and smt_capable()

* mailbox:
  mailbox: Fix deleteing poll timer
  mailbox: Fix TX completion init
  mailbox: pl320: Introduce common API driver
  mailbox: Introduce framework for mailbox
  mailbox: rename pl320-ipc specific mailbox.h

arm64: topology: Provide relative power numbers for cores

Provide performance numbers to the scheduler to help it fill the cores in
the system on big.LITTLE systems. With the current scheduler this may
perform poorly for applications that try to do OpenMP style work over all
cores but should help for more common workloads. The current 32 bit ARM
implementation provides a similar estimate so this helps ensure that
work to improve big.LITTLE systems on ARMv7 systems performs similarly
on ARMv8 systems.

The power numbers are the same as for ARMv7 since it seems that the
expected differential between the big and little cores is very similar on
both ARMv7 and ARMv8.  In both ARMv7 and ARMv8 cases the numbers were
based on the published DMIPS numbers.

These numbers are just an initial and basic approximation for use with
the current scheduler, it is likely that both experience with silicon
and ongoing work on improving the scheduler will lead to further tuning
or will tune automatically at runtime and so make the specific choice of
numbers here less critical.

Signed-off-by: Mark Brown <broonie@linaro.org>

arm64: topology: Tell the scheduler about the relative power of cores

In heterogeneous systems like big.LITTLE systems the scheduler will be
able to make better use of the available cores if we provide power numbers
to it indicating their relative performance. Do this by parsing the CPU
nodes in the DT.

This code currently has no effect as no information on the relative
performance of the cores is provided.

Signed-off-by: Mark Brown <broonie@linaro.org>

arm64: topology: add MPIDR-based detection

Create cpu topology based on MPIDR. When hardware sets MPIDR to sane
values, this method will always work. Therefore it should also work well
as the fallback method. [1]

When we have multiple processing elements in the system, we create
the cpu topology by mapping each affinity level (from lowest to highest)
to threads (if they exist), cores, and clusters.

We combine data from all higher affinity levels into cluster_id
so we don't lose any information from MPIDR. [2]

[1] http://www.spinics.net/lists/arm-kernel/msg317445.html
[2] https://lkml.org/lkml/2014/4/23/703

[Raise the priority of the error message if we don't discover topology
now that we can read it from MPIDIR -- broonie]

Signed-off-by: Zi Shen Lim <zlim@broadcom.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

arm64: topology: Add support for topology DT bindings

Add support for parsing the explicit topology bindings to discover the
topology of the system.

Since it is not currently clear how to map multi-level clusters for the
scheduler all leaf clusters are presented to the scheduler at the same
level. This should be enough to provide good support for current systems.

Signed-off-by: Mark Brown <broonie@linaro.org>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

arm64: topology: Initialise default topology state immediately

As a legacy of the way 32 bit ARM did things the topology code uses a null
topology map by default and then overwrites it by mapping cores with no
information to a cluster by themselves later. In order to make it simpler
to reset things as part of recovering from parse failures in firmware
information directly set this configuration on init. A core will always be
its own sibling so there should be no risk of confusion with firmware
provided information.

Signed-off-by: Mark Brown <broonie@linaro.org>
Reviewed-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

arm64: sched: Remove unused mc_capable() and smt_capable()

Remove unused and deprecated mc_capable() and smt_capable().

Both were added recently by f6e763b93a6c ("arm64: topology:
Implement basic CPU topology support"). Uses of both were removed
by 8e7fbcbc22c1 ("sched: Remove stale power aware scheduling
remnants and dysfunctional knobs").

Signed-off-by: Zi Shen Lim <zlim@broadcom.com>
Signed-off-by: Mark Brown <broonie@linaro.org>

mailbox: Fix deleteing poll timer

Try to delete the timer only if it was init/used.

Signed-off-by: LeyFoon Tan <lftan.linux@gmail.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>

mailbox: Fix TX completion init

For fast TX the complete could be called before being initialized as follows
 mbox_send_message --> poll_txdone --> tx_tick --> complete(&chan->tx_complete)

Init the completion early enough to fix the race.

Signed-off-by: LeyFoon Tan <lftan.linux@gmail.com>
Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>

mailbox: pl320: Introduce common API driver

Convert the PL320 controller driver to work with the common
mailbox API. Also convert the only user of PL320, highbank-cpufreq.c
to work with thee API. Drop the obsoleted driver pl320-ipc.c

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>

mailbox: Introduce framework for mailbox

Introduce common framework for client/protocol drivers and
controller drivers of Inter-Processor-Communication (IPC).

Client driver developers should have a look at
 include/linux/mailbox_client.h to understand the part of
the API exposed to client drivers.
Similarly controller driver developers should have a look
at include/linux/mailbox_controller.h

Signed-off-by: Jassi Brar <jaswinder.singh@linaro.org>

mailbox: rename pl320-ipc specific mailbox.h

The patch 30058677 "ARM / highbank: add support for pl320 IPC"
added a pl320 IPC specific header file as a generic mailbox.h.
This file has been renamed appropriately to allow the
introduction of the generic mailbox API framework.

Acked-by: Mark Langsdorf <mark.langsdorf@calxeda.com>
Cc: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Suman Anna <s-anna@ti.com>

Linux 3.15-rc8

Merge branch 'merge' of git://git./linux/kernel/git/benh/powerpc

Pull powerpc fix from Ben Herrenschmidt:
 "Here's just one trivial patch to wire up sys_renameat2 which I seem to
  have completely missed so far.

  (My test build scripts fwd me warnings but miss the ones generated for
  missing syscalls)"

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  powerpc: Wire renameat2() syscall

Merge branch 'upstream' of git://git.linux-mips.org/ralf/upstream-linus

Pull MIPS fixes from Ralf Baechle:
 "A fair number of fixes across the field.  Nothing terribly
  complicated; the one liners in below changelog should be fairly
  descriptive.

  Noteworthy is the SB1 change which the result of changes to binutils
  resulting in one big gas warning for most files being assembled as
  well as the asid_cache and branch emulation fixes which fix corruption
  or possible uninteded behaviour of kernel or application code.  The
  remainder of fixes are more platforms or subsystem specific"

* 'upstream' of git://git.linux-mips.org/pub/scm/ralf/upstream-linus:
  MIPS: R46000: Fix Micro-assembler field overflow for R4600 V2
  MIPS: ptrace: Avoid smp_processor_id() in preemptible code
  MIPS: Lemote 2F: cs5536: mfgpt: use raw locks
  MIPS: SB1: Fix excessive kernel warnings.
  MIPS: RC32434: fix broken PCI resource initialization
  MIPS: malta: memory.c: Initialize the 'memsize' variable
  MIPS: Fix typo when reporting cache and ftlb errors for ImgTec cores
  MIPS: Fix inconsistancy of __NR_Linux_syscalls value
  MIPS: Fix branch emulation of branch likely instructions.
  MIPS: Fix a typo error in AUDIT_ARCH definition
  MIPS: Change type of asid_cache to unsigned long

Merge branch 'sched-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull scheduler fixes from Ingo Molnar:
 "Various fixlets, mostly related to the (root-only) SCHED_DEADLINE
  policy, but also a hotplug bug fix and a fix for a NR_CPUS related
  overallocation bug causing a suspend/resume regression"

* 'sched-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  sched: Fix hotplug vs. set_cpus_allowed_ptr()
  sched/cpupri: Replace NR_CPUS arrays
  sched/deadline: Replace NR_CPUS arrays
  sched/deadline: Restrict user params max value to 2^63 ns
  sched/deadline: Change sched_getparam() behaviour vs SCHED_DEADLINE
  sched: Disallow sched_attr::sched_policy < 0
  sched: Make sched_setattr() correctly return -EFBIG

powerpc: Wire renameat2() syscall

Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>

Merge branch 'core-urgent-for-linus' of git://git./linux/kernel/git/tip/tip

Pull core futex/rtmutex fixes from Thomas Gleixner:
 "Three fixlets for long standing issues in the futex/rtmutex code
  unearthed by Dave Jones syscall fuzzer:

   - Add missing early deadlock detection checks in the futex code
   - Prevent user space from attaching a futex to kernel threads
   - Make the deadlock detector of rtmutex work again

  Looks large, but is more comments than code change"

* 'core-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  rtmutex: Fix deadlock detector for real
  futex: Prevent attaching to kernel threads
  futex: Add another early deadlock detection check

Merge branch 'drm-fixes' of git://people.freedesktop.org/~airlied/linux

Pull drm fixes from Dave Airlie:
 "Mostly quiet now:

  i915:
    fixing userspace visiblie issues, all stable marked

  radeon:
    one more pll fix, two crashers, one suspend/resume regression"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
  drm/radeon: Resume fbcon last
  drm/radeon: only allocate necessary size for vm bo list
  drm/radeon: don't allow RADEON_GEM_DOMAIN_CPU for command submission
  drm/radeon: avoid crash if VM command submission isn't available
  drm/radeon: lower the ref * post PLL maximum once more
  drm/i915: Prevent negative relocation deltas from wrapping
  drm/i915: Only copy back the modified fields to userspace from execbuffer
  drm/i915: Fix dynamic allocation of physical handles

dcache: add missing lockdep annotation

lock_parent() very much on purpose does nested locking of dentries, and
is careful to maintain the right order (lock parent first).  But because
it didn't annotate the nested locking order, lockdep thought it might be
a deadlock on d_lock, and complained.

Add the proper annotation for the inner locking of the child dentry to
make lockdep happy.

Introduced by commit 046b961b45f9 ("shrink_dentry_list(): take parent's
->d_lock earlier").

Reported-and-tested-by: Josh Boyer <jwboyer@fedoraproject.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

drm/radeon: Resume fbcon last

So a few people complained that

commit 177cf92de4aa97ec1435987e91696ed8b5023130
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Tue Apr 1 22:14:59 2014 +0200

    drm/crtc-helpers: fix dpms on logic

which was merged into 3.15-rc1, broke resume on radeons. Strangely git
bisect lead everyone to

commit 25f397a429dfa43f22c278d0119a60a343aa568f
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri Jul 19 18:57:11 2013 +0200

    drm/crtc-helper: explicit DPMS on after modeset

which was merged long ago and actually part of 3.14.

Digging deeper I've noticed (again) that the call to
drm_helper_resume_force_mode in the radeon resume handlers was a no-op
previously because everything gets shut down on suspend. radeon does
this with explicit calls to drm_helper_connector_dpms with DPMS_OFF.
But with 177c we now force the dpms state to ON, so suddenly
resume_force_mode actually forced the crtcs back on.

This is the intention of the change after all, the problem is that
radeon resumes the fbdev console layer _before_ restoring the display,
through calling fb_set_suspend. And fbcon does an immediate ->set_par,
which in turn causes the same forced mode restore to happen.

Two concurrent modeset operations didn't lead to happiness. Fix this
by delaying the fbcon resume until the end of the readeon resum
functions.

v2: Fix up a bit of the spelling fail.

References: https://lkml.org/lkml/2014/5/29/1043
References: https://lkml.org/lkml/2014/5/2/388
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=74751
Tested-by: Ken Moffat <zarniwhoop@ntlworld.com>
Cc: Alex Deucher <alexdeucher@gmail.com>
Cc: Ken Moffat <zarniwhoop@ntlworld.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@gmail.com>

Merge branch 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux into drm-fixes

this is the next pull request for stashed up radeon fixes for 3.15. This is finally calming down with only four patches in this pull request.

* 'drm-fixes-3.15' of git://people.freedesktop.org/~deathsimple/linux:
  drm/radeon: only allocate necessary size for vm bo list
  drm/radeon: don't allow RADEON_GEM_DOMAIN_CPU for command submission
  drm/radeon: avoid crash if VM command submission isn't available
  drm/radeon: lower the ref * post PLL maximum once more

Merge branch 'for-linus' of git://git./linux/kernel/git/dtor/input

Pull input subsystem fixes from Dmitry Torokhov:
 "A couple of driver/build fixups and also redone quirk for Synaptics
  touchpads on Lenovo boxes (now using PNP IDs instead of DMI data to
  limit number of quirks)"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: synaptics - change min/max quirk table to pnp-id matching
  Input: synaptics - add a matches_pnp_id helper function
  Input: synaptics - T540p - unify with other LEN0034 models
  Input: synaptics - add min/max quirk for the ThinkPad W540
  Input: ambakmi - request a shared interrupt for AMBA KMI devices
  Input: pxa27x-keypad - fix generating scancode
  Input: atmel-wm97xx - only build for AVR32
  Input: fix ps2/serio module dependency

Merge tag 'firewire-fixes' of git://git./linux/kernel/git/ieee1394/linux1394

Pull firewire fix from Stefan Richter:
 "A regression fix for the IEEE 1394 subsystem: re-enable IRQ-based
  asynchronous request reception at addresses below 128 TB"

* tag 'firewire-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394:
  firewire: revert to 4 GB RDMA, fix protocols using Memory Space

Merge tag 'dm-3.15-fixes-3' of git://git./linux/kernel/git/device-mapper/linux-dm

Pull device-mapper fixes from Mike Snitzer:
 "A dm-cache stable fix to split discards on cache block boundaries
  because dm-cache cannot yet handle discards that span cache blocks.

  Really fix a dm-mpath LOCKDEP warning that was introduced in -rc1.

  Add a 'no_space_timeout' control to dm-thinp to restore the ability to
  queue IO indefinitely when no data space is available.  This fixes a
  change in behavior that was introduced in -rc6 where the timeout
  couldn't be disabled"

* tag 'dm-3.15-fixes-3' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm:
  dm mpath: really fix lockdep warning
  dm cache: always split discards on cache block boundaries
  dm thin: add 'no_space_timeout' dm-thin-pool module param

x86_64: expand kernel stack to 16K

While I play inhouse patches with much memory pressure on qemu-kvm,
3.14 kernel was randomly crashed. The reason was kernel stack overflow.

When I investigated the problem, the callstack was a little bit deeper
by involve with reclaim functions but not direct reclaim path.

I tried to diet stack size of some functions related with alloc/reclaim
so did a hundred of byte but overflow was't disappeard so that I encounter
overflow by another deeper callstack on reclaim/allocator path.

Of course, we might sweep every sites we have found for reducing
stack usage but I'm not sure how long it saves the world(surely,
lots of developer start to add nice features which will use stack
agains) and if we consider another more complex feature in I/O layer
and/or reclaim path, it might be better to increase stack size(
meanwhile, stack usage on 64bit machine was doubled compared to 32bit
while it have sticked to 8K. Hmm, it's not a fair to me and arm64
already expaned to 16K. )

So, my stupid idea is just let's expand stack size and keep an eye
toward stack consumption on each kernel functions via stacktrace of ftrace.
For example, we can have a bar like that each funcion shouldn't exceed 200K
and emit the warning when some function consumes more in runtime.
Of course, it could make false positive but at least, it could make a
chance to think over it.

I guess this topic was discussed several time so there might be
strong reason not to increase kernel stack size on x86_64, for me not
knowing so Ccing x86_64 maintainers, other MM guys and virtio
maintainers.

Here's an example call trace using up the kernel stack:

         Depth    Size   Location    (51 entries)
         -----    ----   --------
   0)     7696      16   lookup_address
   1)     7680      16   _lookup_address_cpa.isra.3
   2)     7664      24   __change_page_attr_set_clr
   3)     7640     392   kernel_map_pages
   4)     7248     256   get_page_from_freelist
   5)     6992     352   __alloc_pages_nodemask
   6)     6640       8   alloc_pages_current
   7)     6632     168   new_slab
   8)     6464       8   __slab_alloc
   9)     6456      80   __kmalloc
  10)     6376     376   vring_add_indirect
  11)     6000     144   virtqueue_add_sgs
  12)     5856     288   __virtblk_add_req
  13)     5568      96   virtio_queue_rq
  14)     5472     128   __blk_mq_run_hw_queue
  15)     5344      16   blk_mq_run_hw_queue
  16)     5328      96   blk_mq_insert_requests
  17)     5232     112   blk_mq_flush_plug_list
  18)     5120     112   blk_flush_plug_list
  19)     5008      64   io_schedule_timeout
  20)     4944     128   mempool_alloc
  21)     4816      96   bio_alloc_bioset
  22)     4720      48   get_swap_bio
  23)     4672     160   __swap_writepage
  24)     4512      32   swap_writepage
  25)     4480     320   shrink_page_list
  26)     4160     208   shrink_inactive_list
  27)     3952     304   shrink_lruvec
  28)     3648      80   shrink_zone
  29)     3568     128   do_try_to_free_pages
  30)     3440     208   try_to_free_pages
  31)     3232     352   __alloc_pages_nodemask
  32)     2880       8   alloc_pages_current
  33)     2872     200   __page_cache_alloc
  34)     2672      80   find_or_create_page
  35)     2592      80   ext4_mb_load_buddy
  36)     2512     176   ext4_mb_regular_allocator
  37)     2336     128   ext4_mb_new_blocks
  38)     2208     256   ext4_ext_map_blocks
  39)     1952     160   ext4_map_blocks
  40)     1792     384   ext4_writepages
  41)     1408      16   do_writepages
  42)     1392      96   __writeback_single_inode
  43)     1296     176   writeback_sb_inodes
  44)     1120      80   __writeback_inodes_wb
  45)     1040     160   wb_writeback
  46)      880     208   bdi_writeback_workfn
  47)      672     144   process_one_work
  48)      528     112   worker_thread
  49)      416     240   kthread
  50)      176     176   ret_from_fork

[ Note: the problem is exacerbated by certain gcc versions that seem to
  generate much bigger stack frames due to apparently bad coalescing of
  temporaries and generating too many spills.  Rusty saw gcc-4.6.4 using
  35% more stack on the virtio path than 4.8.2 does, for example.

  Minchan not only uses such a bad gcc version (4.6.3 in his case), but
  some of the stack use is due to debugging (CONFIG_DEBUG_PAGEALLOC is
  what causes that kernel_map_pages() frame, for example). But we're
  clearly getting too close.

  The VM code also seems to have excessive stack frames partly for the
  same compiler reason, triggered by excessive inlining and lots of
  function arguments.

  We need to improve on our stack use, but in the meantime let's do this
  simple stack increase too.  Unlike most earlier reports, there is
  nothing simple that stands out as being really horribly wrong here,
  apart from the fact that the stack frames are just bigger than they
  should need to be.        - Linus ]

Signed-off-by: Minchan Kim <minchan@kernel.org>
Cc: Peter Anvin <hpa@zytor.com>
Cc: Dave Chinner <david@fromorbit.com>
Cc: Dave Jones <davej@redhat.com>
Cc: Jens Axboe <axboe@kernel.dk>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Ingo Molnar <mingo@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Rik van Riel <riel@redhat.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Hugh Dickins <hughd@google.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
Cc: Michael S Tsirkin <mst@redhat.com>
Cc: Dave Hansen <dave.hansen@intel.com>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: PJ Waskiewicz <pjwaskiewicz@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Merge branch 'for-linus-2' of git://git./linux/kernel/git/viro/vfs

Pull vfs dcache livelock fix from Al Viro:
 "Fixes for livelocks in shrink_dentry_list() introduced by fixes to
  shrink list corruption; the root cause was that trylock of parent's
  ->d_lock could be disrupted by d_walk() happening on other CPUs,
  resulting in shrink_dentry_list() making no progress *and* the same
  d_walk() being called again and again for as long as
  shrink_dentry_list() doesn't get past that mess.

  The solution is to have shrink_dentry_list() treat that trylock
  failure not as 'try to do the same thing again', but 'lock them in the
  right order'"

* 'for-linus-2' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  dentry_kill() doesn't need the second argument now
  dealing with the rest of shrink_dentry_list() livelock
  shrink_dentry_list(): take parent's ->d_lock earlier
  expand dentry_kill(dentry, 0) in shrink_dentry_list()
  split dentry_kill()
  lift the "already marked killed" case into shrink_dentry_list()

dentry_kill() doesn't need the second argument now

it's 1 in the only remaining caller.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

dealing with the rest of shrink_dentry_list() livelock

We have the same problem with ->d_lock order in the inner loop, where
we are dropping references to ancestors.  Same solution, basically -
instead of using dentry_kill() we use lock_parent() (introduced in the
previous commit) to get that lock in a safe way, recheck ->d_count
(in case if lock_parent() has ended up dropping and retaking ->d_lock
and somebody managed to grab a reference during that window), trylock
the inode->i_lock and use __dentry_kill() to do the rest.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

shrink_dentry_list(): take parent's ->d_lock earlier

The cause of livelocks there is that we are taking ->d_lock on
dentry and its parent in the wrong order, forcing us to use
trylock on the parent's one.  d_walk() takes them in the right
order, and unfortunately it's not hard to create a situation
when shrink_dentry_list() can't make progress since trylock
keeps failing, and shrink_dcache_parent() or check_submounts_and_drop()
keeps calling d_walk() disrupting the very shrink_dentry_list() it's
waiting for.

Solution is straightforward - if that trylock fails, let's unlock
the dentry itself and take locks in the right order.  We need to
stabilize ->d_parent without holding ->d_lock, but that's doable
using RCU.  And we'd better do that in the very beginning of the
loop in shrink_dentry_list(), since the checks on refcount, etc.
would need to be redone anyway.

That deals with a half of the problem - killing dentries on the
shrink list itself.  Another one (dropping their parents) is
in the next commit.

locking parent is interesting - it would be easy to do rcu_read_lock(),
lock whatever we think is a parent, lock dentry itself and check
if the parent is still the right one.  Except that we need to check
that *before* locking the dentry, or we are risking taking ->d_lock
out of order.  Fortunately, once the D1 is locked, we can check if
D2->d_parent is equal to D1 without the need to lock D2; D2->d_parent
can start or stop pointing to D1 only under D1->d_lock, so taking
D1->d_lock is enough.  In other words, the right solution is
rcu_read_lock/lock what looks like parent right now/check if it's
still our parent/rcu_read_unlock/lock the child.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

drm/radeon: only allocate necessary size for vm bo list

No need to always allocate the theoretical maximum here.

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

drm/radeon: don't allow RADEON_GEM_DOMAIN_CPU for command submission

It hangs the hardware.

Signed-off-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: avoid crash if VM command submission isn't available

Signed-off-by: Christian König <christian.koenig@amd.com>
CC: stable@vger.kernel.org

drm/radeon: lower the ref * post PLL maximum once more

Let's be conservative and use 100 here until we find something better.

Bugs: https://bugzilla.kernel.org/show_bug.cgi?id=75241

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

Merge branch 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm

Pull ARM fixes from Russell King:
 "The usual random collection of relatively small ARM fixes"

* 'fixes' of git://ftp.arm.linux.org.uk/~rmk/linux-arm:
  ARM: 8063/1: bL_switcher: fix individual online status reporting of removed CPUs
  ARM: 8064/1: fix v7-M signal return
  ARM: 8057/1: amba: Add Qualcomm vendor ID.
  ARM: 8052/1: unwind: Fix handling of "Pop r4-r[4+nnn],r14" opcode
  ARM: 8051/1: put_user: fix possible data corruption in put_user
  ARM: 8048/1: fix v7-M setup stack location

Merge tag 'arm64-fixes' of git://git./linux/kernel/git/arm64/linux

Pull arm64 fix from Will Deacon:
 "Fix CoW regression for transparent hugepages by routing set_pmd_at to
  set_pte_at, which correctly handles PTE_WRITE and will mark the
  resulting table entry as read-only where appropriate"

* tag 'arm64-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux:
  arm64: mm: fix pmd_write CoW brokenness

Merge tag 'pm+acpi-3.15-rc8' of git://git./linux/kernel/git/rafael/linux-pm

Pull ACPI and power management fixes from Rafael Wysocki:
 "These are three stable-candidate fixes, one for the ACPI thermal
  driver and two for cpufreq drivers.

  Specifics:

   - A workqueue is destroyed too early during the ACPI thermal driver
     module unload which leads to a NULL pointer dereference in the
     driver's remove callback.  Fix from Aaron Lu.

   - A wrong argument is passed to devm_regulator_get_optional() in the
     probe routine of the cpu0 cpufreq driver which leads to resource
     leaks if the driver is unbound from the cpufreq platform device.
     Fix from Lucas Stach.

   - A lock is missing in cpufreq_governor_dbs() which leads to memory
     corruption and NULL pointer dereferences during system
     suspend/resume, for example.  Fix from Bibek Basu"

* tag 'pm+acpi-3.15-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  ACPI / thermal: fix workqueue destroy order
  cpufreq: cpu0: drop wrong devm usage
  cpufreq: remove race while accessing cur_policy

Merge tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux

Pull clock fixes from Mike Turquette:
 "Small number of user-visible regression fixes for clock drivers.

  There is a memory leak fix for an ST platform, an infinite Loop Of
  Doom fix for the recent changes to the basic clock divider (hopefully
  the last fix for those recent changes) and some Tegra PLL changes
  which keep PCI from being hosed on that platform"

* tag 'clk-fixes-for-linus' of git://git.linaro.org/people/mike.turquette/linux:
  clk: st: Fix memory leak
  clk: divider: Fix table round up function
  clk: tegra: Fix enabling of PLLE
  clk: tegra: Introduce divider mask and shift helpers
  clk: tegra: Fix PLLE programming

arm64: boot: dts: update rtsm aemv8 dts with PSCI and idle states

This patch updates the RTSM dts file with PSCI bindings and nodes
describing the AEMv8 model idle states parameters.

PSCI function IDs compliancy with PSCI v0.2 is still under development
so this patch provides PSCI function IDs for demonstration purposes only.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

drivers: cpuidle: CPU idle ARM64 driver

This patch implements a generic CPU idle driver for ARM64 machines.

It relies on the DT idle states infrastructure to initialize idle
states count and respective parameters. Current code assumes the driver
is managing idle states on all possible CPUs but can be easily
generalized to support heterogenous systems and build cpumasks at
runtime using MIDRs or DT cpu nodes compatible properties.

Suspend back-ends (eg PSCI) must register a suspend initializer with
the CPU idle driver so that the suspend backend call can be detected,
and the driver code can call the back-end infrastructure to complete the
suspend backend initialization.

Idle state index 0 is always initialized as a simple wfi state, ie always
considered present and functional on all ARM64 platforms.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

arm64: add PSCI CPU_SUSPEND based cpu_suspend support

This patch implements the cpu_suspend cpu operations method through
the PSCI CPU_SUSPEND API. The PSCI implementation translates the idle state
index passed by the cpu_suspend core call into a valid PSCI state according to
the PSCI states initialized at boot by the PSCI suspend backend.

Entry point is set to cpu_resume physical address, that represents the
default kernel execution address following a CPU reset.

Idle state indices missing a DT node description are initialized to power
state standby WFI so that if called by the idle driver they provide the
default behaviour.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

drivers: cpuidle: implement OF based idle states infrastructure

On most common ARM systems, the low-power states a CPU can be put into are
not discoverable in HW and require device tree bindings to describe
the respective power domains, power down protocol and idle states parameters.

In order to enable DT based idle states and configure idle drivers, this
patch implements the bulk infrastructure required to parse the device tree
idle states bindings and initialize the corresponding CPUidle driver states
data.

Code that initializes idle states checks the CPU idle driver cpumask so
that multiple CPU idle drivers can be initialized through it in the
kernel. The CPU idle driver cpumask defines which idle states should be
considered valid for the driver, ie idle states that are valid on a set
of cpus the idle driver manages.

Signed-off-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>

firewire: revert to 4 GB RDMA, fix protocols using Memory Space

Undo a feature introduced in v3.14 by commit fcd46b34425d
"firewire: Enable remote DMA above 4 GB".  That change raised the
minimum address at which protocol drivers and user programs can register
for request reception from 0x0001'0000'0000 to 0x8000'0000'0000.
It turned out that at least one vendor-specific protocol exists which
uses lower addresses:  https://bugzilla.kernel.org/show_bug.cgi?id=76921

For the time being, revert most of commit fcd46b34425d so that affected
protocols work like with kernel v3.13 and before.  Just keep the valid
documentation parts from the regressing commit, and the ability to
identify controllers which could be programmed to accept >32 bit
physical DMA addresses.  The rest of fcd46b34425d should probably be
brought back as an optional instead of default feature.

Reported-by: Fabien Spindler <fabien.spindler@inria.fr>
Cc: <stable@vger.kernel.org> # 3.14+
Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de>

expand dentry_kill(dentry, 0) in shrink_dentry_list()

Result will be massaged to saner shape in the next commits.  It is
ugly, no questions - the point of that one is to be a provably
equivalent transformation (and it might be worth splitting a bit
more).

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

split dentry_kill()

... into trylocks and everything else.  The latter (actual killing)
is __dentry_kill().

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>

arm64: mm: fix pmd_write CoW brokenness

Commit 9c7e535fcc17 ("arm64: mm: Route pmd thp functions through pte
equivalents") changed the pmd manipulator and accessor functions to
convert the target pmd to a pte, process it with the pte functions, then
convert it back. Along the way, we gained support for PTE_WRITE, however
this is completely ignored by set_pmd_at, and so we fail to set the
PMD_SECT_RDONLY for PMDs, resulting in all sorts of lovely failures (like
CoW not working).

Partially reverting the offending commit (by making use of
PMD_SECT_RDONLY explicitly for pmd_{write,wrprotect,mkwrite} functions)
leads to further issues because pmd_write can then return potentially
incorrect values for page table entries marked as RDONLY, leading to
BUG_ON(pmd_write(entry)) tripping under some THP workloads.

This patch fixes the issue by routing set_pmd_at through set_pte_at,
which correctly takes the PTE_WRITE flag into account. Given that
THP mappings are always anonymous, the additional cache-flushing code
in __sync_icache_dcache won't impose any significant overhead as the
flush will be skipped.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Steve Capper <steve.capper@arm.com>
Tested-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

Merge tag 'sound-3.15-rc8' of git://git./linux/kernel/git/tiwai/sound

Pull sound fixes from Takashi Iwai:
 "Just two small stable fixes: an HD-audio fix for the new Intel
  chipsets and a PM handling fix in PCM dmaengine core"

* tag 'sound-3.15-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
  ALSA: hda - Fix onboard audio on Intel H97/Z97 chipsets
  ALSA: pcm_dmaengine: Add check during device suspend

Merge branch 'for-linus' of git://git./linux/kernel/git/viro/vfs

Pull vfs fix from Al Viro:
 "Oh, well...  Still nothing useful on that livelock (I had something
  that looked kinda-sorta like a non-invasive solution, but it
  deadlocks), so it's just Miklos' vmsplice fix for now"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs:
  vfs: fix vmplice_to_user()

ARM: 8063/1: bL_switcher: fix individual online status reporting of removed CPUs

The content of /sys/devices/system/cpu/cpu*/online  is still 1 for those
CPUs that the switcher has removed even though the global state in
/sys/devices/system/cpu/online is updated correctly.

It turns out that commit 0902a9044f ("Driver core: Use generic
offline/online for CPU offline/online") has changed the way those files
retrieve their content by relying on on the generic attribute handling
code.  The switcher, by calling cpu_down() directly, bypasses this
handling and the attribute value doesn't get updated.

Fix this by calling device_offline()/device_online() instead.

Signed-off-by: Nicolas Pitre <nico@linaro.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

rtmutex: Fix deadlock detector for real

The current deadlock detection logic does not work reliably due to the
following early exit path:

/*
 * Drop out, when the task has no waiters. Note,
 * top_waiter can be NULL, when we are in the deboosting
 * mode!
 */
if (top_waiter && (!task_has_pi_waiters(task) ||
   top_waiter != task_top_pi_waiter(task)))
goto out_unlock_pi;

So this not only exits when the task has no waiters, it also exits
unconditionally when the current waiter is not the top priority waiter
of the task.

So in a nested locking scenario, it might abort the lock chain walk
and therefor miss a potential deadlock.

Simple fix: Continue the chain walk, when deadlock detection is
enabled.

We also avoid the whole enqueue, if we detect the deadlock right away
(A-A). It's an optimization, but also prevents that another waiter who
comes in after the detection and before the task has undone the damage
observes the situation and detects the deadlock and returns
-EDEADLOCK, which is wrong as the other task is not in a deadlock
situation.

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Peter Zijlstra <peterz@infradead.org>
Reviewed-by: Steven Rostedt <rostedt@goodmis.org>
Cc: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/r/20140522031949.725272460@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Merge tag 'for-linus' of git://git./virt/kvm/kvm

Pull kvm fixes from Paolo Bonzini:
 "Small fixes for x86, slightly larger fixes for PPC, and a forgotten
  s390 patch.  The PPC fixes are important because they fix breakage
  that is new in 3.15"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  KVM: s390: announce irqfd capability
  KVM: x86: disable master clock if TSC is reset during suspend
  KVM: vmx: disable APIC virtualization in nested guests
  KVM guest: Make pv trampoline code executable
  KVM: PPC: Book3S: ifdef on CONFIG_KVM_BOOK3S_32_HANDLER for 32bit
  KVM: PPC: Book3S HV: Add missing code for transaction reclaim on guest exit
  KVM: PPC: Book3S: HV: make _PAGE_NUMA take effect

Merge branch 'merge' of git://git./linux/kernel/git/benh/powerpc

Pull two powerpc fixes from Ben Herrenschmidt:
 "Here's a pair of powerpc fixes for 3.15 which are also going to
  stable.

  One's a fix for building with newer binutils (the problem currently
  only affects the BookE kernels but the affected macro might come back
  into use on BookS platforms at any time).  Unfortunately, the binutils
  maintainer did a backward incompatible change to a construct that we
  use so we have to add Makefile check.

  The other one is a fix for CPUs getting stuck in kexec when running
  single threaded.  Since we routinely use kexec on power (including in
  our newer bootloaders), I deemed that important enough"

* 'merge' of git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc:
  powerpc, kexec: Fix "Processor X is stuck" issue during kexec from ST mode
  powerpc: Fix 64 bit builds with binutils 2.24

lift the "already marked killed" case into shrink_dentry_list()

It can happen only when dentry_kill() is called with unlock_on_failure
equal to 0 - other callers had dentry pinned until the moment they've
got ->d_lock and DCACHE_DENTRY_KILLED is set only after lockref_mark_dead().

IOW, only one of three call sites of dentry_kill() might end up reaching
that code.  Just move it there.

Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>