linux

Fork

Merge branch 'fix/omap' into fixes

Merge branch 'fix/hsu' into fixes

x86/hyperv: Avoid reporting bogus NMI status for Gen2 instances

Generation2 instances don't support reporting the NMI status on port 0x61,
read from there returns 'ff' and we end up reporting nonsensical PCI
error (as there is no PCI bus in these instances) on all NMIs:

NMI: PCI system error (SERR) for reason ff on CPU 0.
Dazed and confused, but trying to continue

Fix the issue by overriding x86_platform.get_nmi_reason. Use 'booted on
EFI' flag to detect Gen2 instances.

Signed-off-by: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Cathy Avery <cavery@redhat.com>
Cc: Haiyang Zhang <haiyangz@microsoft.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: K. Y. Srinivasan <kys@microsoft.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: devel@linuxdriverproject.org
Link: http://lkml.kernel.org/r/1460728232-31433-1-git-send-email-vkuznets@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>

objtool: Detect falling through to the next function

There are several cases in compiled C code where a function may not
return at the end, and may instead fall through to the next function.

That may indicate a bug in the code, or a gcc bug, or even an objtool
bug. But in each case, objtool reports an unhelpful warning, something
like:

drivers/scsi/qla2xxx/qla_attr.o: warning: objtool: qla2x00_get_fc_host_stats()+0x0: duplicate frame pointer save
drivers/scsi/qla2xxx/qla_attr.o: warning: objtool: qla2x00_get_fc_host_stats()+0x0: frame pointer state mismatch

Detect this situation and print a more useful error message:

drivers/scsi/qla2xxx/qla_attr.o: warning: objtool: qla2x00_get_host_fabric_name() falls through to next function qla2x00_get_starget_node_name()

Also add some information about this warning and its potential causes to
the documentation.

Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/caa4ec6c687931db805e692d4e4bf06cd87d33e6.1460729697.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>

vlan: pull on __vlan_insert_tag error path and fix csum correction

When __vlan_insert_tag() fails from skb_vlan_push() path due to the
skb_cow_head(), we need to undo the __skb_push() in the error path
as well that was done earlier to move skb->data pointer to mac header.

Moreover, I noticed that when in the non-error path the __skb_pull()
is done and the original offset to mac header was non-zero, we fixup
from a wrong skb->data offset in the checksum complete processing.

So the skb_postpush_rcsum() really needs to be done before __skb_pull()
where skb->data still points to the mac header start and thus operates
under the same conditions as in __vlan_insert_tag().

Fixes: 93515d53b133 ("net: move vlan pop/push functions into common code")
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

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

Pull block fixes from Jens Axboe:
"A few fixes for the current series. This contains:

- Two fixes for NVMe:

One fixes a reset race that can be triggered by repeated
insert/removal of the module.

The other fixes an issue on some platforms, where we get probe
timeouts since legacy interrupts isn't working. This used not to
be a problem since we had the worker thread poll for completions,
but since that was killed off, it means those poor souls can't
successfully probe their NVMe device. Use a proper IRQ check and
probe (msi-x -> msi ->legacy), like most other drivers to work
around this. Both from Keith.

- A loop corruption issue with offset in iters, from Ming Lei.

- A fix for not having the partition stat per cpu ref count
initialized before sending out the KOBJ_ADD, which could cause user
space to access the counter prior to initialization. Also from
Ming Lei.

- A fix for using the wrong congestion state, from Kaixu Xia"

* 'for-linus' of git://git.kernel.dk/linux-block:
block: loop: fix filesystem corruption in case of aio/dio
NVMe: Always use MSI/MSI-x interrupts
NVMe: Fix reset/remove race
writeback: fix the wrong congested state variable definition
block: partition: initialize percpuref before sending out KOBJ_ADD

Merge branch 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm

Pull libnvdimm fixes from Ross Zwisler:
"Two fixes:

- Fix memcpy_from_pmem() to fallback to memcpy() for architectures
where CONFIG_ARCH_HAS_PMEM_API=n.

- Add a comment explaining why we write data twice when clearing
poison in pmem_do_bvec().

This has passed a boot test on an X86_32 config, which was the
architecture where issue #1 above was first noticed"

Dan Williams adds:
"We're giving this multi-maintainer setup a shot, so expect libnvdimm
pull requests from either Ross or I going forward"

* 'libnvdimm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm:
libnvdimm, pmem: clarify the write+clear_poison+write flow
pmem: fix BUG() error in pmem.h:48 on X86_32

One MTD fix for v4.6-rc4:

In the v4.4 cycle, we relaxed the requirement for assigning mtd->owner, but we
didn't remove this error case. It's hit only by drivers that are both:

(a) using nand_scan() directly and
(b) built as modules

We haven't seen explicit complaints about this (most use cases don't fit one or
both of the above), but we should definitely not be BUG()'ing here.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAABAgAGBQJXEWZUAAoJEFySrpd9RFgtuaYQAIjfmoefoDJuIw3QQE5tLNMc
xTj07f+V/Nzhats69zvjx4LNFF6R339IBFNq7WK+q7l7VbW6/XSa8XaQkgpO+wMI
Sqzkty4YIxQGucITVvauv82JW0K421XVUBAzeNt+4oT72RvMnXhOPka1LQXf3Ezh
vGb7ZGea7ZYuu060OQAGxJlrlDA5x7yhsvs3hpOT9hjx0jXr0JZXmohvFRqSiXqz
Rx60rmhpl37WJg46OX/LYRAF34StF8btDZsQVdpY75T9QtxD3vWvvlMHfJ4cQXRI
L3qUIGGj03tD0/4nf6/p+WMjxgctDqROVxWzLHOvTa+xIFR7iU8yra09fTbylOGL
C3I0B6kW05YJrY3TegL8EhNbotciC9SeCtbeRwbndyO1Jox88xGHovwWFN5++3Q+
4ahiP57cV/py1L2BgeYdPmHES6T4GLH/4y2MaMZr4hfGVxHbKN1/JkLp9cNqCSzZ
MtnEevbHYq4eN1rYULQCzLRxawhYjeY77cMYip6Ynu24UWUJmfdaroJncfmmBOhP
7NvWjtxpsjonrCVOdb4aq9UPTc3PxlyR4kZyzg7+Vx4eOByK8hFkfjckehJ64DCs
ac+r5d2LmaLqAMIvQt4ApwwzRzj4ST6CEWBEyKrvwwF4B4nHhkbf9Pf4IrzGmaao
W4dws70o9WUwGIv0Rw3D
=wxaC
-----END PGP SIGNATURE-----

Merge tag 'for-linus-20160415' of git://git.infradead.org/linux-mtd

Pull MTD fix from Brian Norris:
"One MTD fix for v4.6-rc4:

In the v4.4 cycle, we relaxed the requirement for assigning
mtd->owner, but we didn't remove this error case. It's hit only
by drivers that are both:

(a) using nand_scan() directly
and
(b) built as modules

We haven't seen explicit complaints about this (most use cases don't
fit one or both of the above), but we should definitely not be
BUG()'ing here"

* tag 'for-linus-20160415' of git://git.infradead.org/linux-mtd:
mtd: nand: Drop mtd.owner requirement in nand_scan

MMC core:
- Restore similar old behaviour when assigning mmcblk device indexes

MMC host:
- tegra: Disable UHS-I modes for Tegra124 to fix regression
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAABAgAGBQJXELVaAAoJEP4mhCVzWIwpvCQP/i1P0tPTLKvHmuKMnCbrIVN/
GWbUNjcui4YnOBufJDFZ3QnHVWpnSDpa+dGmzsO0Vpi7OSRWmvgWwwqwspSZUcp/
2c//US3R7iiVQ2ww2Kf7IErmi2CqHxL+ItWtZO3MaabiC0fCPPtjBRnfbftTFBJ5
5zcHeXJTkBF8rXtaz6URwACvlGsPluvVutxLRsEoHDQU0rsTgysbzTr2fu+M7IDI
jE3Q0U5xdIlT8YqmsQTUwdWF12STlBJfHwsGxOSxZTOnLOiNwoSoDftXvA+qH27V
C/gJUP8Di6sgYKPY7zqdN9eF0DAnK6n4QSpyzFEG9U2zNvW6enXiv8RBWRhfGjVp
VW/1XE8DE//l+WCxEQhjiFcBDAJ8ahfcdbsp7Ngd5t8WJVydL0dGpHLolCWwABMl
YMuRaH2eJznxazn0CRrIxRO9OIISandj3G5COkOOaar+2YzIWUotrk+q+swyq2x/
5hgSyaxYm27J7RUTx31YtQxCZownrNvyQAwj3omoe2ffWTENJeAobkBiLrzbSuaL
2TxhRJig75vOcFN6cZI0dhHR47j6uYVYJ62aWi3OzwpGR5Wz7h4zkVN5GRmNYBdE
JB5neGiEeCDnvbZ5tGHR3+ZNnDjFthAK88NagqknZFlnm6VOIsj4dCa2gBvwc1xu
wOobQCSH7JuQqS7JHjuy
=nnxN
-----END PGP SIGNATURE-----

Merge tag 'mmc-v4.6-rc3' of git://git.linaro.org/people/ulf.hansson/mmc

Pull MMC fixes from Ulf Hansson:
"Here are a couple of mmc fixes intended for v4.6 rc4.

Regarding the fix for the regression about mmcblk device indexes. The
approach taken to solve the problem seems to be good enough. There
were some discussions around the solution, but it seems like people
were happy about it in the end.

MMC core:
- Restore similar old behaviour when assigning mmcblk device indexes

MMC host:
- tegra: Disable UHS-I modes for Tegra124 to fix regression"

* tag 'mmc-v4.6-rc3' of git://git.linaro.org/people/ulf.hansson/mmc:
mmc: tegra: Disable UHS-I modes for Tegra124
mmc: block: Use the mmc host device index as the mmcblk device index

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

Pull drm fixes from Dave Airlie:
"This contains fixes for exynos, amdgpu, radeon, i915 and qxl.

It also contains some fixes to the core drm edid parser.

qxl:
- fix for a cursor hotspot issue

radeon:
- some MST fixes that I've been running locally and make my monitor a
bit happier

exynos:
- fix some regressions and build fixes

amdgpu:
- a couple of small fixes

i915:
- two DP MST fixes and a couple of other regression fixes

Nothing too out of the ordinary or surprising at this point"

* 'drm-fixes' of git://people.freedesktop.org/~airlied/linux:
drm/exynos: Use VIDEO_SAMSUNG_S5P_G2D=n as G2D Kconfig dependency
drm/exynos: fix a warning message
drm/exynos: mic: fix an error code
drm/exynos: fimd: fix broken dp_clock control
drm/exynos: build fbdev code conditionally
drm/exynos: fix adjusted_mode pointer in exynos_plane_mode_set
drm/exynos: fix error handling in exynos_drm_subdrv_open
drm/amd/amdgpu: fix irq domain remove for tonga ih
drm/i915: fix deadlock on lid open
drm/radeon: use helper for mst connector dpms.
drm/radeon/mst: port some MST setup code from DAL.
drm/amdgpu: add invisible pin size statistic
drm/edid: Fix DMT 1024x768@43Hz (interlaced) timings
drm/i915: Exit cherryview_irq_handler() after one pass
drm/i915: Call intel_dp_mst_resume() before resuming displays
drm/i915: Fix race condition in intel_dp_destroy_mst_connector()
drm/edid: Fix parsing of EDID 1.4 Established Timings III descriptor
drm/edid: Fix EDID Established Timings I and II
drm/qxl: fix cursor position with non-zero hotspot

Merge branch 'parisc-4.6-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux

Pull parisc ftrace fixes from Helge Deller:
"This is (most likely) the last pull request for v4.6 for the parisc
architecture.

It fixes the FTRACE feature for parisc, which is horribly broken since
quite some time and doesn't even compile. This patch just fixes the
bare minimum (it actually removes more lines than it adds), so that
the function tracer works again on 32- and 64bit kernels.

I've queued up additional patches on top of this patch which e.g. add
the syscall tracer, but those have to wait for the merge window for
v4.7."

* 'parisc-4.6-4' of git://git.kernel.org/pub/scm/linux/kernel/git/deller/parisc-linux:
parisc: Fix ftrace function tracer

cpsw: Prevent NUll pointer dereference with two PHYs

Adding a 2nd PHY to cpsw results in a NULL pointer dereference
as below. Fix by maintaining a reference to each PHY node in slave
struct instead of a single reference in the priv struct which was
overwritten by the 2nd PHY.

[ 17.870933] Unable to handle kernel NULL pointer dereference at virtual address 00000180
[ 17.879557] pgd = dc8bc000
[ 17.882514] [00000180] *pgd=9c882831, *pte=00000000, *ppte=00000000
[ 17.889213] Internal error: Oops: 17 [#1] ARM
[ 17.893838] Modules linked in:
[ 17.897102] CPU: 0 PID: 1657 Comm: connmand Not tainted 4.5.0-ge463dfb-dirty #11
[ 17.904947] Hardware name: Cambrionix whippet
[ 17.909576] task: dc859240 ti: dc968000 task.ti: dc968000
[ 17.915339] PC is at phy_attached_print+0x18/0x8c
[ 17.920339] LR is at phy_attached_info+0x14/0x18
[ 17.925247] pc : [<c042baec>] lr : [<c042bb74>] psr: 600f0113
[ 17.925247] sp : dc969cf8 ip : dc969d28 fp : dc969d18
[ 17.937425] r10: dda7a400 r9 : 00000000 r8 : 00000000
[ 17.942971] r7 : 00000001 r6 : ddb00480 r5 : ddb8cb34 r4 : 00000000
[ 17.949898] r3 : c0954cc0 r2 : c09562b0 r1 : 00000000 r0 : 00000000
[ 17.956829] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 17.964401] Control: 10c5387d Table: 9c8bc019 DAC: 00000051
[ 17.970500] Process connmand (pid: 1657, stack limit = 0xdc968210)
[ 17.977059] Stack: (0xdc969cf8 to 0xdc96a000)
[ 17.981692] 9ce0: dc969d28 dc969d08
[ 17.990386] 9d00: c038f9bc c038f6b4 ddb00480 dc969d34 dc969d28 c042bb74 c042bae4 00000000
[ 17.999080] 9d20: c09562b0 c0954cc0 dc969d5c dc969d38 c043ebfc c042bb6c 00000007 00000003
[ 18.007773] 9d40: ddb00000 ddb8cb58 ddb00480 00000001 dc969dec dc969d60 c0441614 c043ea68
[ 18.016465] 9d60: 00000000 00000003 00000000 fffffff4 dc969df4 0000000d 00000000 00000000
[ 18.025159] 9d80: dc969db4 dc969d90 c005dc08 c05839e0 dc969df4 0000000d ddb00000 00001002
[ 18.033851] 9da0: 00000000 00000000 dc969dcc dc969db8 c005ddf4 c005dbc8 00000000 00000118
[ 18.042544] 9dc0: dc969dec dc969dd0 ddb00000 c06db27c ffff9003 00001002 00000000 00000000
[ 18.051237] 9de0: dc969e0c dc969df0 c057c88c c04410dc dc969e0c ddb00000 ddb00000 00000001
[ 18.059930] 9e00: dc969e34 dc969e10 c057cb44 c057c7d8 ddb00000 ddb00138 00001002 beaeda20
[ 18.068622] 9e20: 00000000 00000000 dc969e5c dc969e38 c057cc28 c057cac0 00000000 dc969e80
[ 18.077315] 9e40: dda7a40c beaeda20 00000000 00000000 dc969ecc dc969e60 c05e36d0 c057cc14
[ 18.086007] 9e60: dc969e84 00000051 beaeda20 00000000 dda7a40c 00000014 ddb00000 00008914
[ 18.094699] 9e80: 30687465 00000000 00000000 00000000 00009003 00000000 00000000 00000000
[ 18.103391] 9ea0: 00001002 00008914 dd257ae0 beaeda20 c098a428 beaeda20 00000011 00000000
[ 18.112084] 9ec0: dc969edc dc969ed0 c05e4e54 c05e3030 dc969efc dc969ee0 c055f5ac c05e4cc4
[ 18.120777] 9ee0: beaeda20 dd257ae0 dc8ab4c0 00008914 dc969f7c dc969f00 c010b388 c055f45c
[ 18.129471] 9f00: c071ca40 dd257ac0 c00165e8 dc968000 dc969f3c dc969f20 dc969f64 dc969f28
[ 18.138164] 9f20: c0115708 c0683ec8 dd257ac0 dd257ac0 dc969f74 dc969f40 c055f350 c00fc66c
[ 18.146857] 9f40: dd82e4d0 00000011 00000000 00080000 dd257ac0 00000000 dc8ab4c0 dc8ab4c0
[ 18.155550] 9f60: 00008914 beaeda20 00000011 00000000 dc969fa4 dc969f80 c010bc34 c010b2fc
[ 18.164242] 9f80: 00000000 00000011 00000002 00000036 c00165e8 dc968000 00000000 dc969fa8
[ 18.172935] 9fa0: c00163e0 c010bbcc 00000000 00000011 00000011 00008914 beaeda20 00009003
[ 18.181628] 9fc0: 00000000 00000011 00000002 00000036 00081018 00000001 00000000 beaedc10
[ 18.190320] 9fe0: 00083188 beaeda1c 00043a5d b6d29c0c 600b0010 00000011 00000000 00000000
[ 18.198989] Backtrace:
[ 18.201621] [<c042bad8>] (phy_attached_print) from [<c042bb74>] (phy_attached_info+0x14/0x18)
[ 18.210664] r3:c0954cc0 r2:c09562b0 r1:00000000
[ 18.215588] r4:ddb00480
[ 18.218322] [<c042bb60>] (phy_attached_info) from [<c043ebfc>] (cpsw_slave_open+0x1a0/0x280)
[ 18.227293] [<c043ea5c>] (cpsw_slave_open) from [<c0441614>] (cpsw_ndo_open+0x544/0x674)
[ 18.235874] r7:00000001 r6:ddb00480 r5:ddb8cb58 r4:ddb00000
[ 18.241944] [<c04410d0>] (cpsw_ndo_open) from [<c057c88c>] (__dev_open+0xc0/0x128)
[ 18.249972] r9:00000000 r8:00000000 r7:00001002 r6:ffff9003 r5:c06db27c r4:ddb00000
[ 18.258255] [<c057c7cc>] (__dev_open) from [<c057cb44>] (__dev_change_flags+0x90/0x154)
[ 18.266745] r5:00000001 r4:ddb00000
[ 18.270575] [<c057cab4>] (__dev_change_flags) from [<c057cc28>] (dev_change_flags+0x20/0x50)
[ 18.279523] r9:00000000 r8:00000000 r7:beaeda20 r6:00001002 r5:ddb00138 r4:ddb00000
[ 18.287811] [<c057cc08>] (dev_change_flags) from [<c05e36d0>] (devinet_ioctl+0x6ac/0x76c)
[ 18.296483] r9:00000000 r8:00000000 r7:beaeda20 r6:dda7a40c r5:dc969e80 r4:00000000
[ 18.304762] [<c05e3024>] (devinet_ioctl) from [<c05e4e54>] (inet_ioctl+0x19c/0x1c8)
[ 18.312882] r10:00000000 r9:00000011 r8:beaeda20 r7:c098a428 r6:beaeda20 r5:dd257ae0
[ 18.321235] r4:00008914
[ 18.323956] [<c05e4cb8>] (inet_ioctl) from [<c055f5ac>] (sock_ioctl+0x15c/0x2d8)
[ 18.331829] [<c055f450>] (sock_ioctl) from [<c010b388>] (do_vfs_ioctl+0x98/0x8d0)
[ 18.339765] r7:00008914 r6:dc8ab4c0 r5:dd257ae0 r4:beaeda20
[ 18.345822] [<c010b2f0>] (do_vfs_ioctl) from [<c010bc34>] (SyS_ioctl+0x74/0x84)
[ 18.353573] r10:00000000 r9:00000011 r8:beaeda20 r7:00008914 r6:dc8ab4c0 r5:dc8ab4c0
[ 18.361924] r4:00000000
[ 18.364653] [<c010bbc0>] (SyS_ioctl) from [<c00163e0>] (ret_fast_syscall+0x0/0x3c)
[ 18.372682] r9:dc968000 r8:c00165e8 r7:00000036 r6:00000002 r5:00000011 r4:00000000
[ 18.380960] Code: e92dd810 e24cb010 e24dd010 e59b4004 (e5902180)
[ 18.387580] ---[ end trace c80529466223f3f3 ]---

Signed-off-by: Andrew Goodbody <andrew.goodbody@cambrionix.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

libnvdimm, pmem: clarify the write+clear_poison+write flow

The ACPI specification does not specify the state of data after a clear
poison operation. Potential future libnvdimm bus implementations for
other architectures also might not specify or disagree on the state of
data after clear poison. Clarify why we write twice.

Reported-by: Jeff Moyer <jmoyer@redhat.com>
Reported-by: Vishal Verma <vishal.l.verma@intel.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
Signed-off-by: Ross Zwisler <ross.zwisler@linux.intel.com>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
Reviewed-by: Vishal Verma <vishal.l.verma@intel.com>

cxgb4: Set VPD size so we can read both VPD structures

Chelsio adapters have two VPD structures stored in the VPD:

- offset 0x000: an abbreviated VPD, and
- offset 0x400: the complete VPD.

After 104daa71b396 ("PCI: Determine actual VPD size on first access"), the
PCI core computes the valid VPD size by parsing the VPD starting at offset
0x0. That size only includes the abbreviated VPD structure, so reads of
the complete VPD at 0x400 fail.

Explicitly set the VPD size with pci_set_vpd_size() so the driver can read
both VPD structures.

[bhelgaas: changelog, split patches, rename to pci_set_vpd_size() and
return int (not ssize_t)]
Fixes: 104daa71b396 ("PCI: Determine actual VPD size on first access")
Tested-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

PCI: Add pci_set_vpd_size() to set VPD size

After 104daa71b396 ("PCI: Determine actual VPD size on first access"), the
PCI core computes the valid VPD size by parsing the VPD starting at offset
0x0. We don't attempt to read past that valid size because that causes
some devices to crash.

However, some devices do have data past that valid size. For example,
Chelsio adapters contain two VPD structures, and the driver needs both of
them.

Add pci_set_vpd_size(). If a driver knows it is safe to read past the end
of the VPD data structure at offset 0, it can use pci_set_vpd_size() to
allow access to as much data as it needs.

[bhelgaas: changelog, split patches, rename to pci_set_vpd_size() and
return int (not ssize_t)]
Fixes: 104daa71b396 ("PCI: Determine actual VPD size on first access")
Tested-by: Steve Wise <swise@opengridcomputing.com>
Signed-off-by: Casey Leedom <leedom@chelsio.com>
Signed-off-by: Hariprasad Shenai <hariprasad@chelsio.com>
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>

s390: add CPU_BIG_ENDIAN config option

Make sure that s390 appears to be a big endian machine by defining
this config option.

Without this s390 appears to be little endian as seen by e.g. the
recordmount script: "perl ./scripts/recordmcount.pl "s390" "little"
"64""
This has no practical impact within the script since the endian
variable is only evaluated for mips. However there are already a
couple of common code places which evaluate this config option. None
of them is relevant for s390 currently though.

To avoid any issues in the future (and fix the recordmcount oddity)
add the new config option.

Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

s390/spinlock: avoid yield to non existent cpu

arch_spin_lock_wait_flags() checks if a spinlock is not held before
trying a compare and swap instruction. If the lock is unlocked it
tries the compare and swap instruction, however if a different cpu
grabbed the lock in the meantime the instruction will fail as
expected.

Subsequently the arch_spin_lock_wait_flags() incorrectly tries to
figure out if the cpu that holds the lock is running. However it is
using the wrong cpu number for this (-1) and then will also yield the
current cpu to the wrong cpu.

Fix this by adding a missing continue statement.

Fixes: 470ada6b1a1d ("s390/spinlock: refactor arch_spin_lock_wait[_flags]")
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Acked-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

s390/dcssblk: fix possible deadlock in remove vs. per-device attributes

dcssblk_remove_store() holds the dcssblk_devices_sem semaphore while
calling device_unregister(), which in turn tries to acquire the kernfs
kn->dev_map rwsem for the device sysfs subtree. The same rwsem is also
acquired when using the per-device sysfs attributes in the device sub-tree,
and the attribute handlers then also acquire the dcssblk_devices_sem.

This can lead to a deadlock when removing a DCSS while concurrently
reading from / writing to one of its sysfs attributes. The following
lockdep warning hinted towards the issue (CPU0 = dcssblk_remove_store,
CPU1 = dcssblk_shared_store):

[ 76.496047] Possible unsafe locking scenario:

[ 76.496054] CPU0 CPU1
[ 76.496059] ---- ----
[ 76.496087] lock(&dcssblk_devices_sem);
[ 76.496090] lock(s_active#175);
[ 76.496106] lock(&dcssblk_devices_sem);
[ 76.496110] lock(s_active#175);
[ 76.496115]
*** DEADLOCK ***

Fix this by releasing the dcssblk_devices_sem semaphore, which only
protects internal DCSS data, before calling device_unregister().

Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

thinkpad_acpi: Silence an uninitialized variable warning

If fan_get_status() fails then "s" is not initialized. Tweak the error
handling a bit to silence this warning.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>

intel_telemetry_pltdrv: Silence an uninitialized variable warning

Presumably "pss_period" and "ioss_period" can't both be zero, but this
function is never called so we can't infer that using static analysis
alone.

Silence the warning by setting "ret" to zero.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>

hp_accel: Silence an uninitialized variable warning

If acpi_evaluate_integer() fails then "lret" isn't initialized. I've
tweaked the error handling to avoid this issue.

Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>

block: loop: fix filesystem corruption in case of aio/dio

Starting from commit e36f620428(block: split bios to max possible length),
block core starts to split bio in the middle of bvec.

Unfortunately loop dio/aio doesn't consider this situation, and
always treat 'iter.iov_offset' as zero. Then filesystem corruption
is observed.

This patch figures out the offset of the base bvevc via
'bio->bi_iter.bi_bvec_done' and fixes the issue by passing the offset
to iov iterator.

Fixes: e36f6204288088f (block: split bios to max possible length)
Cc: Keith Busch <keith.busch@intel.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: stable@vger.kernel.org (4.5)
Signed-off-by: Ming Lei <ming.lei@canonical.com>
Signed-off-by: Jens Axboe <axboe@fb.com>

crypto: ccp - Prevent information leakage on export

Prevent information from leaking to userspace by doing a memset to 0 of
the export state structure before setting the structure values and copying
it. This prevents un-initialized padding areas from being copied into the
export area.

Cc: <stable@vger.kernel.org> # 3.14.x-
Reported-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: Tom Lendacky <thomas.lendacky@amd.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

crypto: sha1-mb - use corrcet pointer while completing jobs

In sha_complete_job, incorrect mcryptd_hash_request_ctx pointer is used
when check and complete other jobs. If the memory of first completed req
is freed, while still completing other jobs in the func, kernel will
crash since NULL pointer is assigned to RIP.

Cc: <stable@vger.kernel.org>
Signed-off-by: Xiaodong Liu <xiaodong.liu@intel.com>
Acked-by: Tim Chen <tim.c.chen@linux.intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

crypto: rsa-pkcs1pad - fix dst len

The output buffer length has to be at least as big as the key_size.
It is then updated to the actual output size by the implementation.

Cc: <stable@vger.kernel.org>
Signed-off-by: Tadeusz Struk <tadeusz.struk@intel.com>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>

objtool: Add workaround for GCC switch jump table bug

GCC has a rare quirk, currently only seen in three driver functions in
the kernel, and only with certain obscure non-distro configs, which can
cause objtool to produce "unreachable instruction" false positive
warnings.

As part of an optimization, GCC makes a copy of an existing switch jump
table, modifies it, and then hard-codes the jump (albeit with an
indirect jump) to use a single entry in the table. The rest of the jump
table and some of its jump targets remain as dead code.

In such a case we can just crudely ignore all unreachable instruction
warnings for the entire object file. Ideally we would just ignore them
for the function, but that would require redesigning the code quite a
bit. And honestly that's just not worth doing: unreachable instruction
warnings are of questionable value anyway, and this is a very rare
issue.

kbuild reports:

https://lkml.kernel.org/r/201603231906.LWcVUpxm%25fengguang.wu@intel.com
https://lkml.kernel.org/r/201603271114.K9i45biy%25fengguang.wu@intel.com
https://lkml.kernel.org/r/201603291058.zuJ6ben1%25fengguang.wu@intel.com

GCC bug:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70604

Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/700fa029bbb0feff34f03ffc69d666a3c3b57a61.1460663532.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>

pinctrl: single: Fix pcs_parse_bits_in_pinctrl_entry to use __ffs than ffs

pcs_parse_bits_in_pinctrl_entry uses ffs which gives bit indices
ranging from 1 to MAX. This leads to a corner case where we try to request
the pin number = MAX and fails.

bit_pos value is being calculted using ffs. pin_num_from_lsb uses
bit_pos value. pins array is populated with:

pin + pin_num_from_lsb.

The above is 1 more than usual bit indices as bit_pos uses ffs to compute
first set bit. Hence the last of the pins array is populated with the MAX
value and not MAX - 1 which causes error when we call pin_request.

mask_pos is rightly calculated as ((pcs->fmask) << (bit_pos - 1))
Consequently val_pos and submask are correct.

Hence use __ffs which gives (ffs(x) - 1) as the first bit set.

fixes: 4e7e8017a8 ("pinctrl: pinctrl-single: enhance to configure multiple pins of different modules")
Signed-off-by: Keerthy <j-keerthy@ti.com>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

ARM: 8551/2: DMA: Fix kzalloc flags in __dma_alloc

Commit 19e6e5e5392b ("ARM: 8547/1: dma-mapping: store buffer
information") allocates a structure meant for internal buffer management
with the GFP flags of the buffer itself. This can trigger the following
safeguard in the slab/slub allocator:

if (unlikely(flags & GFP_SLAB_BUG_MASK)) {
pr_emerg("gfp: %un", flags & GFP_SLAB_BUG_MASK);
BUG();
}

Fix this by filtering the flags that make the slab allocator unhappy.

Signed-off-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Rabin Vincent <rabin@rab.in>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>

pinctrl: mediatek: correct debounce time unit in mtk_gpio_set_debounce

The debounce time unit for gpio_chip.set_debounce is us but
mtk_gpio_set_debounce regard it as ms.
Fix this by correct debounce time array dbnc_arr so it can find correct
debounce setting. Debounce time for first debounce setting is 500us,
correct this as well.

While I'm at it, also change the debounce time array name to
"debounce_time" for readability.

Cc: stable@vger.kernel.org
Signed-off-by: Yingjoe Chen <yingjoe.chen@mediatek.com>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Acked-by: Hongzhou Yang <hongzhou.yang@mediatek.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

hp_accel: Add support for HP ProBook 440 G3

HP ProBook 440 G3 laptop needs a non-standard mapping (x_inverted_usd).

Signed-off-by: Martin Vajnar <martin.vajnar@gmail.com>
Acked-by: Éric Piel <eric.piel@tremplin-utc.net>
Signed-off-by: Darren Hart <dvhart@linux.intel.com>