Commit Graph

574611 Commits

Author SHA1 Message Date
Adrian Hunter 8d28b7a72f mmc: sdhci: Allow override of get_cd() called from sdhci_request()
Drivers may need to provide their own get_cd() mmc host op, but
currently the internals of the current op (sdhci_get_cd()) are
provided by sdhci_do_get_cd() which is also called from
sdhci_request().

To allow override of the get_cd functionality, change sdhci_request()
to call ->get_cd() instead of sdhci_do_get_cd().

Note, in the future the call to ->get_cd() will likely be removed
from sdhci_request() since most drivers don't need actually it.
However this change is being done now to facilitate a subsequent
bug fix.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-02-11 11:39:56 +01:00
Adrian Hunter bf60e592a1 mmc: sdhci: Allow override of mmc host operations
In the past, fixes for specific hardware devices were implemented
in sdhci using quirks.  That approach is no longer accepted because
the growing number of quirks was starting to make the code difficult
to understand and maintain.

One alternative to quirks, is to allow drivers to override the default
mmc host operations.  This patch makes it easy to do that, and it is
needed for a subsequent bug fix, for which separate patches are
provided.

Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Cc: stable@vger.kernel.org # v4.4+
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-02-11 11:39:56 +01:00
Daniel Wagner f4d3d50419 mips: Differentiate between 32 and 64 bit ELF header
Depending on the configuration either the 32 or 64 bit version of
elf_check_arch() is defined. parse_crash_elf{32|64}_headers() does
some basic verification of the ELF header via
vmcore_elf{32|64}_check_arch() which happen to map to elf_check_arch().
Since the implementation 32 and 64 bit version of elf_check_arch()
differ, we use the wrong type:

   In file included from include/linux/elf.h:4:0,
                    from fs/proc/vmcore.c:13:
   fs/proc/vmcore.c: In function 'parse_crash_elf64_headers':
>> arch/mips/include/asm/elf.h:228:23: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]
     struct elfhdr *__h = (hdr);     \
                          ^
   include/linux/crash_dump.h:41:37: note: in expansion of macro 'elf_check_arch'
    #define vmcore_elf64_check_arch(x) (elf_check_arch(x) || vmcore_elf_check_arch_cross(x))
                                        ^
   fs/proc/vmcore.c:1015:4: note: in expansion of macro 'vmcore_elf64_check_arch'
      !vmcore_elf64_check_arch(&ehdr) ||
       ^

Therefore, we rather define vmcore_elf{32|64}_check_arch() as a
basic machine check and use it also in binfm_elf?32.c as well.

Signed-off-by: Daniel Wagner <daniel.wagner@bmw-carit.de>
Suggested-by: Maciej W. Rozycki <macro@imgtec.com>
Reviewed-by: Maciej W. Rozycki <macro@imgtec.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Cc: linux-kernel@vger.kernel.org
Cc: linux-mips@linux-mips.org
Patchwork: https://patchwork.linux-mips.org/patch/12529/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-11 11:38:22 +01:00
Tirumalesh Chalamarla 1a1ebd5fb1 irqchip/gic-v3: Make sure read from ICC_IAR1_EL1 is visible on redestributor
The ARM GICv3 specification mentions the need for dsb after a read
from the ICC_IAR1_EL1 register:

	4.1.1 Physical CPU Interface:
	The effects of reading ICC_IAR0_EL1 and ICC_IAR1_EL1
	on the state of a returned INTID are not guaranteed
	to be visible until after the execution of a DSB.

Not having this could result in missed interrupts, so let's add the
required barrier.

[Marc: fixed commit message]

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Tirumalesh Chalamarla <tchalamarla@caviumnetworks.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2016-02-11 10:20:02 +00:00
Jon Hunter 389a00d3ad irqchip/gic: Only set the EOImodeNS bit for the root controller
EOImode1 is only used for the root controller and hence only the root
controller uses the eoimode1 functions for handling interrupts. However,
if the root controller supports EOImode1, then the EOImodeNS bit will be
set for all GICs, enabling EOImode1. This is not what we want and this
causes interrupts on non-root GICs to only be dropped in priority but
never deactivated. Therefore, only set the EOImodeNS bit for the root
controller.

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2016-02-11 10:20:02 +00:00
Jon Hunter 7bf29d3af6 irqchip/gic: Only populate set_affinity for the root controller
Setting the affinity of an IRQ, it only applicable for the root
interrupt controller and so only populate this operator for the root
controller.

Acked-by: Marc Zyngier <marc.zyngier@arm.com>
Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Marc Zyngier <marc.zyngier@arm.com>
2016-02-11 10:20:02 +00:00
Daniel Stone 8e7199c2c5 component: remove device from master match list on failed add
Calling component_add() may result in the completion of a set of
devices, which will try to bring up a master. In bringing the master
up, we populate its match array with the current set of children.

If binding any of the devices fails, component_add() itself will fail,
free the struct component entry, and return to the caller. The
now-freed entry is never removed from the master's match array, and
will later be used in a futile attempt to bind to freed memory.

Bring component_add's behaviour on failure to bring up a master into
line with component_del by removing the (to-be-freed) component from
the master's match array.

The specific case which broke was:
  - rockchip_drm_drv adds a component master
  - dwhdmi_rockchip adds a child component in probe (master incomplete)
  - rockchip_drm_vop adds two children in probe, which completes the
    set
  - inside component_add, we try to bring up the master, having
    populated the master's match array, and fail with EPROBE_DEFER from
    dwhdmi_rockchip; we delete the putative component
  - rockchip_drm_vop's probe fails and returns EPROBE_DEFER
  - we later re-probe rockchip_drm_vop and add the component; the
    master is complete, so we attempt to bring it up again
  - walking the match array, we find the previous child, whose master
    pointer doesn't match (as it has been freed in the meantime)
  - rockchip_drm_vop probe fails, and will never be attempted again

Fixes: ffc30b74fd
Signed-off-by: Daniel Stone <daniels@collabora.com>
Cc: Russell King <rmk+kernel@arm.linux.org.uk>
Cc: Thierry Reding <treding@nvidia.com>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2016-02-11 09:42:09 +00:00
Quinn Tran 5327c7dbd1 qla2xxx: use TARGET_SCF_USE_CPUID flag to indiate CPU Affinity
Signed-off-by: Quinn Tran <quinn.tran@qlogic.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
Fixes: fb3269b ("qla2xxx: Add selective command queuing")
Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2016-02-10 23:09:00 -08:00
Quinn Tran 9095adaab8 target/transport: add flag to indicate CPU Affinity is observed
Signed-off-by: Quinn Tran <quinn.tran@qlogic.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Bart Van Assche <bart.vanassche@sandisk.com>
Fixes: fb3269b ("qla2xxx: Add selective command queuing")
Signed-off-by: Himanshu Madhani <himanshu.madhani@qlogic.com>
Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2016-02-10 23:08:55 -08:00
Nicholas Bellinger 2e498f25b0 target: Fix incorrect unmap_zeroes_data_store return
This patch fixes an incorrect return of zero from the new
unmap_zeroes_data_store() configfs store attribute handler
introduced in v4.5-rc1, to use the correct 'count' bytes
return value.

Signed-off-by: Nicholas Bellinger <nab@linux-iscsi.org>
2016-02-10 20:34:56 -08:00
Chris Mason 43d871f029 Merge branch 'integration-4.5' of git://git.kernel.org/pub/scm/linux/kernel/git/fdmanana/linux into for-linus-4.5 2016-02-10 16:51:38 -08:00
Anton Protopopov 4b550af519 cifs: fix erroneous return value
The setup_ntlmv2_rsp() function may return positive value ENOMEM instead
of -ENOMEM in case of kmalloc failure.

Signed-off-by: Anton Protopopov <a.s.protopopov@gmail.com>
CC: Stable <stable@vger.kernel.org>
Signed-off-by: Steve French <smfrench@gmail.com>
2016-02-10 18:23:31 -06:00
Insu Yun f34d69c3e5 cifs: fix potential overflow in cifs_compose_mount_options
In worst case, "ip=" + sb_mountdata + ipv6 can be copied into mountdata.
Therefore, for safe, it is better to add more size when allocating memory.

Signed-off-by: Insu Yun <wuninsu@gmail.com>
Signed-off-by: Steve French <smfrench@gmail.com>
2016-02-10 18:04:56 -06:00
Colin Ian King 997152f627 cifs: remove redundant check for null string pointer
server_RFC1001_name is declared as a RFC1001_NAME_LEN_WITH_NULL sized
char array in struct TCP_Server_Info so the null pointer check on
server_RFC1001_name is redundant and can be removed.  Detected with
smatch:

fs/cifs/connect.c:2982 ip_rfc1001_connect() warn: this array is probably
  non-NULL. 'server->server_RFC1001_name'

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Steve French <smfrench@gmail.com>
2016-02-10 18:04:53 -06:00
Linus Torvalds 721675fcf2 4.5-rc3 fixes
- One fix to ipoib
 - One fix to core sysfs code
 - Four patches that resolve an oops found in testing of ocrdma and a couple
   other ocrdma issues
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQIcBAABAgAGBQJWu7lOAAoJELgmozMOVy/dDi8QAISZk+WzoTBsfFymoFwo7Yh7
 2W9PAdh/Wp9jH2nTFHwIgS70aLt3oMhXYMZi7xZBtICZI3QRNR0nkNl/FAwafFPo
 FND2j7ftTcDofqD+OTnAE3ZMdgjJhq+z+kjrfrF9pVxdQVOJmpOm6WKZBO7Q9yZJ
 D6eXmOV6+8TYSlFxbbvB158ddMcBdZXOCoJoK1x/iLtyMvoCGPv7s2eVIeozmD4u
 +C16WKaDIO4xu1a/k7rULBEz1QrnlOg0r7XeYgA3ubzJgTPmBc32ZL/qv7oD1O0O
 4LJLS3/HVZdkH3l94b1mGRquLaOM6TVCYs4BR+EibkB0ndYeESU/mqLaKK91zrba
 TrKGLGlXo1VszzCIra2pnalYHHfe+t3dizylXB2/vvmnWAkZcBh9enxPIMXTArJq
 t72ELkj3b6Ln8uuteimYeT5pX1BuxzMPggoSZ1OW19YfUt4UcmJ/RzgaqxFI6fml
 RRH/7XuavKSD9I1eItg3OFyd77YtvdrWx5VxUFOVPnCaHguDDZGI9l7wP9Vtygj4
 Hh5jHB6roS32z4QZ6Z9glQt0i75iXLcznYjfhA8qMRBbph0+qPW9s6gvCkiy5PL1
 eWuxenS2jnrDCkAvA5BIi50QIgzezNMHduUM3FB5W5dyrFrWzJtAII+CDcn8o2DO
 xZKMOpuMPuDXffP66pee
 =Wpl3
 -----END PGP SIGNATURE-----

Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma

Pull rdma fixes from Doug Ledford:
 "A few more minor fixes for rc3:

   - One fix to ipoib
   - One fix to core sysfs code
   - Four patches that resolve an oops found in testing of ocrdma and a
     couple other ocrdma issues"

* tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dledford/rdma:
  RDMA/ocrdma: Fixing ocrdma debugfs directory remove
  RDMA/ocrdma: Fix pkey_index returned by driver in rq work completion
  RDMA/ocrdma: populate max_sge_rd in device attributes
  RDMA/ocrdma: Initialize stats resources in the driver before ib device registration.
  IB/sysfs: remove unused va_list args
  IB/IPoIB: Do not set skb truesize since using one linearskb
2016-02-10 15:11:08 -08:00
Dave Airlie c92a428f40 Merge branch 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux into drm-fixes
radeon and amdgpu fixes for 4.5.  Highlights:
- powerplay fixes for amdgpu
- race fixes in the sub-allocator in radeon and amdgpu
- hibernate fix for amdgpu
- fix a possible circular locking in userptr handling in amdgpu

* 'drm-fixes-4.5' of git://people.freedesktop.org/~agd5f/linux: (21 commits)
  drm/amdgpu: fix issue with overlapping userptrs
  drm/radeon: hold reference to fences in radeon_sa_bo_new
  drm/amdgpu: remove unnecessary forward declaration
  drm/amdgpu: hold reference to fences in amdgpu_sa_bo_new (v2)
  drm/amdgpu: fix s4 resume
  drm/amdgpu/cz: plumb pg flags through to powerplay
  drm/amdgpu/tonga: plumb pg flags through to powerplay
  drma/dmgpu: move cg and pg flags into shared headers
  drm/amdgpu: remove unused cg defines
  drm/amdgpu: add a cgs interface to fetch cg and pg flags
  drm/amd/powerplay/tonga: disable vce pg
  drm/amd/powerplay/tonga: disable uvd pg
  drm/amd/powerplay/cz: disable vce pg
  drm/amd/powerplay/cz: disable uvd pg
  drm/amdgpu: be consistent with uvd cg flags
  drm/amdgpu: clean up vce pg flags for cz/st
  drm/amdgpu: handle vce pg flags properly
  drm/amdgpu: handle uvd pg flags properly
  drm/amdgpu/dpm/ci: switch over to the common pcie caps interface
  drm/amdgpu/cik: don't mess with aspm if gpu is root bus
  ...
2016-02-11 08:39:07 +10:00
Daniel Borkmann a1b14d27ed bpf: fix branch offset adjustment on backjumps after patching ctx expansion
When ctx access is used, the kernel often needs to expand/rewrite
instructions, so after that patching, branch offsets have to be
adjusted for both forward and backward jumps in the new eBPF program,
but for backward jumps it fails to account the delta. Meaning, for
example, if the expansion happens exactly on the insn that sits at
the jump target, it doesn't fix up the back jump offset.

Analysis on what the check in adjust_branches() is currently doing:

  /* adjust offset of jmps if necessary */
  if (i < pos && i + insn->off + 1 > pos)
    insn->off += delta;
  else if (i > pos && i + insn->off + 1 < pos)
    insn->off -= delta;

First condition (forward jumps):

  Before:                         After:

  insns[0]                        insns[0]
  insns[1] <--- i/insn            insns[1] <--- i/insn
  insns[2] <--- pos               insns[P] <--- pos
  insns[3]                        insns[P]  `------| delta
  insns[4] <--- target_X          insns[P]   `-----|
  insns[5]                        insns[3]
                                  insns[4] <--- target_X
                                  insns[5]

First case is if we cross pos-boundary and the jump instruction was
before pos. This is handeled correctly. I.e. if i == pos, then this
would mean our jump that we currently check was the patchlet itself
that we just injected. Since such patchlets are self-contained and
have no awareness of any insns before or after the patched one, the
delta is correctly not adjusted. Also, for the second condition in
case of i + insn->off + 1 == pos, means we jump to that newly patched
instruction, so no offset adjustment are needed. That part is correct.

Second condition (backward jumps):

  Before:                         After:

  insns[0]                        insns[0]
  insns[1] <--- target_X          insns[1] <--- target_X
  insns[2] <--- pos <-- target_Y  insns[P] <--- pos <-- target_Y
  insns[3]                        insns[P]  `------| delta
  insns[4] <--- i/insn            insns[P]   `-----|
  insns[5]                        insns[3]
                                  insns[4] <--- i/insn
                                  insns[5]

Second interesting case is where we cross pos-boundary and the jump
instruction was after pos. Backward jump with i == pos would be
impossible and pose a bug somewhere in the patchlet, so the first
condition checking i > pos is okay only by itself. However, i +
insn->off + 1 < pos does not always work as intended to trigger the
adjustment. It works when jump targets would be far off where the
delta wouldn't matter. But, for example, where the fixed insn->off
before pointed to pos (target_Y), it now points to pos + delta, so
that additional room needs to be taken into account for the check.
This means that i) both tests here need to be adjusted into pos + delta,
and ii) for the second condition, the test needs to be <= as pos
itself can be a target in the backjump, too.

Fixes: 9bac3d6d54 ("bpf: allow extended BPF programs access skb fields")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-10 16:56:47 -05:00
Linus Torvalds 74c7b2af37 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input
Pull input updates from Dmitry Torokhov:
 "Just small driver fixups"

* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
  Input: colibri-vf50-ts - add missing #include <linux/of.h>
  Input: adp5589 - fix row 5 handling for adp5589
  Input: edt-ft5x06 - fix setting gain, offset, and threshold via device tree
  Input: vmmouse - fix absolute device registration
  Input: serio - drop warnings in case of EPROBE_DEFER from serio_find_driver()
  Input: cap11xx - add missing of_node_put
  Input: sirfsoc-onkey - allow modular build
  Input: xpad - remove unused function
2016-02-10 12:21:57 -08:00
Linus Torvalds 4e54169986 Merge branch 'for-4.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata
Pull libata fixes from Tejun Heo:

 - PORTS_IMPL workaround for very early ahci controllers is misbehaving
   on new systems.  Disabled on recent ahci versions.

 - Old-style PIO state machine had a horrible locking problem.  Don't
   know how we've been getting away this far.  Fixed.

 - Other device specific updates.

* 'for-4.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/libata:
  ahci: Intel DNV device IDs SATA
  libata: fix sff host state machine locking while polling
  libata-sff: use WARN instead of BUG on illegal host state machine state
  libata: disable forced PORTS_IMPL for >= AHCI 1.3
  libata: blacklist a Viking flash model for MWDMA corruption
  drivers: ata: wake port before DMA stop for ALPM
2016-02-10 12:04:59 -08:00
Linus Torvalds fb0dc5f129 Merge branch 'for-4.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup
Pull cgroup fixes from Tejun Heo:

 - The destruction path of cgroup objects are asynchronous and
   multi-staged and some of them ended up destroying parents before
   children leading to failures in cpu and memory controllers.  Ensure
   that parents are always destroyed after children.

 - cpuset mm node migration was performed synchronously while holding
   threadgroup and cgroup mutexes and the recent threadgroup locking
   update resulted in a possible deadlock.  The migration is best effort
   and shouldn't have been performed under those locks to begin with.
   Made asynchronous.

 - Minor documentation fix.

* 'for-4.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup:
  Documentation: cgroup: Fix 'cgroup-legacy' -> 'cgroup-v1'
  cgroup: make sure a parent css isn't freed before its children
  cgroup: make sure a parent css isn't offlined before its children
  cpuset: make mm migration asynchronous
2016-02-10 11:36:19 -08:00
Mark Brown f11aec0d7c Merge remote-tracking branches 'asoc/fix/rt5659', 'asoc/fix/sigmadsp', 'asoc/fix/simple', 'asoc/fix/wm5110' and 'asoc/fix/wm8960' into asoc-linus 2016-02-10 19:23:09 +00:00
Mark Brown 733f4c79de Merge remote-tracking branches 'asoc/fix/imx-spdif', 'asoc/fix/mtk', 'asoc/fix/mxs-saif', 'asoc/fix/qcom' and 'asoc/fix/rt286' into asoc-linus 2016-02-10 19:23:07 +00:00
Mark Brown cf0d6dd9d3 Merge remote-tracking branches 'asoc/fix/amd', 'asoc/fix/arizona', 'asoc/fix/dpcm', 'asoc/fix/dwc', 'asoc/fix/fsl' and 'asoc/fix/fsl-ssi' into asoc-linus 2016-02-10 19:23:04 +00:00
Mark Brown 97b0d5c9b2 Merge remote-tracking branch 'asoc/fix/rt5645' into asoc-linus 2016-02-10 19:23:03 +00:00
Mark Brown 6719f657e4 Merge remote-tracking branch 'asoc/fix/intel-kconfig' into asoc-linus 2016-02-10 19:23:02 +00:00
Mark Brown 7ff60f58e2 Merge remote-tracking branch 'asoc/fix/intel' into asoc-linus 2016-02-10 19:23:02 +00:00
Mark Brown 2022d24e2b Merge remote-tracking branch 'asoc/fix/dapm' into asoc-linus 2016-02-10 19:23:01 +00:00
Richard Fitzgerald 01582a8414 ASoC: arizona: fref must be limited in pseudo-fractional mode
When the FLL is in pseudo-fractional mode there is an additional
limit on fref based on the fratio, to prevent aliasing around the
Nyquist frequency. If fref exceeds this limit the refclk divider
must be increased and the calculation tried again until a suitable
combination of fref and fratio is found or we have to fall back to
integer mode.

This patch also adds some debug log prints around this code.

Signed-off-by: Richard Fitzgerald <rf@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-10 19:21:41 +00:00
Christian König cc1de6e800 drm/amdgpu: fix issue with overlapping userptrs
Otherwise we could try to evict overlapping userptr BOs in get_user_pages(),
leading to a possible circular locking dependency.

Signed-off-by: Christian König <christian.koenig@amd.com>
Acked-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2016-02-10 14:07:52 -05:00
Nicolai Hähnle f6ff4f67cd drm/radeon: hold reference to fences in radeon_sa_bo_new
An arbitrary amount of time can pass between spin_unlock and
radeon_fence_wait_any, so we need to ensure that nobody frees the
fences from under us.

Based on the analogous fix for amdgpu.

Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
2016-02-10 14:07:44 -05:00
Nicolai Hähnle b19763d0d8 drm/amdgpu: remove unnecessary forward declaration
Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
2016-02-10 14:07:38 -05:00
Nicolai Hähnle a8d81b3626 drm/amdgpu: hold reference to fences in amdgpu_sa_bo_new (v2)
An arbitrary amount of time can pass between spin_unlock and
fence_wait_any_timeout, so we need to ensure that nobody frees the
fences from under us.

A stress test (rapidly starting and killing hundreds of glxgears
instances) ran into a deadlock in fence_wait_any_timeout after
about an hour, and this race condition appears to be a plausible
cause.

v2: agd: rebase on upstream

Signed-off-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Reviewed-by: Christian König <christian.koenig@amd.com>
Cc: stable@vger.kernel.org
2016-02-10 14:07:31 -05:00
Flora Cui ca19852884 drm/amdgpu: fix s4 resume
No need to re-init asic if it's already been initialized.
Skip IB tests since kernel processes are frozen in thaw.

Signed-off-by: Flora Cui <Flora.Cui@amd.com>
Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
2016-02-10 14:07:13 -05:00
Linus Torvalds 9aece75c13 Merge branch 'for-4.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq
Pull workqueue fixes from Tejun Heo:
 "Workqueue fixes for v4.5-rc3.

   - Remove a spurious triggering of flush dependency warning.

   - Officially break local execution guarantee of unbound work items
     and add a debug feature to flush out usages which depend on it.

   - Work around CPU -> NODE mapping becoming invalid on CPU offline.

  The branch is young but pushing out early as stable kernels are being
  affected"

* 'for-4.5-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
  workqueue: handle NUMA_NO_NODE for unbound pool_workqueue lookup
  workqueue: implement "workqueue.debug_force_rr_cpu" debug feature
  workqueue: schedule WORK_CPU_UNBOUND work on wq_unbound_cpumask CPUs
  Revert "workqueue: make sure delayed work run in local cpu"
  workqueue: skip flush dependency checks for legacy workqueues
2016-02-10 11:04:05 -08:00
Pascal Huerst 61c4a1ac4d ASoC: sigmadsp: Fix missleading return value
Forwarding the return value of i2c_master_send, leads to errors
later on, since i2c_master_send returns the number of bytes
transmittet. Check for ret < 0 instead and return 0 otherwise.

Signed-off-by: Pascal Huerst <pascal.huerst@gmail.com>
Acked-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
2016-02-10 18:55:01 +00:00
Tejun Heo d6e022f1d2 workqueue: handle NUMA_NO_NODE for unbound pool_workqueue lookup
When looking up the pool_workqueue to use for an unbound workqueue,
workqueue assumes that the target CPU is always bound to a valid NUMA
node.  However, currently, when a CPU goes offline, the mapping is
destroyed and cpu_to_node() returns NUMA_NO_NODE.

This has always been broken but hasn't triggered often enough before
874bbfe600 ("workqueue: make sure delayed work run in local cpu").
After the commit, workqueue forcifully assigns the local CPU for
delayed work items without explicit target CPU to fix a different
issue.  This widens the window where CPU can go offline while a
delayed work item is pending causing delayed work items dispatched
with target CPU set to an already offlined CPU.  The resulting
NUMA_NO_NODE mapping makes workqueue try to queue the work item on a
NULL pool_workqueue and thus crash.

While 874bbfe600 has been reverted for a different reason making the
bug less visible again, it can still happen.  Fix it by mapping
NUMA_NO_NODE to the default pool_workqueue from unbound_pwq_by_node().
This is a temporary workaround.  The long term solution is keeping CPU
-> NODE mapping stable across CPU off/online cycles which is being
worked on.

Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Mike Galbraith <umgwanakikbuti@gmail.com>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Rafael J. Wysocki <rafael@kernel.org>
Cc: Len Brown <len.brown@intel.com>
Cc: stable@vger.kernel.org
Link: http://lkml.kernel.org/g/1454424264.11183.46.camel@gmail.com
Link: http://lkml.kernel.org/g/1453702100-2597-1-git-send-email-tangchen@cn.fujitsu.com
2016-02-10 12:13:05 -05:00
Alexandra Yates 342decff2b ahci: Intel DNV device IDs SATA
Adding Intel codename DNV platform device IDs for SATA.

Signed-off-by: Alexandra Yates <alexandra.yates@linux.intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
2016-02-10 11:35:55 -05:00
Rasmus Villemoes ed3f9fd1e8 drm/i915: fix error path in intel_setup_gmbus()
This fails to undo the setup for pin==0; moreover, something
interesting happens if the setup failed already at pin==0.

Signed-off-by: Rasmus Villemoes <linux@rasmusvillemoes.dk>
Fixes: f899fc64cd ("drm/i915: use GMBUS to manage i2c links")
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1455048677-19882-3-git-send-email-linux@rasmusvillemoes.dk
(cherry picked from commit 2417c8c03f)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-10 18:11:34 +02:00
Lyude 39748841a7 drm/i915/skl: Fix typo in DPLL_CFGCR1 definition
We accidentally point both cfgcr registers for the second shared DPLL to
the same location in i915_reg.h. This results in a lot of hw pipe state
mismatches whenever we try to do a modeset that requires allocating the
DPLL to a CRTC:

[drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr1 (expected 0x80000168, found 0x000004a5)
[drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in base.adjusted_mode.crtc_clock (expected 108000, found 49500)
[drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock (expected 108000, found 49500)

This usually ends up causing blank monitors, since the DPLL never can
get set to the right clock.

Fixes: 086f8e84a0 ("drm/i915: Prefix raw register defines with underscore")
Signed-off-by: Lyude <cpaul@redhat.com>
Cc: drm-intel-fixes@lists.freedesktop.org
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1454600601-21900-1-git-send-email-cpaul@redhat.com
(cherry picked from commit da3b891b0f)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-10 18:02:42 +02:00
Chris Paterson a32ef81c98 mmc: sh_mmcif: Correct TX DMA channel allocation
Commit 27cbd7e815 ("mmc: sh_mmcif: rework dma channel handling")
introduced a typo causing the TX DMA channel allocation to be overwritten
by the requested RX DMA channel.

Fixes: 27cbd7e815 ("mmc: sh_mmcif: rework dma channel handling")
Signed-off-by: Chris Paterson <chris.paterson2@renesas.com>
Acked-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Acked-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-02-10 17:02:25 +01:00
Lyude 3d849b0233 drm/i915/skl: Don't skip mst encoders in skl_ddi_pll_select()
We don't actually check for INTEL_OUTPUT_DP_MST at all in here, as a
result we skip assigning a DPLL to any DP MST ports, which makes link
training fail:

[ 1442.933896] [drm:intel_power_well_enable] enabling DDI D power well
[ 1442.933905] [drm:skl_set_power_well] Enabling DDI D power well
[ 1442.933957] [drm:intel_mst_pre_enable_dp] 0
[ 1442.935474] [drm:intel_dp_set_signal_levels] Using signal levels 00000000
[ 1442.935477] [drm:intel_dp_set_signal_levels] Using vswing level 0
[ 1442.935480] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 0
[ 1442.936190] [drm:intel_dp_set_signal_levels] Using signal levels 05000000
[ 1442.936193] [drm:intel_dp_set_signal_levels] Using vswing level 1
[ 1442.936195] [drm:intel_dp_set_signal_levels] Using pre-emphasis level 1
[ 1442.936858] [drm:intel_dp_set_signal_levels] Using signal levels 08000000
[ 1442.936862] [drm:intel_dp_set_signal_levels] Using vswing level 2
…
[ 1442.998253] [drm:intel_dp_link_training_clock_recovery [i915]] *ERROR* too many full retries, give up
[ 1442.998512] [drm:intel_dp_start_link_train [i915]] *ERROR* failed to train DP, aborting

After which the pipe state goes completely out of sync:

[   70.075596] [drm:check_crtc_state] [CRTC:25]
[   70.075696] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in ddi_pll_sel (expected 0x00000000, found 0x00000001)
[   70.075747] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in shared_dpll (expected -1, found 0)
[   70.075798] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.ctrl1 (expected 0x00000000, found 0x00000021)
[   70.075840] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr1 (expected 0x00000000, found 0x80400173)
[   70.075884] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in dpll_hw_state.cfgcr2 (expected 0x00000000, found 0x000003a5)
[   70.075954] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in base.adjusted_mode.crtc_clock (expected 262750, found 72256)
[   70.075999] [drm:intel_pipe_config_compare [i915]] *ERROR* mismatch in port_clock (expected 540000, found 148500)

And if you're especially lucky, it keeps going downhill:

[   83.309256] Kernel panic - not syncing: Timeout: Not all CPUs entered broadcast exception handler
[   83.309265]
[   83.309265] =================================
[   83.309266] [ INFO: inconsistent lock state ]
[   83.309267] 4.5.0-rc1Lyude-Test #265 Not tainted
[   83.309267] ---------------------------------
[   83.309268] inconsistent {IN-HARDIRQ-W} -> {HARDIRQ-ON-W} usage.
[   83.309270] Xorg/1194 [HC0[1]:SC0[0]:HE1:SE1] takes:
[   83.309293]  (&(&dev_priv->uncore.lock)->rlock){?.-...}, at: [<ffffffffa02a6073>] gen9_write32+0x63/0x400 [i915]
[   83.309293] {IN-HARDIRQ-W} state was registered at:
[   83.309297]   [<ffffffff810e84f4>] __lock_acquire+0x9c4/0x1d00
[   83.309299]   [<ffffffff810ea1be>] lock_acquire+0xce/0x1c0
[   83.309302]   [<ffffffff8177d936>] _raw_spin_lock_irqsave+0x56/0x90
[   83.309321]   [<ffffffffa02a5492>] gen9_read32+0x52/0x3d0 [i915]
[   83.309332]   [<ffffffffa024beea>] gen8_irq_handler+0x27a/0x6a0 [i915]
[   83.309337]   [<ffffffff810fdbc1>] handle_irq_event_percpu+0x41/0x300
[   83.309339]   [<ffffffff810fdeb9>] handle_irq_event+0x39/0x60
[   83.309341]   [<ffffffff811010b4>] handle_edge_irq+0x74/0x130
[   83.309344]   [<ffffffff81009073>] handle_irq+0x73/0x120
[   83.309346]   [<ffffffff817805f1>] do_IRQ+0x61/0x120
[   83.309348]   [<ffffffff8177e6d6>] ret_from_intr+0x0/0x20
[   83.309351]   [<ffffffff815f5105>] cpuidle_enter_state+0x105/0x330
[   83.309353]   [<ffffffff815f5367>] cpuidle_enter+0x17/0x20
[   83.309356]   [<ffffffff810dbe1a>] call_cpuidle+0x2a/0x50
[   83.309358]   [<ffffffff810dc1dd>] cpu_startup_entry+0x26d/0x3a0
[   83.309360]   [<ffffffff817701da>] rest_init+0x13a/0x140
[   83.309363]   [<ffffffff81f2af8e>] start_kernel+0x475/0x482
[   83.309365]   [<ffffffff81f2a315>] x86_64_start_reservations+0x2a/0x2c
[   83.309367]   [<ffffffff81f2a452>] x86_64_start_kernel+0x13b/0x14a

Fixes: 82d3543701 ("drm/i915/skl: Implementation of SKL DPLL programming")
Signed-off-by: Lyude <cpaul@redhat.com>
Cc: stable@vger.kernel.org
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: http://patchwork.freedesktop.org/patch/msgid/1454428183-994-1-git-send-email-cpaul@redhat.com
(cherry picked from commit 78385cb398)
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-10 18:01:59 +02:00
Zubair Lutfullah Kakakhel b96d6a80c9 MIPS: Octeon: Update OCTEON_FEATURE_PCIE for Octeon III
Currently the driver tries to probe the pci driver and oops.

Add CN7XXX to case so that driver probes the pcie driver.

Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com>
Cc: david.daney@cavium.com
Cc: matt.redfearn@imgtec.com
Cc: linux-mips@linux-mips.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12530/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-10 15:08:53 +01:00
David S. Miller 1902750b50 Merge branch 'ovs-tunnel-mtu'
David Wragg says:

====================
Set a large MTU on ovs-created tunnel devices

Prior to 4.3, openvswitch tunnel vports (vxlan, gre and geneve) could
transmit vxlan packets of any size, constrained only by the ability to
send out the resulting packets.  4.3 introduced netdevs corresponding
to tunnel vports.  These netdevs have an MTU, which limits the size of
a packet that can be successfully encapsulated.  The default MTU
values are low (1500 or less), which is awkwardly small in the context
of physical networks supporting jumbo frames, and leads to a
conspicuous change in behaviour for userspace.

This patch series sets the MTU on openvswitch-created netdevs to be
the relevant maximum (i.e. the maximum IP packet size minus any
relevant overhead), effectively restoring the behaviour prior to 4.3.

Where relevant, the limits on MTU values that can be directly set on
the netdevs are also relaxed.

Changes in v2:
* Extend to all openvswitch tunnel types, i.e. gre and geneve as well
* Use IP_MAX_MTU

Changes in v3:
* Fix block comment style
====================

Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-10 05:50:16 -05:00
David Wragg 7e059158d5 vxlan, gre, geneve: Set a large MTU on ovs-created tunnel devices
Prior to 4.3, openvswitch tunnel vports (vxlan, gre and geneve) could
transmit vxlan packets of any size, constrained only by the ability to
send out the resulting packets.  4.3 introduced netdevs corresponding
to tunnel vports.  These netdevs have an MTU, which limits the size of
a packet that can be successfully encapsulated.  The default MTU
values are low (1500 or less), which is awkwardly small in the context
of physical networks supporting jumbo frames, and leads to a
conspicuous change in behaviour for userspace.

Instead, set the MTU on openvswitch-created netdevs to be the relevant
maximum (i.e. the maximum IP packet size minus any relevant overhead),
effectively restoring the behaviour prior to 4.3.

Signed-off-by: David Wragg <david@weave.works>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-10 05:50:03 -05:00
David Wragg 55e5bfb53c geneve: Relax MTU constraints
Allow the MTU of geneve devices to be set to large values, in order to
exploit underlying networks with larger frame sizes.

GENEVE does not have a fixed encapsulation overhead (an openvswitch
rule can add variable length options), so there is no relevant maximum
MTU to enforce.  A maximum of IP_MAX_MTU is used instead.
Encapsulated packets that are too big for the underlying network will
get dropped on the floor.

Signed-off-by: David Wragg <david@weave.works>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-10 05:50:03 -05:00
David Wragg 72564b59ff vxlan: Relax MTU constraints
Allow the MTU of vxlan devices without an underlying device to be set
to larger values (up to a maximum based on IP packet limits and vxlan
overhead).

Previously, their MTUs could not be set to higher than the
conventional ethernet value of 1500.  This is a very arbitrary value
in the context of vxlan, and prevented vxlan devices from being able
to take advantage of jumbo frames etc.

The default MTU remains 1500, for compatibility.

Signed-off-by: David Wragg <david@weave.works>
Acked-by: Roopa Prabhu <roopa@cumulusnetworks.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-02-10 05:50:03 -05:00
Lokesh Vutla 6ec9249a83 gpio: davinci: Fix the number of controllers allocated
Driver only needs to allocate for [ngpio / 32] controllers,
as each controller handles 32 gpios. But the current driver
allocates for ngpio of which the extra allocated are unused.
Fix it be registering only the required number of controllers.

Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com>
Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-02-10 11:00:49 +01:00
Keerthy 310a7e6043 gpio: davinci: Add the missing of-node pointer
Currently the first parameter of irq_domain_add_legacy is NULL.
irq_find_host function returns NULL when we do not populate the of_node
and hence irq_of_parse_and_map call fails whenever we want to request a
gpio irq. This fixes the request_irq failures for gpio interrupts.

Signed-off-by: Keerthy <j-keerthy@ti.com>
Reviewed-by: Grygorii Strashko <grygorii.strashko@ti.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
2016-02-10 10:59:12 +01:00
Wei Yongjun aaa0bf22cb MIPS: pci-mt7620: Fix return value check in mt7620_pci_probe()
In case of error, the function devm_ioremap_resource() returns
ERR_PTR() and never returns NULL. The NULL test in the return
value check should be replaced with IS_ERR().

Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Acked-by: John Crispin <blogic@openwrt.org>
Cc: Matthias Brugger <matthias.bgg@gmail.com>
Cc: linux-mips@linux-mips.org
Cc: linux-mediatek@lists.infradead.org
Cc: linux-kernel@vger.kernel.org
Patchwork: https://patchwork.linux-mips.org/patch/12451/
Signed-off-by: Ralf Baechle <ralf@linux-mips.org>
2016-02-10 10:01:44 +01:00
Olof Johansson f00ab14c25 mmc: block: return error on failed mmc_blk_get()
This used to return -EFAULT, but the function above returns -EINVAL on
the same condition so let's stick to that.

The removal of error return on this path was introduced with b093410c9a
('mmc: block: copy resp[] data on err for MMC_IOC_MULTI_CMD').

Fixes: b093410c9a ('mmc: block: copy resp[] data on err for MMC_IOC_MULTI_CMD').
Signed-off-by: Olof Johansson <olof@lixom.net>
Cc: Grant Grundler <grundler@google.com>
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
2016-02-10 09:12:34 +01:00