Merge tag 'nfsd-4.7-1' of git://linux-nfs.org/~bfields/linux

Pull nfsd bugfixes from Bruce Fields:
 "Oleg Drokin found and fixed races in the nfsd4 state code that go back
  to the big nfs4_lock_state removal around 3.17 (but that were also
  probably hard to reproduce before client changes in 3.20 allowed the
  client to perform parallel opens).

  Also fix a 4.1 backchannel crash due to rpc multipath changes in 4.6.
  Trond acked the client-side rpc fixes going through my tree"

* tag 'nfsd-4.7-1' of git://linux-nfs.org/~bfields/linux:
  nfsd: Make init_open_stateid() a bit more whole
  nfsd: Extend the mutex holding region around in nfsd4_process_open2()
  nfsd: Always lock state exclusively.
  rpc: share one xps between all backchannels
  nfsd4/rpc: move backchannel create logic into rpc code
  SUNRPC: fix xprt leak on xps allocation failure
  nfsd: Fix NFSD_MDS_PR_KEY on 32-bit by adding ULL postfix

Merge branch 'overlayfs-linus' of git://git./linux/kernel/git/mszeredi/vfs

Pull overlayfs fixes from Miklos Szeredi:
 "This contains two regression fixes: one for the xattr API update and
  one for using the mounter's creds in file creation in overlayfs.

  There's also a fix for a bug in handling hard linked AF_UNIX sockets
  that's been there from day one.  This fix is overlayfs only despite
  the fact that it touches code outside the overlay filesystem: d_real()
  is an identity function for all except overlay dentries"

* 'overlayfs-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/vfs:
  ovl: fix uid/gid when creating over whiteout
  ovl: xattr filter fix
  af_unix: fix hard linked sockets on overlay
  vfs: add d_real_inode() helper

KEYS: potential uninitialized variable

If __key_link_begin() failed then "edit" would be uninitialized.  I've
added a check to fix that.

This allows a random user to crash the kernel, though it's quite
difficult to achieve.  There are three ways it can be done as the user
would have to cause an error to occur in __key_link():

 (1) Cause the kernel to run out of memory.  In practice, this is difficult
     to achieve without ENOMEM cropping up elsewhere and aborting the
     attempt.

 (2) Revoke the destination keyring between the keyring ID being looked up
     and it being tested for revocation.  In practice, this is difficult to
     time correctly because the KEYCTL_REJECT function can only be used
     from the request-key upcall process.  Further, users can only make use
     of what's in /sbin/request-key.conf, though this does including a
     rejection debugging test - which means that the destination keyring
     has to be the caller's session keyring in practice.

 (3) Have just enough key quota available to create a key, a new session
     keyring for the upcall and a link in the session keyring, but not then
     sufficient quota to create a link in the nominated destination keyring
     so that it fails with EDQUOT.

The bug can be triggered using option (3) above using something like the
following:

echo 80 >/proc/sys/kernel/keys/root_maxbytes
keyctl request2 user debug:fred negate @t

The above sets the quota to something much lower (80) to make the bug
easier to trigger, but this is dependent on the system.  Note also that
the name of the keyring created contains a random number that may be
between 1 and 10 characters in size, so may throw the test off by
changing the amount of quota used.

Assuming the failure occurs, something like the following will be seen:

kfree_debugcheck: out of range ptr 6b6b6b6b6b6b6b68h
------------[ cut here ]------------
kernel BUG at ../mm/slab.c:2821!
...
RIP: 0010:[<ffffffff811600f9>] kfree_debugcheck+0x20/0x25
RSP: 0018:ffff8804014a7de8  EFLAGS: 00010092
RAX: 0000000000000034 RBX: 6b6b6b6b6b6b6b68 RCX: 0000000000000000
RDX: 0000000000040001 RSI: 00000000000000f6 RDI: 0000000000000300
RBP: ffff8804014a7df0 R08: 0000000000000001 R09: 0000000000000000
R10: ffff8804014a7e68 R11: 0000000000000054 R12: 0000000000000202
R13: ffffffff81318a66 R14: 0000000000000000 R15: 0000000000000001
...
Call Trace:
  kfree+0xde/0x1bc
  assoc_array_cancel_edit+0x1f/0x36
  __key_link_end+0x55/0x63
  key_reject_and_link+0x124/0x155
  keyctl_reject_key+0xb6/0xe0
  keyctl_negate_key+0x10/0x12
  SyS_keyctl+0x9f/0xe7
  do_syscall_64+0x63/0x13a
  entry_SYSCALL64_slow_path+0x25/0x25

Fixes: f70e2e06196a ('KEYS: Do preallocation for __key_link()')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: stable@vger.kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

arm64: kgdb: Match pstate size with gdbserver protocol

Current versions of gdb do not interoperate cleanly with kgdb on arm64
systems because gdb and kgdb do not use the same register description.
This patch modifies kgdb to work with recent releases of gdb (>= 7.8.1).

Compatibility with gdb (after the patch is applied) is as follows:

  gdb-7.6 and earlier  Ok
  gdb-7.7 series       Works if user provides custom target description
  gdb-7.8(.0)          Works if user provides custom target description
  gdb-7.8.1 and later  Ok

When commit 44679a4f142b ("arm64: KGDB: Add step debugging support") was
introduced it was paired with a gdb patch that made an incompatible
change to the gdbserver protocol. This patch was eventually merged into
the gdb sources:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=a4d9ba85ec5597a6a556afe26b712e878374b9dd

The change to the protocol was mostly made to simplify big-endian support
inside the kernel gdb stub. Unfortunately the gdb project released
gdb-7.7.x and gdb-7.8.0 before the protocol incompatibility was identified
and reversed:
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=bdc144174bcb11e808b4e73089b850cf9620a7ee

This leaves us in a position where kgdb still uses the no-longer-used
protocol; gdb-7.8.1, which restored the original behaviour, was
released on 2014-10-29.

I don't believe it is possible to detect/correct the protocol
incompatiblity which means the kernel must take a view about which
version of the gdb remote protocol is "correct". This patch takes the
view that the original/current version of the protocol is correct
and that version found in gdb-7.7.x and gdb-7.8.0 is anomalous.

Signed-off-by: Daniel Thompson <daniel.thompson@linaro.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>

PM / OPP: Add 'UNKNOWN' status for shared_opp in struct opp_table

dev_pm_opp_get_sharing_cpus() returns 0 even in the case when the OPP
core doesn't know whether or not the table is shared. It works on the
majority of platforms, where the OPP table is never created before
invoking the function and then -ENODEV is returned by it.

But in the case of one platform (Jetson TK1) at least, the situation
is a bit different. The OPP table has been created (somehow) before
dev_pm_opp_get_sharing_cpus() is called and it returns 0. Its caller
treats that as 'the CPUs don't share OPPs' and that leads to degraded
performance.

Fix this by converting 'shared_opp' in struct opp_table to an enum
and making dev_pm_opp_get_sharing_cpus() return -EINVAL in case when
the value of that field is "access unknown", so that the caller can
handle it accordingly (cpufreq-dt considers that as 'all CPUs share
the table', for example).

Fixes: 6f707daa3833 "PM / OPP: Add dev_pm_opp_get_sharing_cpus()"
Reported-and-tested-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
[ rjw : Subject & changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

s390/cpum_cf: use perf software context for hardware counters

On s390, there are two different hardware PMUs for counting and
sampling.  Previously, both PMUs have shared the perf_hw_context
which is not correct and, recently, results in this warning:

    ------------[ cut here ]------------
    WARNING: CPU: 5 PID: 1 at kernel/events/core.c:8485 perf_pmu_register+0x420/0x428
    Modules linked in:
    CPU: 5 PID: 1 Comm: swapper/0 Not tainted 4.7.0-rc1+ #2
    task: 00000009c5240000 ti: 00000009c5234000 task.ti: 00000009c5234000
    Krnl PSW : 0704c00180000000 0000000000220c50 (perf_pmu_register+0x420/0x428)
               R:0 T:1 IO:1 EX:1 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
    Krnl GPRS: ffffffffffffffff 0000000000b15ac6 0000000000000000 00000009cb440000
               000000000022087a 0000000000000000 0000000000b78fa0 0000000000000000
               0000000000a9aa90 0000000000000084 0000000000000005 000000000088a97a
               0000000000000004 0000000000749dd0 000000000022087a 00000009c5237cc0
    Krnl Code: 0000000000220c44: a7f4ff54            brc     15,220aec
               0000000000220c48: 92011000           mvi     0(%r1),1
              #0000000000220c4c: a7f40001           brc     15,220c4e
              >0000000000220c50: a7f4ff12           brc     15,220a74
               0000000000220c54: 0707               bcr     0,%r7
               0000000000220c56: 0707               bcr     0,%r7
               0000000000220c58: ebdff0800024       stmg    %r13,%r15,128(%r15)
               0000000000220c5e: a7f13fe0           tmll    %r15,16352
    Call Trace:
    ([<000000000022087a>] perf_pmu_register+0x4a/0x428)
    ([<0000000000b2c25c>] init_cpum_sampling_pmu+0x14c/0x1f8)
    ([<0000000000100248>] do_one_initcall+0x48/0x140)
    ([<0000000000b25d26>] kernel_init_freeable+0x1e6/0x2a0)
    ([<000000000072bda4>] kernel_init+0x24/0x138)
    ([<000000000073495e>] kernel_thread_starter+0x6/0xc)
    ([<0000000000734958>] kernel_thread_starter+0x0/0xc)
    Last Breaking-Event-Address:
     [<0000000000220c4c>] perf_pmu_register+0x41c/0x428
    ---[ end trace 0c6ef9f5b771ad97 ]---

Using the perf_sw_context is an option because the cpum_cf PMU does
not use interrupts.  To make this more clear, initialize the
capabilities in the PMU structure.

Signed-off-by: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Acked-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

memory: omap-gpmc: Fix omap gpmc EXTRADELAY timing

In the omap gpmc driver it can be noticed that GPMC_CONFIG4_OEEXTRADELAY
is overwritten by the WEEXTRADELAY value from the device tree and
GPMC_CONFIG4_WEEXTRADELAY is not updated by the value from the device
tree.

As a consequence, the memory accesses cannot be configured properly when
the extra delay are needed for OE and WE.

Fix the update of GPMC_CONFIG4_WEEXTRADELAY with the value from the
device tree file and prevents GPMC_CONFIG4_OEXTRADELAY
being overwritten by the WEXTRADELAY value from the device tree.

Cc: stable@vger.kernel.org
Signed-off-by: Ocquidant, Sebastien <sebastienocquidant@eaton.com>
Signed-off-by: Roger Quadros <rogerq@ti.com>

kvm: vmx: check apicv is active before using VT-d posted interrupt

VT-d posted interrupt is relying on the CPU side's posted interrupt.
Need to check whether VCPU's APICv is active before enabing VT-d
posted interrupt.

Fixes: d62caabb41f33d96333f9ef15e09cd26e1c12760
Cc: stable@vger.kernel.org
Signed-off-by: Yang Zhang <yang.zhang.wz@gmail.com>
Signed-off-by: Shengge Ding <shengge.dsg@alibaba-inc.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

kvm: Fix irq route entries exceeding KVM_MAX_IRQ_ROUTES

These days, we experienced one guest crash with 8 cores and 3 disks,
with qemu error logs as bellow:

qemu-system-x86_64: /build/qemu-2.0.0/kvm-all.c:984:
kvm_irqchip_commit_routes: Assertion `ret == 0' failed.

And then we found one patch(bdf026317d) in qemu tree, which said
could fix this bug.

Execute the following script will reproduce the BUG quickly:

irq_affinity.sh
========================================================================

vda_irq_num=25
vdb_irq_num=27
while [ 1 ]
do
    for irq in {1,2,4,8,10,20,40,80}
        do
            echo $irq > /proc/irq/$vda_irq_num/smp_affinity
            echo $irq > /proc/irq/$vdb_irq_num/smp_affinity
            dd if=/dev/vda of=/dev/zero bs=4K count=100 iflag=direct
            dd if=/dev/vdb of=/dev/zero bs=4K count=100 iflag=direct
        done
done
========================================================================

The following qemu log is added in the qemu code and is displayed when
this bug reproduced:

kvm_irqchip_commit_routes: max gsi: 1008, nr_allocated_irq_routes: 1024,
irq_routes->nr: 1024, gsi_count: 1024.

That's to say when irq_routes->nr == 1024, there are 1024 routing entries,
but in the kernel code when routes->nr >= 1024, will just return -EINVAL;

The nr is the number of the routing entries which is in of
[1 ~ KVM_MAX_IRQ_ROUTES], not the index in [0 ~ KVM_MAX_IRQ_ROUTES - 1].

This patch fix the BUG above.

Cc: stable@vger.kernel.org
Signed-off-by: Xiubo Li <lixiubo@cmss.chinamobile.com>
Signed-off-by: Wei Tang <tangwei@cmss.chinamobile.com>
Signed-off-by: Zhang Zhuoyu <zhangzhuoyu@cmss.chinamobile.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

coresight: Handle build path error

Enabling a component via sysfs (echo 1 > enable_source), would
trigger building a path from the enabled sources to the sink.
If there is an error in the process (e.g, sink not enabled or
the device (CPU corresponding to ETM) is not online), we never report
failure, except for leaving a message in the dmesg.

Do proper error checking for the build path and return the error.

Before:
 $ echo 0 > /sys/devices/system/cpu/cpu2/online
 $ echo 1 > /sys/devices/cs_etm/cpu2/enable_source
 $ echo $?
 0

After:
 $ echo 0 > /sys/devices/system/cpu/cpu2/online
 $ echo 1 > /sys/devices/cs_etm/cpu2/enable_source
 -bash: echo: write error: No such device or address

Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Acked-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

coresight: Fix erroneous memset in tmc_read_unprepare_etr

At the end of a trace collection, we try to clear the entire buffer
and enable the ETR back if it was already enabled. But, we would have
adjusted the drvdata->buf to point to the beginning of the trace data
in the trace buffer @drvdata->vaddr. So, the following code which
clears the buffer is dangerous and can cause crashes, like below :

memset(drvdata->buf, 0, drvdata->size);

 Unable to handle kernel paging request at virtual address ffffff800a145000
 pgd = ffffffc974726000
 *pgd=00000009f3e91003, *pud=00000009f3e91003, *pmd=0000000000000000
 PREEMPT SMP
 Modules linked in:
 CPU: 4 PID: 1692 Comm: dd Not tainted 4.7.0-rc2+ #1721
 Hardware name: ARM Juno development board (r0) (DT)
 task: ffffffc9734a0080 ti: ffffffc974460000 task.ti: ffffffc974460000
 PC is at __memset+0x1ac/0x200
 LR is at tmc_read_unprepare_etr+0x144/0x1bc
 pc : [<ffffff80083a05ac>] lr : [<ffffff800859c984>] pstate: 200001c5
 ...
 [<ffffff80083a05ac>] __memset+0x1ac/0x200
 [<ffffff800859b2e4>] tmc_release+0x90/0x94
 [<ffffff8008202f58>] __fput+0xa8/0x1ec
 [<ffffff80082030f4>] ____fput+0xc/0x14
 [<ffffff80080c3ef8>] task_work_run+0xb0/0xe4
 [<ffffff8008088bf4>] do_notify_resume+0x64/0x6c
 [<ffffff8008084d5c>] work_pending+0x10/0x14
 Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428)

Since we clear the buffer anyway in the following call to
tmc_etr_enable_hw(), remove the erroneous memset().

Fixes: commit de5461970b3e9e1 ("coresight: tmc: allocating memory when needed")
Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

coresight: Fix tmc_read_unprepare_etr

At the end of the trace capture, we free the allocated memory,
resetting the drvdata->buf to NULL, to indicate that trace data
was collected and the next trace session should allocate the
memory in tmc_enable_etr_sink_sysfs.

The tmc_enable_etr_sink_sysfs, we only allocate memory if drvdata->vaddr
is not NULL (which is not performed at the end of previous session).
This can cause, drvdata->vaddr getting assigned NULL and later we do
memset() which causes a crash as below :

Unable to handle kernel NULL pointer dereference at virtual
 address  00000000
pgd = ffffffc9747f0000
[00000000] *pgd=00000009f402e003, *pud=00000009f402e003,
 *pmd=0000000000000000
Internal error: Oops: 96000046 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 1592 Comm: bash Not tainted 4.7.0-rc1+ #1712
Hardware name: ARM Juno development board (r0) (DT)
task: ffffffc078fe0080 ti: ffffffc974178000 task.ti: ffffffc974178000
PC is at __memset+0x1ac/0x200
LR is at tmc_enable_etr_sink+0xf8/0x304
pc : [<ffffff80083a002c>] lr : [<ffffff800859be44>] pstate: 400001c5
sp : ffffffc97417bc00
x29: ffffffc97417bc00 x28: ffffffc974178000

Call trace:
Exception stack(0xffffffc97417ba40 to 0xffffffc97417bb60)
ba40: 0000000000000001 ffffffc974a5d098 ffffffc97417bc00 ffffff80083a002c
ba60: ffffffc974a5d118 0000000000000000 0000000000000000 0000000000000000
ba80: 0000000000000001 0000000000000000 ffffff800859bdec 0000000000000040
baa0: ffffff8008b45b58 00000000000001c0 ffffffc97417baf0 ffffff80080eddb4
bac0: 0000000000000003 ffffffc078fe0080 ffffffc078fe0960 ffffffc078fe0940
bae0: 0000000000000000 0000000000000000 00000000007fffc0 0000000000000004
bb00: 0000000000000000 0000000000000040 000000000000003f 0000000000000000
bb20: 0000000000000000 0000000000000000 0000000000000000 0000000000000001
bb40: ffffffc078fe0960 0000000000000018 ffffffffffffffff 0008669628000000
[<ffffff80083a002c>] __memset+0x1ac/0x200
[<ffffff8008599814>] coresight_enable_path+0xa8/0x1dc
[<ffffff8008599b10>] coresight_enable+0x88/0x1b8
[<ffffff8008599d88>] enable_source_store+0x3c/0x6c
[<ffffff800845eaf4>] dev_attr_store+0x18/0x28
[<ffffff80082829e8>] sysfs_kf_write+0x54/0x64
[<ffffff8008281c30>] kernfs_fop_write+0x148/0x1d8
[<ffffff8008200128>] __vfs_write+0x28/0x110
[<ffffff8008200e88>] vfs_write+0xa0/0x198
[<ffffff80082021b0>] SyS_write+0x44/0xa0
[<ffffff8008084e70>] el0_svc_naked+0x24/0x28
Code: 91010108 54ffff4a 8b040108 cb050042 (d50b7428)

This patch fixes the issue by clearing the drvdata->vaddr while we free
the allocated buffer at the end of a session, so that we allocate the
memory again.

Cc: mathieu.poirier@linaro.org
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

coresight: Fix NULL pointer dereference in _coresight_build_path

_coresight_build_path assumes that all the connections of a csdev
has the child_dev initialised. This may not be true if the particular
component is not supported by the kernel config(e.g TPIU) but is
present in the DT. In which case, building a path can cause a crash like this :

  Unable to handle kernel NULL pointer dereference at virtual address 00000010
  pgd = ffffffc9750dd000
  [00000010] *pgd=00000009f5e90003, *pud=00000009f5e90003, *pmd=0000000000000000
  Internal error: Oops: 96000006 [#1] PREEMPT SMP
  Modules linked in:
  CPU: 4 PID: 1348 Comm: bash Not tainted 4.6.0-next-20160517 #1646
  Hardware name: ARM Juno development board (r0) (DT)
  task: ffffffc97517a280 ti: ffffffc9762c4000 task.ti: ffffffc9762c4000
  PC is at _coresight_build_path+0x18/0xe4
  LR is at _coresight_build_path+0xc0/0xe4
  pc : [<ffffff80083d5130>] lr : [<ffffff80083d51d8>] pstate: 20000145
  sp : ffffffc9762c7ba0

  [<ffffff80083d5130>] _coresight_build_path+0x18/0xe4
  [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4
  [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4
  [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4
  [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4
  [<ffffff80083d51d8>] _coresight_build_path+0xc0/0xe4
  [<ffffff80083d5cdc>] coresight_build_path+0x40/0x68
  [<ffffff80083d5e14>] coresight_enable+0x74/0x1bc
  [<ffffff80083d60a0>] enable_source_store+0x3c/0x6c
  [<ffffff800830b17c>] dev_attr_store+0x18/0x28
  [<ffffff80081ca9c4>] sysfs_kf_write+0x40/0x50
  [<ffffff80081c9e38>] kernfs_fop_write+0x140/0x1cc
  [<ffffff8008163ec8>] __vfs_write+0x28/0x110
  [<ffffff8008164bf0>] vfs_write+0xa0/0x174
  [<ffffff8008165d18>] SyS_write+0x44/0xa0
  [<ffffff8008084e70>] el0_svc_naked+0x24/0x28

Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Suzuki K Poulose <suzuki.poulose@arm.com>
Signed-off-by: Mathieu Poirier <mathieu.poirier@linaro.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'extcon-fixes-for-4.7-rc4' of git://git./linux/kernel/git/chanwoo/extcon into char-misc-linus

Chanwoo writes:

Update extcon for v4.7-rc4

This patch fixes the following issue:
- In the extcon-palmas.c, fix the state of VBUS when using GPIO detection.
If probe funticon don't check the state during probe, the extcon client
driver cannot get the state of VBUS gpio until the user detach the connector
and attach the connector again.

Merge tag 'drm-fixes-for-v4.7-rc4' of git://people.freedesktop.org/~airlied/linux

Pull drm fixes from Dave Airlie:
 "The main drm fixes pull for rc4: one regression fix in the connector
  refcounting, and an MST fix.

  There rest is nouveau, amdkfd, i915, etnaviv, and radeon/amdgpu fixes,
  mostly regression or black screen fixes"

* tag 'drm-fixes-for-v4.7-rc4' of git://people.freedesktop.org/~airlied/linux: (23 commits)
  drm/etnaviv: initialize iommu domain page size
  drm/nouveau/iccsense: fix memory leak
  drm/nouveau/Revert "drm/nouveau/device/pci: set as non-CPU-coherent on ARM64"
  drm/amd/powerplay: select samu dpm 0 as boot level on polaris.
  drm/amd/powerplay: update powerplay table parsing
  drm/dp/mst: Always clear proposed vcpi table for port.
  drm/crtc: only store the necessary data for set_config rollback
  drm/crtc: fix connector reference counting mismatch in drm_crtc_helper_set_config
  drm/i915/ilk: Don't disable SSC source if it's in use
  Revert "drm/amdgpu: add pipeline sync while vmid switch in same ctx"
  drm/amdgpu/gfx7: fix broken condition check
  drm/radeon: fix asic initialization for virtualized environments
  amdgpu: fix asic initialization for virtualized environments (v2)
  drm/radeon: don't use fractional dividers on RS[78]80 if SS is enabled
  drm/radeon: do not hard reset GPU while freezing on r600/r700 family
  drm/i915: Extract physical display dimensions from VBT
  drm/i915: Check VBT for port presence in addition to the strap on VLV/CHV
  drm/i915: Only ignore eDP ports that are connected
  drm/i915: Silence "unexpected child device config size" for VBT on 845g
  drm/i915: Fix NULL pointer deference when out of PLLs in IVB
  ...

Merge tag 'platform-drivers-x86-v4.7-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86

Pull x86 platform driver fixes from Darren Hart:
 "Minor kconfig dependency cleanup, trivial mic mute hotkey for ideapad,
  and a needed improvement in adaptive keyboard detection for thinkpad:

  platform/x86:
   - Drop duplicate dependencies on X86

  thinkpad_acpi:
   - Add support for HKEY version 0x200

  ideapad_laptop:
   - Add an event for mic mute hotkey"

* tag 'platform-drivers-x86-v4.7-2' of git://git.infradead.org/users/dvhart/linux-platform-drivers-x86:
  platform/x86: Drop duplicate dependencies on X86
  thinkpad_acpi: Add support for HKEY version 0x200
  ideapad_laptop: Add an event for mic mute hotkey

Merge tag 'upstream-4.7-rc4' of git://git.infradead.org/linux-ubifs

Pull UBI fixes from Richard Weinberger:
 "This contains fixes for a regression introduced in rc1"

* tag 'upstream-4.7-rc4' of git://git.infradead.org/linux-ubifs:
  ubi: Don't bypass ->getattr()
  Revert "mtd: switch open_mtd_by_chdev() to use of vfs_stat()"
  Revert "mtd: switch ubi_open_volume_path() to vfs_stat()"

base: make module_create_drivers_dir race-free

Modules which register drivers via standard path (driver_register) in
parallel can cause a warning:
WARNING: CPU: 2 PID: 3492 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80
sysfs: cannot create duplicate filename '/module/saa7146/drivers'
Modules linked in: hexium_gemini(+) mxb(+) ...
...
Call Trace:
...
 [<ffffffff812e63a2>] sysfs_warn_dup+0x62/0x80
 [<ffffffff812e6487>] sysfs_create_dir_ns+0x77/0x90
 [<ffffffff8140f2c4>] kobject_add_internal+0xb4/0x340
 [<ffffffff8140f5b8>] kobject_add+0x68/0xb0
 [<ffffffff8140f631>] kobject_create_and_add+0x31/0x70
 [<ffffffff8157a703>] module_add_driver+0xc3/0xd0
 [<ffffffff8155e5d4>] bus_add_driver+0x154/0x280
 [<ffffffff815604c0>] driver_register+0x60/0xe0
 [<ffffffff8145bed0>] __pci_register_driver+0x60/0x70
 [<ffffffffa0273e14>] saa7146_register_extension+0x64/0x90 [saa7146]
 [<ffffffffa0033011>] hexium_init_module+0x11/0x1000 [hexium_gemini]
...

As can be (mostly) seen, driver_register causes this call sequence:
  -> bus_add_driver
    -> module_add_driver
      -> module_create_drivers_dir
The last one creates "drivers" directory in /sys/module/<...>. When
this is done in parallel, the directory is attempted to be created
twice at the same time.

This can be easily reproduced by loading mxb and hexium_gemini in
parallel:
while :; do
  modprobe mxb &
  modprobe hexium_gemini
  wait
  rmmod mxb hexium_gemini saa7146_vv saa7146
done

saa7146 calls pci_register_driver for both mxb and hexium_gemini,
which means /sys/module/saa7146/drivers is to be created for both of
them.

Fix this by a new mutex in module_create_drivers_dir which makes the
test-and-create "drivers" dir atomic.

I inverted the condition and removed 'return' to avoid multiple
unlocks or a goto.

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Fixes: fe480a2675ed (Modules: only add drivers/ direcory if needed)
Cc: v2.6.21+ <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Merge tag 'for-linus-4.7-2' of git://git.code.sf.net/p/openipmi/linux-ipmi

Pull ipmi bugfix from Corey Minyard:
 "Fix a fairly significant ipmi list bug

  This bug could cause lists to be corrupted"

* tag 'for-linus-4.7-2' of git://git.code.sf.net/p/openipmi/linux-ipmi:
  ipmi: Remove smi_msg from waiting_rcv_msgs list before handle_one_recv_msg()

nfsd: Make init_open_stateid() a bit more whole

Move the state selection logic inside from the caller,
always making it return correct stp to use.

Signed-off-by: J . Bruce Fields <bfields@fieldses.org>
Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

nfsd: Extend the mutex holding region around in nfsd4_process_open2()

To avoid racing entry into nfs4_get_vfs_file().
Make init_open_stateid() return with locked stateid to be unlocked
by the caller.

Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

nfsd: Always lock state exclusively.

It used to be the case that state had an rwlock that was locked for write
by downgrades, but for read for upgrades (opens). Well, the problem is
if there are two competing opens for the same state, they step on
each other toes potentially leading to leaking file descriptors
from the state structure, since access mode is a bitmap only set once.

Signed-off-by: Oleg Drokin <green@linuxhacker.ru>
Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

Merge tag 'for_linus' of git://git./linux/kernel/git/mst/vhost

Pull virtio docs and tests from Michael Tsirkin:
 "This merely has some documentation and a new test, seems safe to
  merge"

* tag 'for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost:
  tools/virtio: add noring tool
  tools/virtio/ringtest: fix run-on-all.sh to work without /dev/cpu
  tools/virtio/ringtest: add usage example to README
  MAINTAINERS: Add file patterns for virtio device tree bindings

Update email addresses in MAINTAINERS and .mailmap

Updating email addresses in MAINTAINERS and .mailmap files.

Cc: stable@vger.kernel.org
Signed-off-by: Shuah Khan <shuahkh@osg.samsung.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

Update my main e-mails at the Kernel tree

For the third time in three years, I'm changing my e-mail at Samsung.
That's bad, as it may stop communications with me for a while.  So, this
time, I'll also add the mchehab@kernel.org e-mail, as it remains stable
since ever.

Cc: stable@vger.kernel.org
Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

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

radeon and amdgpu fixes for 4.7.  Highlights:
- fixes for GPU VM passthrough
- fixes for powerplay on Polaris GPUs
- pll fixes for rs780/880

* 'drm-fixes-4.7' of git://people.freedesktop.org/~agd5f/linux:
  drm/amd/powerplay: select samu dpm 0 as boot level on polaris.
  drm/amd/powerplay: update powerplay table parsing
  Revert "drm/amdgpu: add pipeline sync while vmid switch in same ctx"
  drm/amdgpu/gfx7: fix broken condition check
  drm/radeon: fix asic initialization for virtualized environments
  amdgpu: fix asic initialization for virtualized environments (v2)
  drm/radeon: don't use fractional dividers on RS[78]80 if SS is enabled
  drm/radeon: do not hard reset GPU while freezing on r600/r700 family

kvm: svm: Do not support AVIC if not CONFIG_X86_LOCAL_APIC

Add logic to disable AVIC #ifndef CONFIG_X86_LOCAL_APIC.

Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

kvm: svm: Fix implicit declaration for __default_cpu_present_to_apicid()

The commit 8221c1370056 ("svm: Manage vcpu load/unload when enable AVIC")
introduces a build error due to implicit function declaration
when #ifdef CONFIG_X86_32 and #ifndef CONFIG_X86_LOCAL_APIC
(as reported by Kbuild test robot i386-randconfig-x0-06121009).

So, this patch introduces kvm_cpu_get_apicid() wrapper
around __default_cpu_present_to_apicid() with additional
handling if CONFIG_X86_LOCAL_APIC is not defined.

Reported-by: kbuild test robot <fengguang.wu@intel.com>
Fixes: commit 8221c1370056 ("svm: Manage vcpu load/unload when enable AVIC")
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

Merge branch 'drm-etnaviv-fixes' of git://git.pengutronix.de/git/lst/linux into drm-fixes

just a single fix for a regression introduced by IOMMU API changes in
v4.7.

* 'drm-etnaviv-fixes' of git://git.pengutronix.de/git/lst/linux:
  drm/etnaviv: initialize iommu domain page size

rpc: share one xps between all backchannels

The spec allows backchannels for multiple clients to share the same tcp
connection.  When that happens, we need to use the same xprt for all of
them.  Similarly, we need the same xps.

This fixes list corruption introduced by the multipath code.

Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Acked-by: Trond Myklebust <trondmy@primarydata.com>

nfsd4/rpc: move backchannel create logic into rpc code

Also simplify the logic a bit.

Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Acked-by: Trond Myklebust <trondmy@primarydata.com>

SUNRPC: fix xprt leak on xps allocation failure

Callers of rpc_create_xprt expect it to put the xprt on success and
failure.

Cc: stable@vger.kernel.org
Signed-off-by: J. Bruce Fields <bfields@redhat.com>
Acked-by: Trond Myklebust <trondmy@primarydata.com>

ovl: fix uid/gid when creating over whiteout

Fix a regression when creating a file over a whiteout.  The new
file/directory needs to use the current fsuid/fsgid, not the ones from the
mounter's credentials.

The refcounting is a bit tricky: prepare_creds() sets an original refcount,
override_creds() gets one more, which revert_cred() drops.  So

  1) we need to expicitly put the mounter's credentials when overriding
     with the updated one

  2) we need to put the original ref to the updated creds (and this can
     safely be done before revert_creds(), since we'll still have the ref
     from override_creds()).

Reported-by: Stephen Smalley <sds@tycho.nsa.gov>
Fixes: 3fe6e52f0626 ("ovl: override creds with the ones from the superblock mounter")
Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>

debugfs: open_proxy_open(): avoid double fops release

Debugfs' open_proxy_open(), the ->open() installed at all inodes created
through debugfs_create_file_unsafe(),
- grabs a reference to the original file_operations instance passed to
  debugfs_create_file_unsafe() via fops_get(),
- installs it at the file's ->f_op by means of replace_fops()
- and calls fops_put() on it.

Since the semantics of replace_fops() are such that the reference's
ownership is transferred, the subsequent fops_put() will result in a double
release when the file is eventually closed.

Currently, this is not an issue since fops_put() basically does a
module_put() on the file_operations' ->owner only and there don't exist any
modules calling debugfs_create_file_unsafe() yet. This is expected to
change in the future though, c.f. commit c64688081490 ("debugfs: add
support for self-protecting attribute file fops").

Remove the call to fops_put() from open_proxy_open().

Fixes: 9fd4dcece43a ("debugfs: prevent access to possibly dead
                      file_operations at file open")
Signed-off-by: Nicolai Stange <nicstange@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

debugfs: full_proxy_open(): free proxy on ->open() failure

Debugfs' full_proxy_open(), the ->open() installed at all inodes created
through debugfs_create_file(),
- grabs a reference to the original struct file_operations instance passed
  to debugfs_create_file(),
- dynamically allocates a proxy struct file_operations instance wrapping
  the original
- and installs this at the file's ->f_op.

Afterwards, it calls the original ->open() and passes its return value back
to the VFS layer.

Now, if that return value indicates failure, the VFS layer won't ever call
->release() and thus, neither the reference to the original file_operations
nor the memory for the proxy file_operations will get released, i.e. both
are leaked.

Upon failure of the original fops' ->open(), undo the proxy installation.
That is:
- Set the struct file ->f_op to what it had been when full_proxy_open()
  was entered.
- Drop the reference to the original file_operations.
- Free the memory holding the proxy file_operations.

Fixes: 49d200deaa68 ("debugfs: prevent access to removed files' private
                      data")
Signed-off-by: Nicolai Stange <nicstange@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

kernel/kcov: unproxify debugfs file's fops

Since commit 49d200deaa68 ("debugfs: prevent access to removed files'
private data"), a debugfs file's file_operations methods get proxied
through lifetime aware wrappers.

However, only a certain subset of the file_operations members is supported
by debugfs and ->mmap isn't among them -- it appears to be NULL from the
VFS layer's perspective.

This behaviour breaks the /sys/kernel/debug/kcov file introduced
concurrently with commit 5c9a8750a640 ("kernel: add kcov code coverage").

Since that file never gets removed, there is no file removal race and thus,
a lifetime checking proxy isn't needed.

Avoid the proxying for /sys/kernel/debug/kcov by creating it via
debugfs_create_file_unsafe() rather than debugfs_create_file().

Fixes: 49d200deaa68 ("debugfs: prevent access to removed files' private data")
Fixes: 5c9a8750a640 ("kernel: add kcov code coverage")
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Nicolai Stange <nicstange@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mnt: Account for MS_RDONLY in fs_fully_visible

In rare cases it is possible for s_flags & MS_RDONLY to be set but
MNT_READONLY to be clear.  This starting combination can cause
fs_fully_visible to fail to ensure that the new mount is readonly.
Therefore force MNT_LOCK_READONLY in the new mount if MS_RDONLY
is set on the source filesystem of the mount.

In general both MS_RDONLY and MNT_READONLY are set at the same for
mounts so I don't expect any programs to care.  Nor do I expect
MS_RDONLY to be set on proc or sysfs in the initial user namespace,
which further decreases the likelyhood of problems.

Which means this change should only affect system configurations by
paranoid sysadmins who should welcome the additional protection
as it keeps people from wriggling out of their policies.

Cc: stable@vger.kernel.org
Fixes: 8c6cf9cc829f ("mnt: Modify fs_fully_visible to deal with locked ro nodev and atime")
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>

arm64: spinlock: Ensure forward-progress in spin_unlock_wait

Rather than wait until we observe the lock being free (which might never
happen), we can also return from spin_unlock_wait if we observe that the
lock is now held by somebody else, which implies that it was unlocked
but we just missed seeing it in that state.

Furthermore, in such a scenario there is no longer a need to write back
the value that we loaded, since we know that there has been a lock
hand-off, which is sufficient to publish any stores prior to the
unlock_wait because the ARm architecture ensures that a Store-Release
instruction is multi-copy atomic when observed by a Load-Acquire
instruction.

The litmus test is something like:

AArch64
{
0:X1=x; 0:X3=y;
1:X1=y;
2:X1=y; 2:X3=x;
}
 P0          | P1           | P2           ;
 MOV W0,#1   | MOV W0,#1    | LDAR W0,[X1] ;
 STR W0,[X1] | STLR W0,[X1] | LDR W2,[X3]  ;
 DMB SY      |              |              ;
 LDR W2,[X3] |              |              ;
exists
(0:X2=0 /\ 2:X0=1 /\ 2:X2=0)

where P0 is doing spin_unlock_wait, P1 is doing spin_unlock and P2 is
doing spin_lock.

Signed-off-by: Will Deacon <will.deacon@arm.com>

iommu/rockchip: Fix zap cache during device attach

rk_iommu_command() takes a struct rk_iommu and iterates over the slave
MMUs, so this is doubly wrong in that we're passing in the wrong pointer
and talking to MMUs that we shouldn't be.

Fixes: cd6438c5f844 ("iommu/rockchip: Reconstruct to support multi slaves")
Cc: stable@vger.kernel.org
Signed-off-by: John Keeping <john@metanate.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Heiko Stuebner <heiko@sntech.de>
Signed-off-by: Joerg Roedel <jroedel@suse.de>

drm/etnaviv: initialize iommu domain page size

Since d16e0faab91 (iommu: Allow selecting page sizes per domain) the
iommu core demands the page size to be set per domain, otherwise any
mapping attempts will be dropped. Make sure to set a valid page size
for the etnaviv iommu.

Signed-off-by: Lucas Stach <l.stach@pengutronix.de>

arm64: spinlock: fix spin_unlock_wait for LSE atomics

Commit d86b8da04dfa ("arm64: spinlock: serialise spin_unlock_wait against
concurrent lockers") fixed spin_unlock_wait for LL/SC-based atomics under
the premise that the LSE atomics (in particular, the LDADDA instruction)
are indivisible.

Unfortunately, these instructions are only indivisible when used with the
-AL (full ordering) suffix and, consequently, the same issue can
theoretically be observed with LSE atomics, where a later (in program
order) load can be speculated before the write portion of the atomic
operation.

This patch fixes the issue by performing a CAS of the lock once we've
established that it's unlocked, in much the same way as the LL/SC code.

Fixes: d86b8da04dfa ("arm64: spinlock: serialise spin_unlock_wait against concurrent lockers")
Signed-off-by: Will Deacon <will.deacon@arm.com>

arm64: spinlock: order spin_{is_locked,unlock_wait} against local locks

spin_is_locked has grown two very different use-cases:

(1) [The sane case] API functions may require a certain lock to be held
    by the caller and can therefore use spin_is_locked as part of an
    assert statement in order to verify that the lock is indeed held.
    For example, usage of assert_spin_locked.

(2) [The insane case] There are two locks, where a CPU takes one of the
    locks and then checks whether or not the other one is held before
    accessing some shared state. For example, the "optimized locking" in
    ipc/sem.c.

In the latter case, the sequence looks like:

  spin_lock(&sem->lock);
  if (!spin_is_locked(&sma->sem_perm.lock))
    /* Access shared state */

and requires that the spin_is_locked check is ordered after taking the
sem->lock. Unfortunately, since our spinlocks are implemented using a
LDAXR/STXR sequence, the read of &sma->sem_perm.lock can be speculated
before the STXR and consequently return a stale value.

Whilst this hasn't been seen to cause issues in practice, PowerPC fixed
the same issue in 51d7d5205d33 ("powerpc: Add smp_mb() to
arch_spin_is_locked()") and, although we did something similar for
spin_unlock_wait in d86b8da04dfa ("arm64: spinlock: serialise
spin_unlock_wait against concurrent lockers") that doesn't actually take
care of ordering against local acquisition of a different lock.

This patch adds an smp_mb() to the start of our arch_spin_is_locked and
arch_spin_unlock_wait routines to ensure that the lock value is always
loaded after any other locks have been taken by the current CPU.

Reported-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>

arm: pmu: Fix non-devicetree probing

There is a problem in the non-devicetree PMU probing where some
probe functions may get the number of supported events through
smp_call_function_any() using the arm_pmu supported_cpus mask.
But at the time the probe function is called, the supported_cpus
mask is empty so the call fails. This patch makes sure the mask
is set before calling the init function rather than after.

Signed-off-by: Mark Salter <msalter@redhat.com>
Signed-off-by: Jeremy Linton <jeremy.linton@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

extcon: palmas: Fix boot up state of VBUS when using GPIO detection

If USB cable is connected prior to boot, we don't get any interrupts
so we must manually check the VBUS state and report it during probe.
If we don't do it then USB controller will never know that peripheral
cable was connected till the user unplugs and replugs the cable.

Fixes: b7aad8e2685b ("extcon: palmas: Add the support for VBUS detection by using GPIO")
Cc: stable@vger.kernel.org
Signed-off-by: Roger Quadros <rogerq@ti.com>
Signed-off-by: Chanwoo Choi <cw00.choi@samsung.com>

Merge branch 'linux-4.7' of git://github.com/skeggsb/linux into drm-fixes

* 'linux-4.7' of git://github.com/skeggsb/linux:
  drm/nouveau/iccsense: fix memory leak
  drm/nouveau/Revert "drm/nouveau/device/pci: set as non-CPU-coherent on ARM64"

drm/nouveau/iccsense: fix memory leak

Signed-off-by: Ben Skeggs <bskeggs@redhat.com>

drm/nouveau/Revert "drm/nouveau/device/pci: set as non-CPU-coherent on ARM64"

This reverts commit 1733a2ad36741b1812cf8b3f3037c28d0af53f50.

There is apparently something amiss with the way the TTM code handles
DMA buffers, which the above commit was attempting to work around for
arm64 systems with non-coherent PCI. Unfortunately, this completely
breaks systems *with* coherent PCI (which appear to be the majority).

Booting a plain arm64 defconfig + CONFIG_DRM + CONFIG_DRM_NOUVEAU on
a machine with a PCI GPU having coherent dma_map_ops (in this case a
7600GT card plugged into an ARM Juno board) results in a fatal crash:

[    2.803438] nouveau 0000:06:00.0: DRM: allocated 1024x768 fb: 0x9000, bo ffffffc976141c00
[    2.897662] Unable to handle kernel NULL pointer dereference at virtual address 000001ac
[    2.897666] pgd = ffffff8008e00000
[    2.897675] [000001ac] *pgd=00000009ffffe003, *pud=00000009ffffe003, *pmd=0000000000000000
[    2.897680] Internal error: Oops: 96000045 [#1] PREEMPT SMP
[    2.897685] Modules linked in:
[    2.897692] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.6.0-rc5+ #543
[    2.897694] Hardware name: ARM Juno development board (r1) (DT)
[    2.897699] task: ffffffc9768a0000 ti: ffffffc9768a8000 task.ti: ffffffc9768a8000
[    2.897711] PC is at __memcpy+0x7c/0x180
[    2.897719] LR is at OUT_RINGp+0x34/0x70
[    2.897724] pc : [<ffffff80083465fc>] lr : [<ffffff800854248c>] pstate: 80000045
[    2.897726] sp : ffffffc9768ab360
[    2.897732] x29: ffffffc9768ab360 x28: 0000000000000001
[    2.897738] x27: ffffffc97624c000 x26: 0000000000000000
[    2.897744] x25: 0000000000000080 x24: 0000000000006c00
[    2.897749] x23: 0000000000000005 x22: ffffffc97624c010
[    2.897755] x21: 0000000000000004 x20: 0000000000000004
[    2.897761] x19: ffffffc9763da000 x18: ffffffc976b2491c
[    2.897766] x17: 0000000000000007 x16: 0000000000000006
[    2.897771] x15: 0000000000000001 x14: 0000000000000001
[    2.897777] x13: 0000000000e31b70 x12: ffffffc9768a0080
[    2.897783] x11: 0000000000000000 x10: fffffffffffffb00
[    2.897788] x9 : 0000000000000000 x8 : 0000000000000000
[    2.897793] x7 : 0000000000000000 x6 : 00000000000001ac
[    2.897799] x5 : 00000000ffffffff x4 : 0000000000000000
[    2.897804] x3 : 0000000000000010 x2 : 0000000000000010
[    2.897810] x1 : ffffffc97624c010 x0 : 00000000000001ac
...
[    2.898494] Call trace:
[    2.898499] Exception stack(0xffffffc9768ab1a0 to 0xffffffc9768ab2c0)
[    2.898506] b1a0: ffffffc9763da000 0000000000000004 ffffffc9768ab360 ffffff80083465fc
[    2.898513] b1c0: ffffffc976801e00 ffffffc9762b8000 ffffffc9768ab1f0 ffffff80080ec158
[    2.898520] b1e0: ffffffc9768ab230 ffffff8008496d04 ffffffc975ce6d80 ffffffc9768ab36e
[    2.898527] b200: ffffffc9768ab36f ffffffc9768ab29d ffffffc9768ab29e ffffffc9768a0000
[    2.898533] b220: ffffffc9768ab250 ffffff80080e70c0 ffffffc9768ab270 ffffff8008496e44
[    2.898540] b240: 00000000000001ac ffffffc97624c010 0000000000000010 0000000000000010
[    2.898546] b260: 0000000000000000 00000000ffffffff 00000000000001ac 0000000000000000
[    2.898552] b280: 0000000000000000 0000000000000000 fffffffffffffb00 0000000000000000
[    2.898558] b2a0: ffffffc9768a0080 0000000000e31b70 0000000000000001 0000000000000001
[    2.898566] [<ffffff80083465fc>] __memcpy+0x7c/0x180
[    2.898574] [<ffffff800853e164>] nv04_fbcon_imageblit+0x1d4/0x2e8
[    2.898582] [<ffffff800853d6d0>] nouveau_fbcon_imageblit+0xd8/0xe0
[    2.898591] [<ffffff80083c4db4>] soft_cursor+0x154/0x1d8
[    2.898598] [<ffffff80083c47b4>] bit_cursor+0x4fc/0x538
[    2.898605] [<ffffff80083c0cfc>] fbcon_cursor+0x134/0x1a8
[    2.898613] [<ffffff800841c280>] hide_cursor+0x38/0xa0
[    2.898620] [<ffffff800841d420>] redraw_screen+0x120/0x228
[    2.898628] [<ffffff80083bf268>] fbcon_prepare_logo+0x370/0x3f8
[    2.898635] [<ffffff80083bf640>] fbcon_init+0x350/0x560
[    2.898641] [<ffffff800841c634>] visual_init+0xac/0x108
[    2.898648] [<ffffff800841df14>] do_bind_con_driver+0x1c4/0x3a8
[    2.898655] [<ffffff800841e4f4>] do_take_over_console+0x174/0x1e8
[    2.898662] [<ffffff80083bf8c4>] do_fbcon_takeover+0x74/0x100
[    2.898669] [<ffffff80083c3e44>] fbcon_event_notify+0x8cc/0x920
[    2.898680] [<ffffff80080d7e38>] notifier_call_chain+0x50/0x90
[    2.898685] [<ffffff80080d8214>] __blocking_notifier_call_chain+0x4c/0x90
[    2.898691] [<ffffff80080d826c>] blocking_notifier_call_chain+0x14/0x20
[    2.898696] [<ffffff80083c5e1c>] fb_notifier_call_chain+0x1c/0x28
[    2.898703] [<ffffff80083c81ac>] register_framebuffer+0x1cc/0x2e0
[    2.898712] [<ffffff800845da80>] drm_fb_helper_initial_config+0x288/0x3e8
[    2.898719] [<ffffff800853da20>] nouveau_fbcon_init+0xe0/0x118
[    2.898727] [<ffffff800852d2f8>] nouveau_drm_load+0x268/0x890
[    2.898734] [<ffffff8008466e24>] drm_dev_register+0xbc/0xc8
[    2.898740] [<ffffff8008468a88>] drm_get_pci_dev+0xa0/0x180
[    2.898747] [<ffffff800852cb28>] nouveau_drm_probe+0x1a0/0x1e0
[    2.898755] [<ffffff80083a32e0>] pci_device_probe+0x98/0x110
[    2.898763] [<ffffff800858e434>] driver_probe_device+0x204/0x2b0
[    2.898770] [<ffffff800858e58c>] __driver_attach+0xac/0xb0
[    2.898777] [<ffffff800858c3e0>] bus_for_each_dev+0x60/0xa0
[    2.898783] [<ffffff800858dbc0>] driver_attach+0x20/0x28
[    2.898789] [<ffffff800858d7b0>] bus_add_driver+0x1d0/0x238
[    2.898796] [<ffffff800858ed50>] driver_register+0x60/0xf8
[    2.898802] [<ffffff80083a20dc>] __pci_register_driver+0x3c/0x48
[    2.898809] [<ffffff8008468eb4>] drm_pci_init+0xf4/0x120
[    2.898818] [<ffffff8008c56fc0>] nouveau_drm_init+0x21c/0x230
[    2.898825] [<ffffff80080829d4>] do_one_initcall+0x8c/0x190
[    2.898832] [<ffffff8008c31af4>] kernel_init_freeable+0x14c/0x1f0
[    2.898839] [<ffffff80088a0c20>] kernel_init+0x10/0x100
[    2.898845] [<ffffff8008085e10>] ret_from_fork+0x10/0x40
[    2.898853] Code: a88120c7 a8c12027 a88120c7 a8c12027 (a88120c7)
[    2.898871] ---[ end trace d5713dcad023ee04 ]---
[    2.898888] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

In a toss-up between the GPU seeing stale data artefacts on some systems
vs. catastrophic kernel crashes on other systems, the latter would seem
to take precedence, so revert this change until the real underlying
problem can be fixed.

Signed-off-by: Robin Murphy <robin.murphy@arm.com>
Acked-by: Alexandre Courbot <acourbot@nvidia.com>
[acourbot@nvidia.com: port to Nouveau tree, remove bits in lib/]
Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Cc: stable@vger.kernel.org

drm/amd/powerplay: select samu dpm 0 as boot level on polaris.

Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/amd/powerplay: update powerplay table parsing

to handle pptable format change on Polaris boards

Signed-off-by: Rex Zhu <Rex.Zhu@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

drm/dp/mst: Always clear proposed vcpi table for port.

Not clearing mst manager's proposed vcpis table for destroyed connectors when the manager is stopped leaves it pointing to unrefernced memory, this causes pagefault when the manager is restarted when plugging back a branch.

Fixes: 91a25e463130 ("drm/dp/mst: deallocate payload on port destruction")
Signed-off-by: Andrey Grodzovsky <Andrey.Grodzovsky@amd.com>
Reviewed-by: Lyude <cpaul@redhat.com>
Cc: stable@vger.kernel.org
Cc: Mykola Lysenko <Mykola.Lysenko@amd.com>
Cc: Alex Deucher <alexander.deucher@amd.com>

drm/crtc: only store the necessary data for set_config rollback

drm_crtc_helper_set_config only potentially touches connector->encoder
and encoder->crtc, so we only have to store those for all connectors
and encoders, respectively.

Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

drm/crtc: fix connector reference counting mismatch in drm_crtc_helper_set_config

Since commit 0955c1250e96 ("drm/crtc: take references to connectors used
in a modeset. (v2)"), the reference counts of all connectors in the
drm_mode_set given to drm_crtc_helper_set_config are incremented, and then
the reference counts of all connectors are decremented on success, but in a
temporary copy of the connector structure. This leads to the following
error after the first modeset on imx-drm:

    Unable to handle kernel NULL pointer dereference at virtual address 00000004
    pgd = ad8c4000
    [00000004] *pgd=3d9c5831, *pte=00000000, *ppte=00000000
    Internal error: Oops: 817 [#1] PREEMPT SMP ARM
    Modules linked in:
    CPU: 1 PID: 190 Comm: kmsfb-manage Not tainted 4.7.0-rc1+ #657
    Hardware name: Freescale i.MX6 Quad/DualLit: [<80506098>]    lr : [<80252e94>]    psr: 200c0013
    sp : adca7ca8  ip : adca7b90  fp : adca7cd4
    r10: 00000000  r9 : 00000100  r8 : 00000200
    r7 : af3c9800  r6 : aded7848  r5 : aded7800  r4 : 00000000
    r3 : af3ca058  r2 : 00000200  r1 : af3ca058  r0 : 00000000
    Flags: nzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
    Control: 10c5387d  Table: 3d8c404a  DAC: 00000051
    Process kmsfb-manage (pid: 190, stack limit = 0xadca6210)
    Stack: (0xadca7ca8 to 0xadca8000)
    7ca0:                   805190e0 aded7800 aded7820 80501a88 8155a290 af3c9c6c
    7cc0: adca7ddc 0000000f adca7cec adca7cd8 80519104 80506044 805190e0 aded7800
    7ce0: adca7d04 adca7cf0 80501ac0 805190ec aded7820 aded7814 adca7d24 adca7d08
    7d00: 804fdb80 80501a94 aded7800 af3ca010 aded7afc af3c9c60 adca7d94 adca7d28
    7d20: 804e3518 804fdb20 00000000 af3c9b1c adca7d50 81506f44 00000000 8093c500
    7d40: af3c9c6c ae4f2ca8 ae4f2c18 00000000 00000000 ae637f00 00000000 aded7800
    7d60: 00000001 af3c9800 af23c300 ae77fcc0 ae4f2c18 00000001 af3c9800 8155a290
    7d80: af1af700 adca6000 adca7db4 adca7d98 804fea6c 804e2de4 adca7e50 adb3d940
    7da0: 00000001 af3c9800 adca7e24 adca7db8 8050440c 804fea0c ae77fcc0 00000003
    7dc0: adca7e24 adb3d940 af1af700 ae77fcc0 ae77fccc ae4f2c18 8083d44c ae77fcc0
    7de0: ae4002 80d03040 adca7e64 adca7e40 adca7e50 80503f08
    7e40: 7ebd5630 adca7e50 00000068 c06864a2 7ebd5be8 00000000 00000001 00000018
    7e60: 00000026 00000000 00000000 00000000 00000001 000115bc 05010500 05a0059f
    7e80: 03200000 03360321 00000337 0000003c 00000000 00000040 30383231 30303878
    7ea0: 00000000 00000000 00000000 00000000 00000000 00000000 80173058 80172e30
    7ec0: 80d77d32 00004000 adf7d900 00000003 00000000 7ebd5630 af342bb0 adfe3b80
    7ee0: 80272f50 00000003 adca6000 00000000 adca7f7c adca7f00 802725ec 804f52cc
    7f00: 802809cc 80178450 00000000 00000000 80280880 80145904 adb3d8c0 adf7d990
    7f20: ffffffff 00000003 00004000 01614c10 c06864a2 00000003 adca6000 00000000
    7f40: adca7f6c adca7f50 80280b04 8028088c 000115bc adfe3b81 7ebd5630 adfe3b80
    7f60: c06864a2 00000003 adca6000 00000000 adca7fa4 adca7f80 80272f50 80272548
    7f80: 000115bc 00017050 00000001 01614c10 00000036 801089e4 00000000 adca7fa8
    7fa0: 80108840 80272f18 00017050 00000001 00000003 c06864a2 7ebd5630 000115bc
    7fc0: 00017050 00000001 01614c10 00000036 00000003 00000000 00000026 00000018
    7fe0: 00016f38 7ebd562c 0000b5e9 76ef31e6 400c0030 00000003 ff5f37db bfe7dd4d
    Backtrace:
    [<80506038>] (drm_connector_cleanup) from [<80519104>] (dw_hdmi_connector_destroy+0x24/0x28)
     r10:0000000f r9:adca7ddc r8:af3c9c6c r7:8155a290 r6:80501a88 r5:aded7820
     r4:aded7800 r3:805190e0
    [<805190e0>] (dw_hdmi_connector_destroy) from [<80501ac0>] (drm_connector_free+0x38/0x3c)
     r4:aded7800 nreference) from [<804e3518>] (drm_crtc_helper_set_config+0x740/0xbf4)
     r6:af3c9c60 r5:aded7afc r4:af3ca010 r3:aded7800
    [<804e2dd8>] (drm_crtc_helper_set_config) from [<804fea6c>] (drm_mode_set_config_internal+0x6c/0xf4)
     r10:adca6000 r9:af1af700 r8:8155a290 r7:af3c9800 r6:00000001 r5:ae4f2c18
     r4:ae77fcc0
    [<804fea00>] (drm_mode_set_config_internal) from [<8050440c>] (drm_mode_setcrtc+0x504/0x57c)
     r7:af3c9800 r6:00000001 r5:adb3d940 r4:adca7e50
    [<80503f08>] (drm_mode_setcrtc) from [<804f5404>] (drm_ioctl+0x144/0x4dc)
     r10:ada2e000 r9:000000a2 r8:af3c9800 r7:8155a290 r6:809320b4 r5:00000051
     r4:adca7e50
    [<804f52c0>] (drm_ioctl) from [<802725ec>] (do_vfs_ioctl+0xb0/0x9d0)
     r10:00000000 r9:adca6000 r8:00000003 r7:80272f50 r6:adfe3b80 r5:af342bb0
     r4:7ebd5630
    [<8027253c>] (do_vfs_ioctl) from [<80272f50>] (SyS_ioctl+0x44/0x6c)
     r10:00000000 r9:adca6000 r8:00000003 r7:c06864a2 r6:adfe3b80 r5:7ebd5630
     r4:adfe3b81
    [<80272f0c>] (SyS_ioctl) from [<80108840>] (ret_fast_syscall+0x0/0x1c)
     r8:801089e4 r7:00000036 r6:01614c10 r5:00000001 r4:00017050 r3:000115bc
    Code: 0a00000c e5932004 e1a01003 e1a0a004 (e5842004)
    ---[ end trace 9a7257572ccacb16 ]---

Only the reference count of connectors that weren't previously bound to
an encoder should be incremented after a call to drm_crtc_helper_set_config.
And only the reference count of connectors that were previously bound to
an encoder and are unbound afterwards should ever be decremented.
The reference counts of the temporary copies in the save_connectors
should not be touched at all.

This patch fixes the above error by only incrementing the reference count
of those connectors in the set that are initially not bound to any encoder,
and also by restoring the reference count of only those connectors in the
set in the failure case.

"Note that this can only be hit when fbdev emulation is disabled, since
then the refcount drops from 1 to 0 and we call the connector destroy
functions on the backup copy, which eventually results in tears. With
fbdev emulation the refcount only goes down from 2 to 1 ever. And since we
unconditionally increment the refcount on the real object, the refcount of
that will slowly increase. The backup connector's refcount doesn't matter,
since we kfree() that either way in the end of
drm_crtc_helper_set_config()."

Fixes: 0955c1250e96 ("drm/crtc: take references to connectors used in a modeset. (v2)")
Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>

Merge tag 'drm-intel-fixes-2016-06-14' of git://anongit.freedesktop.org/drm-intel into drm-fixes

"Pretty much all regression fixes, or black screens."

* tag 'drm-intel-fixes-2016-06-14' of git://anongit.freedesktop.org/drm-intel:
  drm/i915/ilk: Don't disable SSC source if it's in use
  drm/i915: Extract physical display dimensions from VBT
  drm/i915: Check VBT for port presence in addition to the strap on VLV/CHV
  drm/i915: Only ignore eDP ports that are connected
  drm/i915: Silence "unexpected child device config size" for VBT on 845g
  drm/i915: Fix NULL pointer deference when out of PLLs in IVB

Revert "ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_hw_write()"

Revert commit 66b1ed5aa8dd "ACPICA: ACPI 2.0, Hardware: Add
access_width/bit_offset support for acpi_hw_write()" that is reported
to break suspend-to-RAM (ACPI S3) on one system.

The root cause of the failure is a wrong access width value for one of
the involved registers provided by the ACPI tables, but before commit
66b1ed5aa8dd that value was not taken into account at all and things
worked.

Fixes: 66b1ed5aa8dd "ACPICA: ACPI 2.0, Hardware: Add access_width/bit_offset support for acpi_hw_write()"
Reported-by: Andrey Skvortsov <andrej.skvortzov@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

cpufreq: intel_pstate: Adjust _PSS[0] freqeuency if needed

The maximum turbo P-State used by the intel_pstate driver may be
limited by ACPI _PSS table entry 0.  After commit 9522a2ff9cde
(cpufreq: intel_pstate: Enforce _PPC limits), the maximum performance
on servers will be capped by the _PSS table entry 0 by default.

Even though that is formally correct, it may lead to preformance
regressions in some cases.  Namely, if the _PSS table entry 0 is
not the maximum turbo P-State, performance measured after commit
9522a2ff9cde will not match the performance measured before that
commit on the same system.

For this reason, modify the code to always use the maximum turbo
frequency as the one that corresponds to _PSS table entry 0 if turbo
is enabled in the BIOS.  This way, the performance levels from
before commit 9522a2ff9cde will be restored on the affected systems.

Fixes: 9522a2ff9cde (cpufreq: intel_pstate: Enforce _PPC limits)
Suggested-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
[ rjw : Changelog ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

arm: Use _rcuidle for smp_cross_call() tracepoints

Further testing with false negatives suppressed by commit 293e2421fe25
("rcu: Remove superfluous versions of rcu_read_lock_sched_held()")
identified another unprotected use of RCU from the idle loop.  Because RCU
actively ignores idle-loop code (for energy-efficiency reasons, among
other things), using RCU from the idle loop can result in too-short
grace periods, in turn resulting in arbitrary misbehavior.

The resulting lockdep-RCU splat is as follows:

------------------------------------------------------------------------

===============================
[ INFO: suspicious RCU usage. ]
4.6.0-rc5-next-20160426+ #1112 Not tainted
-------------------------------
include/trace/events/ipi.h:35 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 0
RCU used illegally from extended quiescent state!
no locks held by swapper/0/0.

stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc5-next-20160426+ #1112
Hardware name: Generic OMAP4 (Flattened Device Tree)
[<c0110308>] (unwind_backtrace) from [<c010c3a8>] (show_stack+0x10/0x14)
[<c010c3a8>] (show_stack) from [<c047fec8>] (dump_stack+0xb0/0xe4)
[<c047fec8>] (dump_stack) from [<c010dcfc>] (smp_cross_call+0xbc/0x188)
[<c010dcfc>] (smp_cross_call) from [<c01c9e28>] (generic_exec_single+0x9c/0x15c)
[<c01c9e28>] (generic_exec_single) from [<c01ca0a0>] (smp_call_function_single_async+0 x38/0x9c)
[<c01ca0a0>] (smp_call_function_single_async) from [<c0603728>] (cpuidle_coupled_poke_others+0x8c/0xa8)
[<c0603728>] (cpuidle_coupled_poke_others) from [<c0603c10>] (cpuidle_enter_state_coupled+0x26c/0x390)
[<c0603c10>] (cpuidle_enter_state_coupled) from [<c0183c74>] (cpu_startup_entry+0x198/0x3a0)
[<c0183c74>] (cpu_startup_entry) from [<c0b00c0c>] (start_kernel+0x354/0x3c8)
[<c0b00c0c>] (start_kernel) from [<8000807c>] (0x8000807c)

------------------------------------------------------------------------

Reported-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Tested-by: Tony Lindgren <tony@atomide.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Cc: Russell King <linux@arm.linux.org.uk>
Cc: Steven Rostedt <rostedt@goodmis.org>
Cc: <linux-omap@vger.kernel.org>
Cc: <linux-arm-kernel@lists.infradead.org>

drm/i915/ilk: Don't disable SSC source if it's in use

Thanks to Ville Syrjälä for pointing me towards the cause of this issue.

Unfortunately one of the sideaffects of having the refclk for a DPLL set
to SSC is that as long as it's set to SSC, the GPU will prevent us from
powering down any of the pipes or transcoders using it. A couple of
BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL
configurations. This causes issues on the first modeset, since we don't
expect SSC to be left on and as a result, can't successfully power down
the pipes or the transcoders using it. Here's an example from this Dell
OptiPlex 990:

[drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says disabled
[drm:intel_modeset_init] 2 display pipes available.
[drm:intel_update_cdclk] Current CD clock rate: 400000 kHz
[drm:intel_update_max_cdclk] Max CD clock rate: 400000 kHz
[drm:intel_update_max_cdclk] Max dotclock rate: 360000 kHz
vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
[drm:intel_crt_reset] crt adpa set to 0xf40000
[drm:intel_dp_init_connector] Adding DP connector on port C
[drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1
[drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0
[drm:ironlake_init_pch_refclk] Disabling SSC entirely
… later we try committing the first modeset …
[drm:intel_dump_pipe_config] [CRTC:26][modeset] config ffff88041b02e800 for pipe A
[drm:intel_dump_pipe_config] cpu_transcoder: A
…
[drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, fp0: 0x20e08, fp1: 0x30d07
[drm:intel_dump_pipe_config] planes on this crtc
[drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled
[drm:intel_dump_pipe_config]     FB:42, fb = 800x600 format = 0x34325258
[drm:intel_dump_pipe_config]     scaler:0 src (0, 0) 800x600 dst (0, 0) 800x600
[drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, scaler_id = 0
[drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, scaler_id = 0
[drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A
[drm:intel_get_shared_dpll] using PCH DPLL A for pipe A
[drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A
[drm:intel_disable_pipe] disabling pipe A
------------[ cut here ]------------
WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 intel_disable_pipe+0x297/0x2d0 [i915]
pipe_off wait timed out
…
---[ end trace 94fc8aa03ae139e8 ]---
[drm:intel_dp_link_down]
[drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A

Later modesets succeed since they reset the DPLL's configuration anyway,
but this is enough to get stuck with a big fat warning in dmesg.

A better solution would be to add refcounts for the SSC source, but for
now leaving the source clock on should suffice.

Changes since v4:
 - Fix calculation of final for systems with LVDS panels (fixes BUG() on
   CI test suite)
Changes since v3:
 - Move temp variable into loop
 - Move checks for using_ssc_source to after we've figured out has_ck505
 - Add using_ssc_source to debug output
Changes since v2:
 - Fix debug output for when we disable the CPU source
Changes since v1:
 - Leave the SSC source clock on instead of just shutting it off on all
   of the DPLL configurations.

Cc: stable@vger.kernel.org
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Lyude <cpaul@redhat.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1465916649-10228-1-git-send-email-cpaul@redhat.com
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>

usb: musb: sunxi: Remove bogus "Frees glue" comment

The comment is wrong, glue is devm_kzalloc-ed mem attached to the
"allwinner,sun4i-a10-musb" compatible platform-dev. Where as
glue->musb_pdev is a newly created "musb-hdrc" platform-dev.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[b-liu@ti.com: revise subject prefix]
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: musb: sunxi: Fix NULL ptr deref when gadget is registered before musb

Stop using the return value of platform_device_register_full() to get to
the struct musb in sunxi_musb_work(). If a gadget has been registered
(insmod-ed) before the musb driver, then musb_start will get called
from the musb_core probe function and sunxi_musb_work() may run before
platform_device_register_full() has returned.

Instead store a pointer to struct musb in struct sunxi_glue when
sunxi_musb_enable gets called. Note that sunxi_musb_enable always gets
called before sunxi_musb_work() can run.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
[b-liu@ti.com: revise subject prefix]
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

nfsd: Fix NFSD_MDS_PR_KEY on 32-bit by adding ULL postfix

On 32-bit:

    fs/nfsd/blocklayout.c: In function ‘nfsd4_block_get_device_info_scsi’:
    fs/nfsd/blocklayout.c:337: warning: integer constant is too large for ‘long’ type
    fs/nfsd/blocklayout.c:344: warning: integer constant is too large for ‘long’ type
    fs/nfsd/blocklayout.c: In function ‘nfsd4_scsi_fence_client’:
    fs/nfsd/blocklayout.c:385: warning: integer constant is too large for ‘long’ type

Add the missing "ULL" postfix to 64-bit constant NFSD_MDS_PR_KEY to fix
this.

Fixes: f99d4fbdae6765d0 ("nfsd: add SCSI layout support")
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: J. Bruce Fields <bfields@redhat.com>

arm64: mm: mark fault_info table const

Unlike the debug_fault_info table, we never intentionally alter the
fault_info table at runtime, and all derived pointers are treated as
const currently.

Make the table const so that it can be placed in .rodata and protected
from unintentional writes, as we do for the syscall tables.

Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

arm64: fix dump_instr when PAN and UAO are in use

If the kernel is set to show unhandled signals, and a user task does not
handle a SIGILL as a result of an instruction abort, we will attempt to
log the offending instruction with dump_instr before killing the task.

We use dump_instr to log the encoding of the offending userspace
instruction. However, dump_instr is also used to dump instructions from
kernel space, and internally always switches to KERNEL_DS before dumping
the instruction with get_user. When both PAN and UAO are in use, reading
a user instruction via get_user while in KERNEL_DS will result in a
permission fault, which leads to an Oops.

As we have regs corresponding to the context of the original instruction
abort, we can inspect this and only flip to KERNEL_DS if the original
abort was taken from the kernel, avoiding this issue. At the same time,
remove the redundant (and incorrect) comments regarding the order
dump_mem and dump_instr are called in.

Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: James Morse <james.morse@arm.com>
Cc: Robin Murphy <robin.murphy@arm.com>
Cc: <stable@vger.kernel.org> #4.6+
Signed-off-by: Mark Rutland <mark.rutland@arm.com>
Reported-by: Vladimir Murzin <vladimir.murzin@arm.com>
Tested-by: Vladimir Murzin <vladimir.murzin@arm.com>
Fixes: 57f4959bad0a154a ("arm64: kernel: Add support for User Access Override")
Signed-off-by: Will Deacon <will.deacon@arm.com>

Merge branch 'kvm-mips-fixes' into HEAD

Merge MIPS patches destined to both 4.7 and kvm/next, to avoid
unnecessary conflicts.

Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

MIPS: KVM: Fix CACHE triggered exception emulation

When emulating TLB miss / invalid exceptions during CACHE instruction
emulation, be sure to set up the correct PC and host_cp0_badvaddr state
for the kvm_mips_emlulate_tlb*_ld() function to pick up for guest EPC
and BadVAddr.

PC needs to be rewound otherwise the guest EPC will end up pointing at
the next instruction after the faulting CACHE instruction.

host_cp0_badvaddr must be set because guest CACHE instructions trap with
a Coprocessor Unusable exception, which doesn't update the host BadVAddr
as a TLB exception would.

This doesn't tend to get hit when dynamic translation of emulated
instructions is enabled, since only the first execution of each CACHE
instruction actually goes through this code path, with subsequent
executions hitting the SYNCI instruction that it gets replaced with.

Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: kvm@vger.kernel.org
Cc: linux-mips@linux-mips.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

MIPS: KVM: Don't unwind PC when emulating CACHE

When a CACHE instruction is emulated by kvm_mips_emulate_cache(), the PC
is first updated to point to the next instruction, and afterwards it
falls through the "dont_update_pc" label, which rewinds the PC back to
its original address.

This works when dynamic translation of emulated instructions is enabled,
since the CACHE instruction is replaced with a SYNCI which works without
trapping, however when dynamic translation is disabled the guest hangs
on CACHE instructions as they always trap and are never stepped over.

Roughly swap the meanings of the "done" and "dont_update_pc" to match
kvm_mips_emulate_CP0(), so that "done" will roll back the PC on failure,
and "dont_update_pc" won't change PC at all (for the sake of exceptions
that have already modified the PC).

Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: kvm@vger.kernel.org
Cc: linux-mips@linux-mips.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

MIPS: KVM: Include bit 31 in segment matches

When faulting guest addresses are matched against guest segments with
the KVM_GUEST_KSEGX() macro, change the mask to 0xe0000000 so as to
include bit 31.

This is mainly for safety's sake, as it prevents a rogue BadVAddr in the
host kseg2/kseg3 segments (e.g. 0xC*******) after a TLB exception from
matching the guest kseg0 segment (e.g. 0x4*******), triggering an
internal KVM error instead of allowing the corresponding guest kseg0
page to be mapped into the host vmalloc space.

Such a rogue BadVAddr was observed to happen with the host MIPS kernel
running under QEMU with KVM built as a module, due to a not entirely
transparent optimisation in the QEMU TLB handling. This has already been
worked around properly in a previous commit.

Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: kvm@vger.kernel.org
Cc: linux-mips@linux-mips.org
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

MIPS: KVM: Fix modular KVM under QEMU

Copy __kvm_mips_vcpu_run() into unmapped memory, so that we can never
get a TLB refill exception in it when KVM is built as a module.

This was observed to happen with the host MIPS kernel running under
QEMU, due to a not entirely transparent optimisation in the QEMU TLB
handling where TLB entries replaced with TLBWR are copied to a separate
part of the TLB array. Code in those pages continue to be executable,
but those mappings persist only until the next ASID switch, even if they
are marked global.

An ASID switch happens in __kvm_mips_vcpu_run() at exception level after
switching to the guest exception base. Subsequent TLB mapped kernel
instructions just prior to switching to the guest trigger a TLB refill
exception, which enters the guest exception handlers without updating
EPC. This appears as a guest triggered TLB refill on a host kernel
mapped (host KSeg2) address, which is not handled correctly as user
(guest) mode accesses to kernel (host) segments always generate address
error exceptions.

Signed-off-by: James Hogan <james.hogan@imgtec.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Radim Krčmář <rkrcmar@redhat.com>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: kvm@vger.kernel.org
Cc: linux-mips@linux-mips.org
Cc: <stable@vger.kernel.org> # 3.10.x-
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>

pwm: atmel-hlcdc: Fix default PWM polarity

The PWM device exposed by the HLCDC IP is configured with an inverted
polarity by default. Registering the PWM chip with the normal polarity
was not a problem before commit 42e8992c58d4 ("pwm: Add core
infrastructure to allow atomic updates") because the ->set_polarity()
hook was called no matter the current polarity state, but this is no longer
the case.

Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
Signed-off-by: Thierry Reding <thierry.reding@gmail.com>

ubi: Don't bypass ->getattr()

Directly accessing inode fields bypasses ->getattr()
and can cause problems when the underlying filesystem
does not have the default ->getattr() implementation.

So instead of obtaining the backing inode via d_backing_inode()
use vfs_getattr() and obtain what we need from the kstat struct.

Cc: Al Viro <viro@zeniv.linux.org.uk>
Reported-by: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Richard Weinberger <richard@nod.at>

Revert "mtd: switch open_mtd_by_chdev() to use of vfs_stat()"

This reverts commit 87f15d4add758fb7fc76655721af94be57a4c17d.

vfs_stat() can only be used on user supplied buffers.

Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Richard Weinberger <richard@nod.at>

Revert "mtd: switch ubi_open_volume_path() to vfs_stat()"

This reverts commit 322ea0bbf3003df17b6253f76e572c37d79a6810.

vfs_stat() can only be used on user supplied buffers.
UBI's kapi.c is the API to the kernel and therefore vfs_stat()
is inappropriate.

This solves the problem that mounting any UBIFS will immediately
fail with -EINVAL.

Cc: Al Viro <viro@zeniv.linux.org.uk>
Signed-off-by: Richard Weinberger <richard@nod.at>

Merge branch 'for-4.7-fixes' of git://git./linux/kernel/git/tj/percpu

Pull percpu fixes from Tejun Heo:
 "While adding GFP_ATOMIC support to the percpu allocator, the
  synchronization for the fast-path which doesn't require external
  allocations was separated into pcpu_lock.

  Unfortunately, it incorrectly decoupled async paths and percpu
  chunks could get destroyed while still being operated on.  This
  contains two patches to fix the bug"

* 'for-4.7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/percpu:
  percpu: fix synchronization between synchronous map extension and chunk destruction
  percpu: fix synchronization between chunk->map_extend_work and chunk destruction

Merge tag 'regulator-fix-v4.7-rc2' of git://git./linux/kernel/git/broonie/regulator

Pull regulator fixes from Mark Brown:
 "Some driver specific fixes for the regulator subsystem:

   - Some of the changes to the core that were merged in the last merge
     window exposed the fact that the qcom-smd driver hadn't implemented
     the voltage enumeration interfaces like it should.  Since it's a
     simple driver specific fix to implement them do that.

   - Fix the ramp delay configuration for tps51632"

* tag 'regulator-fix-v4.7-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator:
  regulator: qcom_smd: add list_voltage callback
  regulator: qcom_smd: add regulator ops for pm8941 lnldo
  regulator: qcom_smd: add list_voltage callback
  regulator: tps51632: Fix setting ramp delay

mcb: Acquire reference to carrier module in core

Acquire a reference to the carrier's kernel module in bus code, so
it can't be removed from the kernel while it still has a bus and thus
possibly devices attached to it.

Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reported-by: Andreas Werner <andreas.werner@men.de>
Tested-by: Andreas Werner <andreas.werner@men.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

mcb: Acquire reference to device in probe

mcb_probe() does not aqcuire a reference to the probed device but drops one
when removing the device. As it is actually using the device, it should grab
a reference via get_device().

This could lead to a panic found with a rmmod/modprobe stress test

Signed-off-by: Johannes Thumshirn <jthumshirn@suse.de>
Reported-by: Andreas Werner <andreas.werner@men.de>
Tested-by: Andreas Werner <andreas.werner@men.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Revert "drm/amdgpu: add pipeline sync while vmid switch in same ctx"

This reverts commit 2ba272d7bde27e1db2cf1c6cee49b01b7ea08989.

The issue fixed by this patch is specific to compute rings and the
previous patch was enough.  Additionally, this patch as been traced
to strange behavior on some CZ systems so we might as well drop it.

Merge tag 'samsung-fixes-4.7-2' of git://git./linux/kernel/git/krzk/linux into fixes

Fixes for Exynos-based Snow and Peach Pit boards for regressions introduced in
4.7-rc1 because OF graph logic expects specific names of child nodes.

* tag 'samsung-fixes-4.7-2' of git://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux:
  ARM: dts: exynos: Fix port nodes names for Exynos5420 Peach Pit board
  ARM: dts: exynos: Fix port nodes names for Exynos5250 Snow board

Signed-off-by: Olof Johansson <olof@lixom.net>

MAINTAINERS: Add myself as reviewer of ARM FSL/NXP

I would like to help reviewing FSL/NXP ARM architecture patches.

Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Acked-by: Shawn Guo <shawnguo@kernel.org>
Signed-off-by: Olof Johansson <olof@lixom.net>

Merge tag 'socfpga_fix_for_v4.7' of git://git./linux/kernel/git/dinguyen/linux into fixes

SoCFPGA fix for v4.7
- Add missing PHY phandle for SoCFPGA VINING board

* tag 'socfpga_fix_for_v4.7' of git://git.kernel.org/pub/scm/linux/kernel/git/dinguyen/linux:
  ARM: dts: socfpga: Add missing PHY phandle

Signed-off-by: Olof Johansson <olof@lixom.net>

drm/amdgpu/gfx7: fix broken condition check

Wrong operator.

Reported-by: David Binderman <linuxdev.baldrick@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

drm/radeon: fix asic initialization for virtualized environments

When executing in a PCI passthrough based virtuzliation environment, the
hypervisor will usually attempt to send a PCIe bus reset signal to the
ASIC when the VM reboots. In this scenario, the card is not correctly
initialized, but we still consider it to be posted. Therefore, in a
passthrough based environemnt we should always post the card to guarantee
it is in a good state for driver initialization.

Ported from amdgpu commit:
amdgpu: fix asic initialization for virtualized environments

Cc: Andres Rodriguez <andres.rodriguez@amd.com>
Cc: Alex Williamson <alex.williamson@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org

amdgpu: fix asic initialization for virtualized environments (v2)

When executing in a PCI passthrough based virtuzliation environemnt, the
hypervisor will usually attempt to send a PCIe bus reset signal to the
ASIC when the VM reboots. In this scenario, the card is not correctly
initialized, but we still consider it to be posted. Therefore, in a
passthrough based environemnt we should always post the card to guarantee
it is in a good state for driver initialization.

However, if we are operating in SR-IOV mode it is up to the GIM driver
to manage the asic state, therefore we should not post the card (and
shouldn't be able to do it either).

v2: add missing semi-colon

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

drm/radeon: don't use fractional dividers on RS[78]80 if SS is enabled

Seems to cause problems for some older hardware. Kudos to Thom Kouwenhoven
for working a lot with the PLLs and figuring this out.

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

drm/radeon: do not hard reset GPU while freezing on r600/r700 family

Seems r600/r700 does not like hard reset while freezing for hibernation
(regression due to 274ad65c9d02bdcbee9bae045517864c3521d530 which itself
is a fix for hibernation on some GPU families). Until i can debug further
issue with r600, let just disable this for r600/r700 as they are very
similar family and bug affecting one likely affect the other.

Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Jérôme Glisse <jglisse@redhat.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>

Merge remote-tracking branches 'regulator/fix/qcom-smd' and 'regulator/fix/tps51632' into regulator-linus

KVM: s390/mm: Fix CMMA reset during reboot

commit 1e133ab296f ("s390/mm: split arch/s390/mm/pgtable.c") factored
out the page table handling code from __gmap_zap and  __s390_reset_cmma
into ptep_zap_unused and added a simple flag that tells which one of the
function (reset or not) is to be made. This also changed the behaviour,
as it also zaps unused page table entries on reset.
Turns out that this is wrong as s390_reset_cmma uses the page walker,
which DOES NOT take the ptl lock.

The most simple fix is to not do the zapping part on reset (which uses
the walker)

Signed-off-by: Christian Borntraeger <borntraeger@de.ibm.com>
Fixes: 1e133ab296f ("s390/mm: split arch/s390/mm/pgtable.c")
Cc: stable@vger.kernel.org # 4.6+
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

ipmi: Remove smi_msg from waiting_rcv_msgs list before handle_one_recv_msg()

Commit 7ea0ed2b5be8 ("ipmi: Make the message handler easier to use for
SMI interfaces") changed handle_new_recv_msgs() to call handle_one_recv_msg()
for a smi_msg while the smi_msg is still connected to waiting_rcv_msgs list.
That could lead to following list corruption problems:

1) low-level function treats smi_msg as not connected to list

  handle_one_recv_msg() could end up calling smi_send(), which
  assumes the msg is not connected to list.

  For example, the following sequence could corrupt list by
  doing list_add_tail() for the entry still connected to other list.

    handle_new_recv_msgs()
      msg = list_entry(waiting_rcv_msgs)
      handle_one_recv_msg(msg)
        handle_ipmb_get_msg_cmd(msg)
          smi_send(msg)
            spin_lock(xmit_msgs_lock)
            list_add_tail(msg)
            spin_unlock(xmit_msgs_lock)

2) race between multiple handle_new_recv_msgs() instances

  handle_new_recv_msgs() once releases waiting_rcv_msgs_lock before calling
  handle_one_recv_msg() then retakes the lock and list_del() it.

  If others call handle_new_recv_msgs() during the window shown below
  list_del() will be done twice for the same smi_msg.

  handle_new_recv_msgs()
    spin_lock(waiting_rcv_msgs_lock)
    msg = list_entry(waiting_rcv_msgs)
    spin_unlock(waiting_rcv_msgs_lock)
  |
  | handle_one_recv_msg(msg)
  |
    spin_lock(waiting_rcv_msgs_lock)
    list_del(msg)
    spin_unlock(waiting_rcv_msgs_lock)

Fixes: 7ea0ed2b5be8 ("ipmi: Make the message handler easier to use for SMI interfaces")
Signed-off-by: Jun'ichi Nomura <j-nomura@ce.jp.nec.com>
[Added a comment to describe why this works.]
Signed-off-by: Corey Minyard <cminyard@mvista.com>
Cc: stable@vger.kernel.org # 3.19
Tested-by: Ye Feng <yefeng.yl@alibaba-inc.com>

gpio: 104-idi-48: Fix missing spin_lock_init for ack_lock

Fixes: 9ae482104cb9 ("gpio: 104-idi-48: Clear pending interrupt once in IRQ handler")
Signed-off-by: Axel Lin <axel.lin@ingics.com>
Acked-by: William Breathitt Gray <vilhelm.gray@gmail.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Merge tag 'kvm-s390-master-4.7-1' of git://git./linux/kernel/git/kvms390/linux into HEAD

KVM: s390: fixup and missing stat

1. A fixup for a bug that was introduced in 4.7-rc1 if userspace uses
   the cpu model ioctls
2. Add the missing kvm stat for pei events

iommu/arm-smmu: Wire up map_sg for arm-smmu-v3

The map_sg callback is missing from arm_smmu_ops, but is required by
iommu.h. Similarly to most other IOMMU drivers, connect it to
default_iommu_map_sg.

Cc: <stable@vger.kernel.org>
Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker@arm.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>
Signed-off-by: Joerg Roedel <jroedel@suse.de>

regulator: qcom_smd: add list_voltage callback

This patch adds support to list_voltage callback, so that consumers
like mmc core, can get information of supported voltage range.

Without this patch there is no way for mmc core to know this voltage range.

Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Mark Brown <broonie@kernel.org>

ARM: OMAP: DRA7: powerdomain data: Remove unused pwrsts_mem_ret

As per the latest revision F of public TRM for DRA7/AM57xx SoCs
SPRUHZ6F[1] (April 2016), with the exception of MPU power domain, all
other power domains do not have memories capable of retention since
they all operate in either "ON" or "OFF" mode. For these power states,
the retention state for memories are basically ignored by PRCM and does
not require to be programmed.

[1] http://www.ti.com/lit/pdf/spruhz6

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP: DRA7: powerdomain data: Remove unused pwrsts_logic_ret

As per the latest revision F of public TRM for DRA7/AM57xx SoCs
SPRUHZ6F[1] (April 2016), with the exception of MPU power domain (and
CPUx sub power domains), all other power domains can either operate
in "ON" mode OR in some cases, "OFF" mode. For these power states,
the logic retention state is basically ignored by PRCM and does not
require to be programmed.

[1] http://www.ti.com/lit/pdf/spruhz6

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

ARM: OMAP: DRA7: powerdomain data: Set L3init and L4per to ON

As per the latest revision F of public TRM for DRA7/AM57xx SoCs
SPRUHZ6F[1] (April 2016), L4Per and L3init power domains now operate in
always "ON" mode due to asymmetric aging limitations. Update the same

[1] http://www.ti.com/lit/pdf/spruhz6

Signed-off-by: Nishanth Menon <nm@ti.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>

autofs races

* make autofs4_expire_indirect() skip the dentries being in process of
expiry
* do *not* mess with list_move(); making sure that dentry with
AUTOFS_INF_EXPIRING are not picked for expiry is enough.
* do not remove NO_RCU when we set EXPIRING, don't bother with smp_mb()
there.  Clear it at the same time we clear EXPIRING.  Makes a bunch of
tests simpler.
* rename NO_RCU to WANT_EXPIRE, which is what it really is.

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

Linux 4.7-rc3

Merge branch 'for-rc' of git://git./linux/kernel/git/rzhang/linux

Pull thermal management fixes from Zhang Rui:

 - fix an ordering issue in cpu cooling that cooling device is
   registered before it's ready (freq_table being populated).
   (Lukasz Luba)

 - fix a missing comment update (Caesar Wang)

* 'for-rc' of git://git.kernel.org/pub/scm/linux/kernel/git/rzhang/linux:
  thermal: add the note for set_trip_temp
  thermal: cpu_cooling: fix improper order during initialization

Merge branch 'overlayfs-af_unix-fix' into overlayfs-linus

Merge branch 'for-linus' of git://git.kernel.dk/linux-block

Pull block layer fixes from Jens Axboe:
 "A small collection of fixes for the current series.  This contains:

   - Two fixes for xen-blkfront, from Bob Liu.

   - A bug fix for NVMe, releasing only the specific resources we
     requested.

   - Fix for a debugfs flags entry for nbd, from Josef.

   - Plug fix from Omar, fixing up a case of code being switched between
     two functions.

   - A missing bio_put() for the new discard callers of
     submit_bio_wait(), fixing a regression causing a leak of the bio.
     From Shaun.

   - Improve dirty limit calculation precision in the writeback code,
     fixing a case where setting a limit lower than 1% of memory would
     end up being zero.  From Tejun"

* 'for-linus' of git://git.kernel.dk/linux-block:
  NVMe: Only release requested regions
  xen-blkfront: fix resume issues after a migration
  xen-blkfront: don't call talk_to_blkback when already connected to blkback
  nbd: pass the nbd pointer for flags debugfs
  block: missing bio_put following submit_bio_wait
  blk-mq: really fix plug list flushing for nomerge queues
  writeback: use higher precision calculation in domain_dirty_limits()

Merge tag 'gpio-v4.7-3' of git://git./linux/kernel/git/linusw/linux-gpio

Pull GPIO fixes from Linus Walleij:
 "A new bunch of GPIO fixes for v4.7.

  This time I am very grateful that Ricardo Ribalda Delgado went in and
  fixed my stupid refcounting mistakes in the removal path for GPIO
  chips.  I had a feeling something was wrong here and so it was.  It
  exploded on OMAP and it fixes their problem.  Now it should be (more)
  solid.

  The rest i compilation, Kconfig and driver fixes.  Some tagged for
  stable.

  Summary:

   - Fix a NULL pointer dereference when we are searching the GPIO
     device list but one of the devices have been removed (struct
     gpio_chip pointer is NULL).

   - Fix unaligned reference counters: we were ending on +3 after all
     said and done.  It should be 0.  Remove an extraneous get_device(),
     and call cdev_del() followed by device_del() in gpiochip_remove()
     instead and the count goes to zero and calls the release() function
     properly.

   - Fix a compile warning due to a missing #include in the OF/device
     tree portions.

   - Select ANON_INODES for GPIOLIB, we're using that for our character
     device.  Some randconfig tests disclosed the problem.

   - Make sure the Zynq driver clock runs also without CONFIG_PM enabled

   - Fix an off-by-one error in the 104-DIO-48E driver

   - Fix warnings in bcm_kona_gpio_reset()"

* tag 'gpio-v4.7-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
  gpio: bcm-kona: fix bcm_kona_gpio_reset() warnings
  gpio: select ANON_INODES
  gpio: include <linux/io-mapping.h> in gpiolib-of
  gpiolib: Fix unaligned used of reference counters
  gpiolib: Fix NULL pointer deference
  gpio: zynq: initialize clock even without CONFIG_PM
  gpio: 104-dio-48e: Fix control port offset computation off-by-one error