KEYS: Fix short sprintf buffer in /proc/keys show function

This fixes CVE-2016-7042.

Fix a short sprintf buffer in proc_keys_show().  If the gcc stack protector
is turned on, this can cause a panic due to stack corruption.

The problem is that xbuf[] is not big enough to hold a 64-bit timeout
rendered as weeks:

(gdb) p 0xffffffffffffffffULL/(60*60*24*7)
$2 = 30500568904943

That's 14 chars plus NUL, not 11 chars plus NUL.

Expand the buffer to 16 chars.

I think the unpatched code apparently works if the stack-protector is not
enabled because on a 32-bit machine the buffer won't be overflowed and on a
64-bit machine there's a 64-bit aligned pointer at one side and an int that
isn't checked again on the other side.

The panic incurred looks something like:

Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: ffffffff81352ebe
CPU: 0 PID: 1692 Comm: reproducer Not tainted 4.7.2-201.fc24.x86_64 #1
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
 0000000000000086 00000000fbbd2679 ffff8800a044bc00 ffffffff813d941f
 ffffffff81a28d58 ffff8800a044bc98 ffff8800a044bc88 ffffffff811b2cb6
 ffff880000000010 ffff8800a044bc98 ffff8800a044bc30 00000000fbbd2679
Call Trace:
 [<ffffffff813d941f>] dump_stack+0x63/0x84
 [<ffffffff811b2cb6>] panic+0xde/0x22a
 [<ffffffff81352ebe>] ? proc_keys_show+0x3ce/0x3d0
 [<ffffffff8109f7f9>] __stack_chk_fail+0x19/0x30
 [<ffffffff81352ebe>] proc_keys_show+0x3ce/0x3d0
 [<ffffffff81350410>] ? key_validate+0x50/0x50
 [<ffffffff8134db30>] ? key_default_cmp+0x20/0x20
 [<ffffffff8126b31c>] seq_read+0x2cc/0x390
 [<ffffffff812b6b12>] proc_reg_read+0x42/0x70
 [<ffffffff81244fc7>] __vfs_read+0x37/0x150
 [<ffffffff81357020>] ? security_file_permission+0xa0/0xc0
 [<ffffffff81246156>] vfs_read+0x96/0x130
 [<ffffffff81247635>] SyS_read+0x55/0xc0
 [<ffffffff817eb872>] entry_SYSCALL_64_fastpath+0x1a/0xa4

Reported-by: Ondrej Kozina <okozina@redhat.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Ondrej Kozina <okozina@redhat.com>
cc: stable@vger.kernel.org
Signed-off-by: James Morris <james.l.morris@oracle.com>

arm64: mm: fix __page_to_voff definition

Fix parameter name for __page_to_voff, to match its definition.
At present, we don't see any issue, as page_to_virt's caller
declares 'page'.

Fixes: 9f2875912dac ("arm64: mm: restrict virt_to_page() to the linear mapping")
Acked-by: Mark Rutland <mark.rutland@arm.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Neeraj Upadhyay <neeraju@codeaurora.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>

arm64/numa: fix incorrect log for memory-less node

When booting on NUMA system with memory-less node (no
memory dimm on this memory controller), the print
for setup_node_data() is incorrect:

NUMA: Initmem setup node 2 [mem 0x00000000-0xffffffffffffffff]

It can be fixed by printing [mem 0x00000000-0x00000000] when
end_pfn is 0, but print <memory-less node> will be more useful.

Fixes: 1a2db300348b ("arm64, numa: Add NUMA support for arm64 platforms.")
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Ganapatrao Kulkarni <gkulkarni@caviumnetworks.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Yisheng Xie <xieyisheng1@huawei.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

arm64/numa: fix pcpu_cpu_distance() to get correct CPU proximity

The pcpu_build_alloc_info() function group CPUs according to their
proximity, by call callback function @cpu_distance_fn from different
ARCHs.

For arm64 the callback of @cpu_distance_fn is
    pcpu_cpu_distance(from, to)
        -> node_distance(from, to)
The @from and @to for function node_distance() should be nid.

However, pcpu_cpu_distance() in arch/arm64/mm/numa.c just past the
cpu id for @from and @to, and didn't convert to numa node id.

For this incorrect cpu proximity get from ARCH, it may cause each CPU
in one group and make group_cnt out of bound:

setup_per_cpu_areas()
pcpu_embed_first_chunk()
pcpu_build_alloc_info()
in pcpu_build_alloc_info, since cpu_distance_fn will return
REMOTE_DISTANCE if we pass cpu ids (0,1,2...), so
cpu_distance_fn(cpu, tcpu) > LOCAL_DISTANCE will wrongly be ture.

This may results in triggering the BUG_ON(unit != nr_units) later:

[    0.000000] kernel BUG at mm/percpu.c:1916!
[    0.000000] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
[    0.000000] Modules linked in:
[    0.000000] CPU: 0 PID: 0 Comm: swapper Not tainted 4.9.0-rc1-00003-g14155ca-dirty #26
[    0.000000] Hardware name: Hisilicon Hi1616 Evaluation Board (DT)
[    0.000000] task: ffff000008d6e900 task.stack: ffff000008d60000
[    0.000000] PC is at pcpu_embed_first_chunk+0x420/0x704
[    0.000000] LR is at pcpu_embed_first_chunk+0x3bc/0x704
[    0.000000] pc : [<ffff000008c754f4>] lr : [<ffff000008c75490>] pstate: 800000c5
[    0.000000] sp : ffff000008d63eb0
[    0.000000] x29: ffff000008d63eb0 [    0.000000] x28: 0000000000000000
[    0.000000] x27: 0000000000000040 [    0.000000] x26: ffff8413fbfcef00
[    0.000000] x25: 0000000000000042 [    0.000000] x24: 0000000000000042
[    0.000000] x23: 0000000000001000 [    0.000000] x22: 0000000000000046
[    0.000000] x21: 0000000000000001 [    0.000000] x20: ffff000008cb3bc8
[    0.000000] x19: ffff8413fbfcf570 [    0.000000] x18: 0000000000000000
[    0.000000] x17: ffff000008e49ae0 [    0.000000] x16: 0000000000000003
[    0.000000] x15: 000000000000001e [    0.000000] x14: 0000000000000004
[    0.000000] x13: 0000000000000000 [    0.000000] x12: 000000000000006f
[    0.000000] x11: 00000413fbffff00 [    0.000000] x10: 0000000000000004
[    0.000000] x9 : 0000000000000000 [    0.000000] x8 : 0000000000000001
[    0.000000] x7 : ffff8413fbfcf63c [    0.000000] x6 : ffff000008d65d28
[    0.000000] x5 : ffff000008d65e50 [    0.000000] x4 : 0000000000000000
[    0.000000] x3 : ffff000008cb3cc8 [    0.000000] x2 : 0000000000000040
[    0.000000] x1 : 0000000000000040 [    0.000000] x0 : 0000000000000000
[...]
[    0.000000] Call trace:
[    0.000000] Exception stack(0xffff000008d63ce0 to 0xffff000008d63e10)
[    0.000000] 3ce0: ffff8413fbfcf570 0001000000000000 ffff000008d63eb0 ffff000008c754f4
[    0.000000] 3d00: ffff000008d63d50 ffff0000081af210 00000413fbfff010 0000000000001000
[    0.000000] 3d20: ffff000008d63d50 ffff0000081af220 00000413fbfff010 0000000000001000
[    0.000000] 3d40: 00000413fbfcef00 0000000000000004 ffff000008d63db0 ffff0000081af390
[    0.000000] 3d60: 00000413fbfcef00 0000000000001000 0000000000000000 0000000000001000
[    0.000000] 3d80: 0000000000000000 0000000000000040 0000000000000040 ffff000008cb3cc8
[    0.000000] 3da0: 0000000000000000 ffff000008d65e50 ffff000008d65d28 ffff8413fbfcf63c
[    0.000000] 3dc0: 0000000000000001 0000000000000000 0000000000000004 00000413fbffff00
[    0.000000] 3de0: 000000000000006f 0000000000000000 0000000000000004 000000000000001e
[    0.000000] 3e00: 0000000000000003 ffff000008e49ae0
[    0.000000] [<ffff000008c754f4>] pcpu_embed_first_chunk+0x420/0x704
[    0.000000] [<ffff000008c6658c>] setup_per_cpu_areas+0x38/0xc8
[    0.000000] [<ffff000008c608d8>] start_kernel+0x10c/0x390
[    0.000000] [<ffff000008c601d8>] __primary_switched+0x5c/0x64
[    0.000000] Code: b8018660 17ffffd7 6b16037f 54000080 (d4210000)
[    0.000000] ---[ end trace 0000000000000000 ]---
[    0.000000] Kernel panic - not syncing: Attempted to kill the idle task!

Fix by getting cpu's node id with early_cpu_to_node() then pass it
to node_distance() as the original intention.

Fixes: 7af3a0a99252 ("arm64/numa: support HAVE_SETUP_PER_CPU_AREA")
Signed-off-by: Yisheng Xie <xieyisheng1@huawei.com>
Signed-off-by: Hanjun Guo <hanjun.guo@linaro.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>
Cc: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
Cc: Will Deacon <will.deacon@arm.com>
Cc: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Will Deacon <will.deacon@arm.com>

block: flush: fix IO hang in case of flood fua req

This patch fixes one issue reported by Kent, which can
be triggered in bcachefs over sata disk. Actually it
is a generic issue in block flush vs. blk-tag.

Cc: Christoph Hellwig <hch@infradead.org>
Reported-by: Kent Overstreet <kent.overstreet@gmail.com>
Signed-off-by: Ming Lei <tom.leiming@gmail.com>
Signed-off-by: Jens Axboe <axboe@fb.com>

x86: Fix export for mcount and __fentry__

Commit 784d5699eddc5 ("x86: move exports to actual definitions") removed the
EXPORT_SYMBOL(__fentry__) and EXPORT_SYMBOL(mcount) from x8664_ksyms_64.c,
and added EXPORT_SYMBOL(function_hook) in mcount_64.S instead. The problem
is that function_hook isn't a function at all, but a macro that is defined
as either mcount or __fentry__ depending on the support from gcc.

Originally, I thought this was a macro issue, like what __stringify()
is used for. But the problem is a bit deeper. The Makefile.build has
some magic that does post processing of files to create the CRC
bindings. It does some searches for EXPORT_SYMBOL() and because it
finds a macro name and not the actual functions, this causes
function_hook not to be converted into mcount or __fentry__ and they
are missed.

Instead of adding more magic to Makefile.build, just add
EXPORT_SYMBOL() for mcount and __fentry__ where the ifdef is used.
Since this is assembly and not C, it doesn't require being set after
the function is defined.

Signed-off-by: Steven Rostedt <rostedt@goodmis.org>
Tested-by: Borislav Petkov <bp@alien8.de>
Cc: Gabriel C <nix.or.die@gmail.com>
Cc: Nicholas Piggin <npiggin@gmail.com>
Cc: Al Viro <viro@ZenIV.linux.org.uk>
Link: http://lkml.kernel.org/r/20161024150148.4f9d90e4@gandalf.local.home
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

doc: Add missing parameter for msi_setup

commit 92ca8d20dee2 ("genirq/msi: Switch to new irq spreading")
introduced new parameter to msi_init_setup and but did not update
docbook comments. Fixes 'make htmldocs' warning.

Signed-off-by: Stephen Hemminger <sthemmin@microsoft.com>
Cc: bhelgaas@google.com
Cc: linux-pci@vger.kernel.org
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

Merge tag 'usb-ci-v4.9-rc2' of git://git./linux/kernel/git/peter.chen/usb into usb-linus

Peter writes:

Fix for kernel panic during the system reboot for some boards

drm/drivers: add support for using the arch wc mapping API.

This fixes a regression in all these drivers since the cache
mode tracking was fixed for mixed mappings. It uses the new
arch API to add the VRAM range to the PAT mapping tracking
tables.

Fixes: 87744ab3832 (mm: fix cache mode tracking in vm_insert_mixed())
Reviewed-by: Christian König <christian.koenig@amd.com>.
Signed-off-by: Dave Airlie <airlied@redhat.com>

x86/io: add interface to reserve io memtype for a resource range. (v1.1)

A recent change to the mm code in:
87744ab3832b mm: fix cache mode tracking in vm_insert_mixed()

started enforcing checking the memory type against the registered list for
amixed pfn insertion mappings. It happens that the drm drivers for a number
of gpus relied on this being broken. Currently the driver only inserted
VRAM mappings into the tracking table when they came from the kernel,
and userspace mappings never landed in the table. This led to a regression
where all the mapping end up as UC instead of WC now.

I've considered a number of solutions but since this needs to be fixed
in fixes and not next, and some of the solutions were going to introduce
overhead that hadn't been there before I didn't consider them viable at
this stage. These mainly concerned hooking into the TTM io reserve APIs,
but these API have a bunch of fast paths I didn't want to unwind to add
this to.

The solution I've decided on is to add a new API like the arch_phys_wc
APIs (these would have worked but wc_del didn't take a range), and
use them from the drivers to add a WC compatible mapping to the table
for all VRAM on those GPUs. This means we can then create userspace
mapping that won't get degraded to UC.

v1.1: use CONFIG_X86_PAT + add some comments in io.h

Cc: Toshi Kani <toshi.kani@hp.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: x86@kernel.org
Cc: mcgrof@suse.com
Cc: Dan Williams <dan.j.williams@intel.com>
Acked-by: Ingo Molnar <mingo@kernel.org>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Dave Airlie <airlied@redhat.com>

MAINTAINERS: Begin module maintainer transition

Being a Linux kernel maintainer has been my proudest professional
accomplishment, spanning the last 19 years.  But now we have a surfeit
of excellent hackers, and I can hand this over without regret.

I'll still be around as co-maintainer for another cycle, but Jessica
is now the one to convince if you want your patches applied.  She
rocks, and is far more timely than me too!

Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Acked-by: Jessica Yu <jeyu@redhat.com>

ahci: fix the single MSI-X case in ahci_init_one

We need to make sure hpriv->irq is set properly if we don't use per-port
vectors, so switch from blindly assigning pdev->irq to using
pci_irq_vector, which handles all interrupt types correctly.

Signed-off-by: Christoph Hellwig <hch@lst.de>
Reported-by: Robert Richter <robert.richter@cavium.com>
Tested-by: Robert Richter <robert.richter@cavium.com>
Tested-by: David Daney <ddaney.cavm@gmail.com>
Fixes: 0b9e2988ab22 ("ahci: use pci_alloc_irq_vectors")
Signed-off-by: Tejun Heo <tj@kernel.org>

timers: Prevent base clock corruption when forwarding

When a timer is enqueued we try to forward the timer base clock. This
mechanism has two issues:

1) Forwarding a remote base unlocked

The forwarding function is called from get_target_base() with the current
timer base lock held. But if the new target base is a different base than
the current base (can happen with NOHZ, sigh!) then the forwarding is done
on an unlocked base. This can lead to corruption of base->clk.

Solution is simple: Invoke the forwarding after the target base is locked.

2) Possible corruption due to jiffies advancing

This is similar to the issue in get_net_timer_interrupt() which was fixed
in the previous patch. jiffies can advance between check and assignement
and therefore advancing base->clk beyond the next expiry value.

So we need to read jiffies into a local variable once and do the checks and
assignment with the local copy.

Fixes: a683f390b93f("timers: Forward the wheel clock whenever possible")
Reported-by: Ashton Holmes <scoopta@gmail.com>
Reported-by: Michael Thayer <michael.thayer@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Michal Necasek <michal.necasek@oracle.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: knut.osmundsen@oracle.com
Cc: stable@vger.kernel.org
Cc: stern@rowland.harvard.edu
Cc: rt@linutronix.de
Link: http://lkml.kernel.org/r/20161022110552.253640125@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

timers: Prevent base clock rewind when forwarding clock

Ashton and Michael reported, that kernel versions 4.8 and later suffer from
USB timeouts which are caused by the timer wheel rework.

This is caused by a bug in the base clock forwarding mechanism, which leads
to timers expiring early. The scenario which leads to this is:

run_timers()
  while (jiffies >= base->clk) {
    collect_expired_timers();
    base->clk++;
    expire_timers();
  }

So base->clk = jiffies + 1. Now the cpu goes idle:

idle()
  get_next_timer_interrupt()
    nextevt = __next_time_interrupt();
    if (time_after(nextevt, base->clk))
        base->clk = jiffies;

jiffies has not advanced since run_timers(), so this assignment effectively
decrements base->clk by one.

base->clk is the index into the timer wheel arrays. So let's assume the
following state after the base->clk increment in run_timers():

 jiffies = 0
 base->clk = 1

A timer gets enqueued with an expiry delta of 63 ticks (which is the case
with the USB timeout and HZ=250) so the resulting bucket index is:

  base->clk + delta = 1 + 63 = 64

The timer goes into the first wheel level. The array size is 64 so it ends
up in bucket 0, which is correct as it takes 63 ticks to advance base->clk
to index into bucket 0 again.

If the cpu goes idle before jiffies advance, then the bug in the forwarding
mechanism sets base->clk back to 0, so the next invocation of run_timers()
at the next tick will index into bucket 0 and therefore expire the timer 62
ticks too early.

Instead of blindly setting base->clk to jiffies we must make the forwarding
conditional on jiffies > base->clk, but we cannot use jiffies for this as
we might run into the following issue:

  if (time_after(jiffies, base->clk) {
    if (time_after(nextevt, base->clk))
       base->clk = jiffies;

jiffies can increment between the check and the assigment far enough to
advance beyond nextevt. So we need to use a stable value for checking.

get_next_timer_interrupt() has the basej argument which is the jiffies
value snapshot taken in the calling code. So we can just that.

Thanks to Ashton for bisecting and providing trace data!

Fixes: a683f390b93f ("timers: Forward the wheel clock whenever possible")
Reported-by: Ashton Holmes <scoopta@gmail.com>
Reported-by: Michael Thayer <michael.thayer@oracle.com>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Michal Necasek <michal.necasek@oracle.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: knut.osmundsen@oracle.com
Cc: stable@vger.kernel.org
Cc: stern@rowland.harvard.edu
Cc: rt@linutronix.de
Link: http://lkml.kernel.org/r/20161022110552.175308322@linutronix.de
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

timers: Lock base for same bucket optimization

Linus stumbled over the unlocked modification of the timer expiry value in
mod_timer() which is an optimization for timers which stay in the same
bucket - due to the bucket granularity - despite their expiry time getting
updated.

The optimization itself still makes sense even if we take the lock, because
in case that the bucket stays the same, we avoid the pointless
queue/enqueue dance.

Make the check and the modification of timer->expires protected by the base
lock and shuffle the remaining code around so we can keep the lock held
when we actually have to requeue the timer to a different bucket.

Fixes: f00c0afdfa62 ("timers: Implement optimization for same expiry time in mod_timer()")
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1610241711220.4983@nanos
Cc: stable@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>

timers: Plug locking race vs. timer migration

Linus noticed that lock_timer_base() lacks a READ_ONCE() for accessing the
timer flags. As a consequence the compiler is allowed to reload the flags
between the initial check for TIMER_MIGRATION and the following timer base
computation and the spin lock of the base.

While this has not been observed (yet), we need to make sure that it never
happens.

Fixes: 0eeda71bc30d ("timer: Replace timer base by a cpu index")
Reported-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1610241711220.4983@nanos
Cc: stable@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>

ALSA: seq: Fix time account regression

The recent rewrite of the sequencer time accounting using timespec64
in the commit [3915bf294652: ALSA: seq_timer: use monotonic times
internally] introduced a bad regression.  Namely, the time reported
back doesn't increase but goes back and forth.

The culprit was obvious: the delta is stored to the result (cur_time =
delta), instead of adding the delta (cur_time += delta)!

Let's fix it.

Fixes: 3915bf294652 ('ALSA: seq_timer: use monotonic times internally')
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=177571
Reported-by: Yves Guillemot <yc.guillemot@wanadoo.fr>
Cc: <stable@vger.kernel.org> # v4.8+
Signed-off-by: Takashi Iwai <tiwai@suse.de>

i2c: imx: defer probe if bus recovery GPIOs are not ready

Some SoC might load the GPIO driver after the I2C driver and
using the I2C bus recovery mechanism via GPIOs. In this case
it is crucial to defer probing if the GPIO request functions
do so, otherwise the I2C driver gets loaded without recovery
mechanisms enabled.

Signed-off-by: Stefan Agner <stefan@agner.ch>
Acked-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Acked-by: Li Yang <leoyang.li@nxp.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

i2c: designware: Avoid aborted transfers with fast reacting I2C slaves

I2C DesignWare may abort transfer with arbitration lost if I2C slave pulls
SDA down quickly after falling edge of SCL. Reason for this is unknown but
after trial and error it was found this can be avoided by enabling non-zero
SDA RX hold time for the receiver.

By the specification SDA RX hold time extends incoming SDA low to high
transition by n * ic_clk cycles but only when SCL is high. However it
seems to help avoid above faulty arbitration lost error.

Bits 23:16 in IC_SDA_HOLD register define the SDA RX hold time for the
receiver. Be conservative and enable 1 ic_clk cycle long hold time in
case boot firmware hasn't set it up.

Reported-by: Jukka Laitinen <jukka.laitinen@intel.com>
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: Jukka Laitinen <jukka.laitinen@intel.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

i2c: i801: Fix I2C Block Read on 8-Series/C220 and later

Starting with the 8-Series/C220 PCH (Lynx Point), the SMBus
controller includes a SPD EEPROM protection mechanism. Once the SPD
Write Disable bit is set, only reads are allowed to slave addresses
0x50-0x57.

However the legacy implementation of I2C Block Read since the ICH5
looks like a write, and is therefore blocked by the SPD protection
mechanism. This causes the eeprom and at24 drivers to fail.

So assume that I2C Block Read is implemented as an actual read on
these chipsets. I tested it on my Q87 chipset and it seems to work
just fine.

Signed-off-by: Jean Delvare <jdelvare@suse.de>
Tested-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
[wsa: rebased to v4.9-rc2]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

i2c: xgene: Avoid dma_buffer overrun

SMBus block command uses the first byte of buffer for the data length.
The dma_buffer should be increased by 1 to avoid the overrun issue.

Reported-by: Phil Endecott <phil_gjouf_endecott@chezphil.org>
Signed-off-by: Hoan Tran <hotran@apm.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

i2c: digicolor: Fix module autoload

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

i2c: xlr: Fix module autoload for OF registration

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

i2c: xlp9xx: Fix module autoload

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

i2c: jz4780: Fix module autoload

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

i2c: allow configuration of imx driver for ColdFire architecture

The i2c controller used by Freescales iMX processors is the same
hardware module used on Freescales ColdFire family of processors.

We can use the existing i2c-imx driver on ColdFire family members.
Modify the configuration to allow it to be selected when compiling
for ColdFire targets.

Signed-off-by: Greg Ungerer <gerg@linux-m68k.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

i2c: mark device nodes only in case of successful instantiation

Instantiated I2C device nodes are marked with OF_POPULATE. This was
introduced in 4f001fd30145a6. On unloading, loaded device nodes will of
course be unmarked. The problem are nodes that fail during
initialisation: If a node fails, it won't be unloaded and hence not be
unmarked.

If a I2C driver module is unloaded and reloaded, it will skip nodes that
failed before.

Skip device nodes that are already populated and mark them only in case
of success.

Fixes: 4f001fd30145a6 ("i2c: Mark instantiated device nodes with OF_POPULATE")
Signed-off-by: Ralf Ramsauer <ralf@ramses-pyramidenbau.de>
Reviewed-by: Geert Uytterhoeven <geert+renesas@glider.be>
Acked-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com>
[wsa: use 14-digit commit sha]
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

x86/quirks: Hide maybe-uninitialized warning

gcc -Wmaybe-uninitialized detects that quirk_intel_brickland_xeon_ras_cap
uses uninitialized data when CONFIG_PCI is not set:

  arch/x86/kernel/quirks.c: In function ‘quirk_intel_brickland_xeon_ras_cap’:
  arch/x86/kernel/quirks.c:641:13: error: ‘capid0’ is used uninitialized in this function [-Werror=uninitialized]

However, the function is also not called in this configuration, so we
can avoid the warning by moving the existing #ifdef to cover it as well.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Bjorn Helgaas <bhelgaas@google.com>
Cc: Borislav Petkov <bp@suse.de>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Tony Luck <tony.luck@intel.com>
Cc: linux-pci@vger.kernel.org
Link: http://lkml.kernel.org/r/20161024153325.2752428-1-arnd@arndb.de
Signed-off-by: Ingo Molnar <mingo@kernel.org>

x86/build: Fix build with older GCC versions

Older GCC (observed with 4.1.x) doesn't support -Wno-override-init and
also doesn't ignore unknown -Wno-* options.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Valdis Kletnieks <valdis.kletnieks@vt.edu>
Cc: Valdis.Kletnieks@vt.edu
Fixes: 5e44258d16 "x86/build: Reduce the W=1 warnings noise when compiling x86 syscall tables"
Link: http://lkml.kernel.org/r/580E3E1C02000078001191C4@prv-mh.provo.novell.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>

x86/unwind: Fix empty stack dereference in guess unwinder

Vince Waver reported the following bug:

  WARNING: CPU: 0 PID: 21338 at arch/x86/mm/fault.c:435 vmalloc_fault+0x58/0x1f0
  CPU: 0 PID: 21338 Comm: perf_fuzzer Not tainted 4.8.0+ #37
  Hardware name: Hewlett-Packard HP Compaq Pro 6305 SFF/1850, BIOS K06 v02.57 08/16/2013
  Call Trace:
   <NMI>  ? dump_stack+0x46/0x59
   ? __warn+0xd5/0xee
   ? vmalloc_fault+0x58/0x1f0
   ? __do_page_fault+0x6d/0x48e
   ? perf_log_throttle+0xa4/0xf4
   ? trace_page_fault+0x22/0x30
   ? __unwind_start+0x28/0x42
   ? perf_callchain_kernel+0x75/0xac
   ? get_perf_callchain+0x13a/0x1f0
   ? perf_callchain+0x6a/0x6c
   ? perf_prepare_sample+0x71/0x2eb
   ? perf_event_output_forward+0x1a/0x54
   ? __default_send_IPI_shortcut+0x10/0x2d
   ? __perf_event_overflow+0xfb/0x167
   ? x86_pmu_handle_irq+0x113/0x150
   ? native_read_msr+0x6/0x34
   ? perf_event_nmi_handler+0x22/0x39
   ? perf_ibs_nmi_handler+0x4a/0x51
   ? perf_event_nmi_handler+0x22/0x39
   ? nmi_handle+0x4d/0xf0
   ? perf_ibs_handle_irq+0x3d1/0x3d1
   ? default_do_nmi+0x3c/0xd5
   ? do_nmi+0x92/0x102
   ? end_repeat_nmi+0x1a/0x1e
   ? entry_SYSCALL_64_after_swapgs+0x12/0x4a
   ? entry_SYSCALL_64_after_swapgs+0x12/0x4a
   ? entry_SYSCALL_64_after_swapgs+0x12/0x4a
   <EOE> ^A4---[ end trace 632723104d47d31a ]---
  BUG: stack guard page was hit at ffffc90008500000 (stack is ffffc900084fc000..ffffc900084fffff)
  kernel stack overflow (page fault): 0000 [#1] SMP
  ...

The NMI hit in the entry code right after setting up the stack pointer
from 'cpu_current_top_of_stack', so the kernel stack was empty.  The
'guess' version of __unwind_start() attempted to dereference the "top of
stack" pointer, which is not actually *on* the stack.

Add a check in the guess unwinder to deal with an empty stack.  (The
frame pointer unwinder already has such a check.)

Reported-by: Vince Weaver <vincent.weaver@maine.edu>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Fixes: 7c7900f89770 ("x86/unwind: Add new unwind interface and implementations")
Link: http://lkml.kernel.org/r/20161024133127.e5evgeebdbohnmpb@treble
Signed-off-by: Ingo Molnar <mingo@kernel.org>

i2c: rk3x: Give the tuning value 0 during rk3x_i2c_v0_calc_timings

We found a bug that i2c transfer sometimes failed on 3066a board with
stabel-4.8, the con register would be updated by uninitialized tuning
value, it made the i2c transfer failed.

So give the tuning value to be zero during rk3x_i2c_v0_calc_timings.

Signed-off-by: David Wu <david.wu@rock-chips.com>
Tested-by: Andy Yan <andy.yan@rock-chips.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Cc: stable@kernel.org

i2c: hix5hd2: allow build with ARCH_HISI

This driver should be buildable with ARCH_HISI,
because some of other HiSilicon SoCs also use it.

Signed-off-by: Ruqiang Ju <juruqiang@huawei.com>
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>

usb: chipidea: host: fix NULL ptr dereference during shutdown

After commit b09b5224fe86 ("usb: chipidea: implement platform shutdown
callback") and commit 43a404577a93 ("usb: chipidea: host: set host to
be null after hcd is freed") a NULL pointer dereference is caused
on i.MX23 during shutdown. So ensure that role is set to CI_ROLE_END and
we finish interrupt handling before the hcd is deallocated. This avoids
the NULL pointer dereference.

Suggested-by: Alan Stern <stern@rowland.harvard.edu>
Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com>
Fixes: b09b5224fe86 ("usb: chipidea: implement platform shutdown callback")
Signed-off-by: Peter Chen <peter.chen@nxp.com>

ALSA: hda - Fix surround output pins for ASRock B150M mobo

ASRock B150M Pro4/D3 mobo with ALC892 codec doesn't seem to provide
proper pins for the surround outputs, hence we need to specify the
pincfgs manually with a couple of other corrections.

Reported-and-tested-by: Benjamin Valentin <benpicco@googlemail.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>

Merge branch 'linus' of git://git./linux/kernel/git/herbert/crypto-2.6

Pull crypto fix from Herbert Xu:
 "This fixes a regression caused by the stack vmalloc change"

* 'linus' of git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6:
  hwrng: core - Don't use a stack buffer in add_early_randomness()

Merge tag 'clk-fixes-for-linus' of git://git./linux/kernel/git/clk/linux

Pull clk fixes from Stephen Boyd:
 "This is the first batch of clk driver fixes for this release.

  We have a handful of fixes for the uniphier clk driver that was
  introduced recently, as well as Kconfig option hiding, module
  autoloading markings, and a few fixes for clk_hw based registration
  patches that went in this merge window"

* tag 'clk-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/clk/linux:
  clk: at91: Fix a return value in case of error
  clk: uniphier: rename MIO clock to SD clock for Pro5, PXs2, LD20 SoCs
  clk: uniphier: fix memory overrun bug
  clk: hi6220: use CLK_OF_DECLARE_DRIVER for sysctrl and mediactrl clock init
  clk: mvebu: armada-37xx-periph: Fix the clock gate flag
  clk: bcm2835: Clamp the PLL's requested rate to the hardware limits.
  clk: max77686: fix number of clocks setup for clk_hw based registration
  clk: mvebu: armada-37xx-periph: Fix the clock provider registration
  clk: core: add __init decoration for CLK_OF_DECLARE_DRIVER function
  clk: mediatek: Add hardware dependency
  clk: samsung: clk-exynos-audss: Fix module autoload
  clk: uniphier: fix type of variable passed to regmap_read()
  clk: uniphier: add system clock support for sLD3 SoC

Merge tag 'gpio-v4.9-2' of git://git./linux/kernel/git/linusw/linux-gpio

Pull GPIO fixes from Linus Walleij:
 "Here is a set of GPIO fixes for the v4.9 kernel series:

   - Fix up off-by one and line offset validation, info leak to
     userspace, and reject invalid flags. Those are especially valuable
     hardening patches from Lars-Peter Clausen, all tagged for stable.

   - Fix module autoload for TS4800 and ATH79.

   - Correct the IRQ handler for MPC8xxx to use handle_level_irq() as it
     (a) reacts to edges not levels and (b) even implements .irq_ack().
     We were missing IRQs here.

   - Fix the error path for acpi_dev_gpio_irq_get()

   - Fix a memory leak in the MXS driver.

   - Fix an annoying typo in the STMPE driver.

   - Put a dependency on sysfs to the mockup driver"

* tag 'gpio-v4.9-2' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-gpio:
  gpio: mpc8xxx: Correct irq handler function
  gpio: ath79: Fix module autoload
  gpio: ts4800: Fix module autoload
  gpio: GPIO_GET_LINEEVENT_IOCTL: Reject invalid line and event flags
  gpio: GPIO_GET_LINEHANDLE_IOCTL: Reject invalid line flags
  gpio: GPIOHANDLE_GET_LINE_VALUES_IOCTL: Fix information leak
  gpio: GPIO_GET_LINEEVENT_IOCTL: Validate line offset
  gpio: GPIOHANDLE_GET_LINE_VALUES_IOCTL: Fix information leak
  gpio: GPIO_GET_LINEHANDLE_IOCTL: Validate line offset
  gpio: GPIO_GET_CHIPINFO_IOCTL: Fix information leak
  gpio: GPIO_GET_CHIPINFO_IOCTL: Fix line offset validation
  gpio / ACPI: fix returned error from acpi_dev_gpio_irq_get()
  gpio: mockup: add sysfs dependency
  gpio: stmpe: || vs && typo
  gpio: mxs: Unmap region obtained by of_iomap
  gpio/board.txt: point to gpiod_set_value

Merge tag 'for-linus-4.9-rc2-tag' of git://git./linux/kernel/git/xen/tip

Pull xen fixes from David Vrabel:

 - advertise control feature flags in xenstore

 - fix x86 build when XEN_PVHVM is disabled

* tag 'for-linus-4.9-rc2-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip:
  xenbus: check return value of xenbus_scanf()
  xenbus: prefer list_for_each()
  x86: xen: move cpu_up functions out of ifdef
  xenbus: advertise control feature flags

mm: unexport __get_user_pages()

This patch unexports the low-level __get_user_pages() function.

Recent refactoring of the get_user_pages* functions allow flags to be
passed through get_user_pages() which eliminates the need for access to
this function from its one user, kvm.

We can see that the two calls to get_user_pages() which replace
__get_user_pages() in kvm_main.c are equivalent by examining their call
stacks:

  get_user_page_nowait():
    get_user_pages(start, 1, flags, page, NULL)
    __get_user_pages_locked(current, current->mm, start, 1, page, NULL, NULL,
    false, flags | FOLL_TOUCH)
    __get_user_pages(current, current->mm, start, 1,
     flags | FOLL_TOUCH | FOLL_GET, page, NULL, NULL)

  check_user_page_hwpoison():
    get_user_pages(addr, 1, flags, NULL, NULL)
    __get_user_pages_locked(current, current->mm, addr, 1, NULL, NULL, NULL,
    false, flags | FOLL_TOUCH)
    __get_user_pages(current, current->mm, addr, 1, flags | FOLL_TOUCH, NULL,
     NULL, NULL)

Signed-off-by: Lorenzo Stoakes <lstoakes@gmail.com>
Acked-by: Paolo Bonzini <pbonzini@redhat.com>
Acked-by: Michal Hocko <mhocko@suse.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

proc: don't use FOLL_FORCE for reading cmdline and environment

Now that Lorenzo cleaned things up and made the FOLL_FORCE users
explicit, it becomes obvious how some of them don't really need
FOLL_FORCE at all.

So remove FOLL_FORCE from the proc code that reads the command line and
arguments from user space.

The mem_rw() function actually does want FOLL_FORCE, because gdd (and
possibly many other debuggers) use it as a much more convenient version
of PTRACE_PEEKDATA, but we should consider making the FOLL_FORCE part
conditional on actually being a ptracer.  This does not actually do
that, just moves adds a comment to that effect and moves the gup_flags
settings next to each other.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

cpufreq: intel_pstate: Always set max P-state in performance mode

The only times at which intel_pstate checks the policy set for
a given CPU is the initialization of that CPU and updates of its
policy settings from cpufreq when intel_pstate_set_policy() is
invoked.

That is insufficient, however, because intel_pstate uses the same
P-state selection function for all CPUs regardless of the policy
setting for each of them and the P-state limits are shared between
them.  Thus if the policy is set to "performance" for a particular
CPU, it may not behave as expected if the cpufreq settings are
changed subsequently for another CPU.

That can be easily demonstrated by writing "performance" to
scaling_governor for all CPUs and then switching it to "powersave"
for one of them in which case all of the CPUs will behave as though
their scaling_governor were all "powersave" (even though the policy
still appears to be "performance" for the remaining CPUs).

Fix this problem by modifying intel_pstate_adjust_busy_pstate() to
always set the P-state to the maximum allowed by the current limits
for all CPUs whose policy is set to "performance".

Note that it still is recommended to always change the policy setting
in the same way for all CPUs even with this fix applied to avoid
confusion.

Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

nbd: fix incorrect unlock of nbd->sock_lock in sock_shutdown

Commit 0eadf37afc250 ("nbd: allow block mq to deal with timeouts")
changed normal usage of nbd->sock_lock to use spin_lock/spin_unlock
rather than the *_irq variants, but it missed this unlock in an
error path.

Found by Coverity, CID 1373871.

Signed-off-by: John W. Linville <linville@tuxdriver.com>
Cc: Josef Bacik <jbacik@fb.com>
Cc: Jens Axboe <axboe@fb.com>
Cc: Markus Pargmann <mpa@pengutronix.de>
Fixes: 0eadf37afc250 ("nbd: allow block mq to deal with timeouts")
Signed-off-by: Jens Axboe <axboe@fb.com>

orangefs: don't use d_time

Instead use d_fsdata which is the same size.  Hoping to get rid of d_time,
which is used by very few filesystems by this time.

Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
Reviewed-by: Martin Brandenburg <martin@omnibond.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

orangefs: user file_inode() where it is due

Replace wrong use of file->f_path.dentry->d_inode with file_inode(file).
In case orangefs ever finds itself as an overelayfs layer, it would want
to get its own inode and not overlayfs's inode.

DISCLAIMER: I did not test this patch because I do not know how to setup
            an orangefs mount

Signed-off-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Mike Marshall <hubcap@omnibond.com>

ARCv2: IOC: use @ioc_enable not @ioc_exist where intended

if user disables IOC from debugger at startup (by clearing @ioc_enable),
@ioc_exists is cleared too. This means boot prints don't capture the
fact that IOC was present but disabled which could be misleading.

So invert how we use @ioc_enable and @ioc_exists and make it more
canonical. @ioc_exists represent whether hardware is present or not and
stays same whether enabled or not. @ioc_enable is still user driven,
but will be auto-disabled if IOC hardware is not present, i.e. if
@ioc_exist=0. This is opposite to what we were doing before, but much
clearer.

This means @ioc_enable is now the "exported" toggle in rest of code such
as dma mapping API.

Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

ARC: syscall for userspace cmpxchg assist

Older ARC700 cores (ARC750 specifically) lack instructions to implement
atomic r-w-w. This is problematic for userspace libraries such as NPTL
which need atomic primitives. So enable them by providing kernel assist.
This is costly but really the only sane soluton (othern than tight
spinning using the otherwise availiable atomic exchange EX instruciton).

Good thing is there are only a few of these cores running Linux out in
the wild.

This only works on UP systems.

Reviewed-by: Colin Ian King <colin.king@canonical.com>
Signed-off-by: Vineet Gupta <vgupta@synopsys.com>

dm table: fix missing dm_put_target_type() in dm_table_add_target()

dm_get_target_type() was previously called so any error returned from
dm_table_add_target() must first call dm_put_target_type().  Otherwise
the DM target module's reference count will leak and the associated
kernel module will be unable to be removed.

Also, leverage the fact that r is already -EINVAL and remove an extra
newline.

Fixes: 36a0456 ("dm table: add immutable feature")
Fixes: cc6cbe1 ("dm table: add always writeable feature")
Fixes: 3791e2f ("dm table: add singleton feature")
Cc: stable@vger.kernel.org # 3.2+
Signed-off-by: tang.junhui <tang.junhui@zte.com.cn>
Signed-off-by: Mike Snitzer <snitzer@redhat.com>

xenbus: check return value of xenbus_scanf()

Don't ignore errors here: Set backend state to unknown when
unsuccessful.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>

xenbus: prefer list_for_each()

This is more efficient than list_for_each_safe() when list modification
is accompanied by breaking out of the loop.

Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Juergen Gross <jgross@suse.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>

x86: xen: move cpu_up functions out of ifdef

Three newly introduced functions are not defined when CONFIG_XEN_PVHVM is
disabled, but are still being used:

arch/x86/xen/enlighten.c:141:12: warning: ‘xen_cpu_up_prepare’ used but never defined
arch/x86/xen/enlighten.c:142:12: warning: ‘xen_cpu_up_online’ used but never defined
arch/x86/xen/enlighten.c:143:12: warning: ‘xen_cpu_dead’ used but never defined

Fixes: 4d737042d6c4 ("xen/x86: Convert to hotplug state machine")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>

xenbus: advertise control feature flags

The Xen docs specify several flags which a guest can set to advertise
which values of the xenstore control/shutdown key it will recognize.
This patch adds code to write all the relevant feature-flag keys.

Based-on-patch-by: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: Juergen Gross <jgross@suse.com>
Reviewed-by: David Vrabel <david.vrabel@citrix.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Signed-off-by: David Vrabel <david.vrabel@citrix.com>

greybus: fix a leak on error in gb_module_create()

We should release ->interfaces[0] as well.

Fixes: b15d97d77017 ("greybus: core: add module abstraction")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Acked-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

greybus: es2: fix error return code in ap_probe()

Fix to return a negative error code from the es2_arpc_in_enable() error
handling case instead of 0, as done elsewhere in this function.

Fixes: 9d9d3777a9db ("greybus: es2: Add a new bulk in endpoint for APBridgeA RPC")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

greybus: arche-platform: Add missing of_node_put() in arche_platform_change_state()

This node pointer is returned by of_find_compatible_node() with
refcount incremented in this function. of_node_put() on it before
exitting this function.

This is detected by Coccinelle semantic patch.

Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Johan Hovold <johan@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

staging: android: ion: Fix error handling in ion_query_heaps()

If the copy_to_user() fails we should unlock and return directly without
updating "cnt".  Also the return value should be -EFAULT instead of the
number of bytes remaining.

Fixes: 02b23803c6af ("staging: android: ion: Add ioctl to query available heaps")
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

PM / suspend: Fix missing KERN_CONT for suspend message

Commit 4bcc595ccd80 (printk: reinstate KERN_CONT for printing
continuation lines) exposed a missing KERN_CONT from one of the
messages shown on entering suspend. With v4.9-rc1, the 'done.' shown
after syncing the filesystems no longer appears as a continuation but
a new message with its own timestamp.

[    9.259566] PM: Syncing filesystems ... [    9.264119] done.

Fix this by adding the KERN_CONT log level for the 'done.' part of the
message seen after syncing filesystems. While we are at it, convert
these suspend printks to pr_info and pr_cont, respectively.

Signed-off-by: Jon Hunter <jonathanh@nvidia.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

usb: renesas_usbhs: add wait after initialization for R-Car Gen3

Since the controller on R-Car Gen3 doesn't have any status registers
to detect initialization (LPSTS.SUSPM = 1) and the initialization needs
up to 45 usec, this patch adds wait after the initialization. Otherwise,
writing other registers (e.g. INTENB0) will fail.

Fixes: de18757e272d ("usb: renesas_usbhs: add R-Car Gen3 power control")
Cc: <stable@vger.kernel.org> # v4.6+
Cc: <balbi@kernel.org>
Signed-off-by: Yoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ACPI / APEI: Fix incorrect return value of ghes_proc()

Although ghes_proc() tests for errors while reading the error status,
it always return success (0). Fix this by propagating the return
value.

Fixes: d334a49113a4a33 (ACPI, APEI, Generic Hardware Error Source memory error support)
Signed-of-by: Punit Agrawal <punit.agrawa.@arm.com>
Tested-by: Tyler Baicar <tbaicar@codeaurora.org>
Reviewed-by: Borislav Petkov <bp@suse.de>
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

usb: increase ohci watchdog delay to 275 msec

Increase ohci watchout delay to 275 ms. Previous delay was 250 ms
with 20 ms of slack, after removing slack time some ohci controllers don't
respond in time. Logs from systems with controllers that have the
issue would show "HcDoneHead not written back; disabled"

Signed-off-by: Bryan Paluch <bryanpaluch@gmail.com>
Acked-by: Alan Stern <stern@rowland.harvard.edu>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: musb: Call pm_runtime from musb_gadget_queue

If we're booting pandaboard using NFSroot over built-in g_ether, we
can get the following after booting once and doing a warm reset:

g_ether gadget: ecm_open
g_ether gadget: notify connect true
...
WARNING: CPU: 0 PID: 1 at drivers/bus/omap_l3_noc.c:147
l3_interrupt_handler+0x220/0x34c
44000000.ocp:L3 Custom Error: MASTER MPU TARGET L4CFG (Read):
Data Access in User mode du ring Functional access
...

Fix the issue by calling pm_runtime functions from
musb_gadget_queue.

Note that in the long run we should be able to queue the pending
transfers if pm_runtime is not active, and flush the queue from
pm_runtime_resume.

Reported-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Tested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: musb: Fix hardirq-safe hardirq-unsafe lock order error

If we configure musb with 2430 glue as a peripheral, and then rmmod
omap2430 module, we'll get the following error:

[ INFO: HARDIRQ-safe -> HARDIRQ-unsafe lock order detected ]
...
rmmod/413 [HC0[0]:SC0[0]:HE0:SE1] is trying to acquire:
 (&phy->mutex){+.+.+.}, at: [<c04b9fd0>] phy_power_off+0x1c/0xb8
[  204.678710]
               and this task is already holding:
 (&(&musb->lock)->rlock){-.-...}, at: [<bf3a482c>]
 musb_gadget_stop+0x24/0xec [musb_hdrc]
which would create a new lock dependency:
 (&(&musb->lock)->rlock){-.-...} -> (&phy->mutex){+.+.+.}
...

This is because some glue layers expect musb_platform_enable/disable
to be called with spinlock held, and 2430 glue layer has USB PHY on
the I2C bus using a mutex.

We could fix the glue layers to take the spinlock, but we still have
a problem of musb_plaform_enable/disable being called in an unbalanced
manner. So that would still lead into USB PHY enable/disable related
problems for omap2430 glue layer.

While it makes sense to only enable USB PHY when needed from PM point
of view, in this case we just can't do it yet without breaking things.
So let's just revert phy_enable/disable related changes instead and
reconsider this after we have fixed musb_platform_enable/disable to
be balanced.

Fixes: a83e17d0f73b ("usb: musb: Improve PM runtime and phy handling for 2430 glue layer")
Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Bin Liu <b-liu@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: ehci-platform: increase EHCI_MAX_RSTS to 4

Socionext LD11 SoC (arch/arm64/boot/dts/socionext/uniphier-ld11.dtsi)
needs to handle 4 reset lines for EHCI.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

usb: ohci-at91: Set RemoteWakeupConnected bit explicitly.

The reset value of RWC is 0, set RemoteWakeupConnected bit explicitly
before calling ohci_run, it also fixes the issue that the mass
storage stick connected wasn't suspended when the system suspend.

Signed-off-by: Wenyou Yang <wenyou.yang@atmel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

ACPI/PCI: pci_link: Include PIRQ_PENALTY_PCI_USING for ISA IRQs

Commit 103544d86976 ("ACPI,PCI,IRQ: reduce resource requirements")
replaced the addition of PIRQ_PENALTY_PCI_USING in acpi_pci_link_allocate()
with an addition in acpi_irq_pci_sharing_penalty(), but f7eca374f000
("ACPI,PCI,IRQ: separate ISA penalty calculation") removed the use
of acpi_irq_pci_sharing_penalty() for ISA IRQs.

Therefore, PIRQ_PENALTY_PCI_USING is missing from ISA IRQs used by
interrupt links.  Include that penalty by adding it in the
acpi_pci_link_allocate() path.

Fixes: f7eca374f000 (ACPI,PCI,IRQ: separate ISA penalty calculation)
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI/PCI: pci_link: penalize SCI correctly

Ondrej reported that IRQs stopped working in v4.7 on several
platforms.  A typical scenario, from Ondrej's VT82C694X/694X, is:

ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [LNKA] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: No IRQ available for PCI Interrupt Link [LNKA]
8139too 0000:00:0f.0: PCI INT A: no GSI

We're using PIC routing, so acpi_irq_balance == 0, and LNKA is already
active at IRQ 11. In that case, acpi_pci_link_allocate() only tries
to use the active IRQ (IRQ 11) which also happens to be the SCI.

We should penalize the SCI by PIRQ_PENALTY_PCI_USING, but
irq_get_trigger_type(11) returns something other than
IRQ_TYPE_LEVEL_LOW, so we penalize it by PIRQ_PENALTY_ISA_ALWAYS
instead, which makes acpi_pci_link_allocate() assume the IRQ isn't
available and give up.

Add acpi_penalize_sci_irq() so platforms can tell us the SCI IRQ,
trigger, and polarity directly and we don't have to depend on
irq_get_trigger_type().

Fixes: 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements)
Link: http://lkml.kernel.org/r/201609251512.05657.linux@rainbow-software.org
Reported-by: Ondrej Zary <linux@rainbow-software.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Tested-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

ACPI/PCI/IRQ: assign ISA IRQ directly during early boot stages

We do not want to store the SCI penalty in the acpi_isa_irq_penalty[]
table because acpi_isa_irq_penalty[] only holds ISA IRQ penalties and
there's no guarantee that the SCI is an ISA IRQ.  We add in the SCI
penalty as a special case in acpi_irq_get_penalty().

But if we called acpi_penalize_isa_irq() or acpi_irq_penalty_update()
for an SCI that happened to be an ISA IRQ, they stored the SCI
penalty (part of the acpi_irq_get_penalty() return value) in
acpi_isa_irq_penalty[].  Subsequent calls to acpi_irq_get_penalty()
returned a penalty that included *two* SCI penalties.

Fixes: 103544d86976 (ACPI,PCI,IRQ: reduce resource requirements)
Signed-off-by: Sinan Kaya <okaya@codeaurora.org>
Acked-by: Bjorn Helgaas <bhelgaas@google.com>
Tested-by: Jonathan Liu <net147@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>

Merge tag 'iio-fixes-for-4.9a' of git://git./linux/kernel/git/jic23/iio into staging-linus

Jonathan writes:

First set of IIO fixes for the 4.9 cycle.

* atlas chemical
  - Fix alignment of big endian values in a larger storage (by using the right
  size storage)
* maxim thermocouple
  - Fix alignment of big endian values in larger (by using the correct
  sized storage).
* sca3000
  - Handle unexpected mode values.
* ti-adc081
  - Select IIO_TRIGGERED_BUFFER to avoid build errors

powerpc/64: Fix race condition in setting lock bit in idle/wakeup code

This fixes a race condition where one thread that is entering or
leaving a power-saving state can inadvertently ignore the lock bit
that was set by another thread, and potentially also clear it.
The core_idle_lock_held function is called when the lock bit is
seen to be set.  It polls the lock bit until it is clear, then
does a lwarx to load the word containing the lock bit and thread
idle bits so it can be updated.  However, it is possible that the
value loaded with the lwarx has the lock bit set, even though an
immediately preceding lwz loaded a value with the lock bit clear.
If this happens then we go ahead and update the word despite the
lock bit being set, and when called from pnv_enter_arch207_idle_mode,
we will subsequently clear the lock bit.

No identifiable misbehaviour has been attributed to this race.

This fixes it by checking the lock bit in the value loaded by the
lwarx.  If it is set then we just go back and keep on polling.

Fixes: b32aadc1a8ed ("powerpc/powernv: Fix race in updating core_idle_state")
Cc: stable@vger.kernel.org # v4.2+
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

powerpc/64: Re-fix race condition between going idle and entering guest

Commit 8117ac6a6c2f ("powerpc/powernv: Switch off MMU before entering
nap/sleep/rvwinkle mode", 2014-12-10) fixed a race condition where one
thread entering a KVM guest could switch the MMU context to the guest
while another thread was still in host kernel context with the MMU on.
That commit moved the point where a thread entering a power-saving
mode set its kvm_hstate.hwthread_state field in its PACA to
KVM_HWTHREAD_IN_IDLE from a point where the MMU was on to after the
MMU had been switched off.  That commit also added a comment
explaining that we have to switch to real mode before setting
hwthread_state to avoid this race.

Nevertheless, commit 4eae2c9ae54a ("powerpc/powernv: Make
pnv_powersave_common more generic", 2016-07-08) subsequently moved
the setting of hwthread_state back to a point where the MMU is on,
thus reintroducing the race, despite the comment saying that this
should not be done being included in full in the context lines of
the patch that did it.

This fixes the race again and adds a bigger and shoutier comment
explaining the potential race condition.

Fixes: 4eae2c9ae54a ("powerpc/powernv: Make pnv_powersave_common more generic")
Cc: stable@vger.kernel.org # v4.8+
Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
Reviewed-by: Shreyas B. Prabhu <shreyasbp@gmail.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

s390/mm: fix zone calculation in arch_add_memory()

Standby (hotplug) memory should be added to ZONE_MOVABLE on s390. After
commit 199071f1 "s390/mm: make arch_add_memory() NUMA aware",
arch_add_memory() used memblock_end_of_DRAM() to find out the end of
ZONE_NORMAL and the beginning of ZONE_MOVABLE. However, commit 7f36e3e5
"memory-hotplug: add hot-added memory ranges to memblock before allocate
node_data for a node." moved the call of memblock_add_node() before
the call of arch_add_memory() in add_memory_resource(), and thus changed
the return value of memblock_end_of_DRAM() when called in
arch_add_memory(). As a result, arch_add_memory() will think that all
memory blocks should be added to ZONE_NORMAL.

Fix this by changing the logic in arch_add_memory() so that it will
manually iterate over all zones of a given node to find out which zone
a memory block should be added to.

Reviewed-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Gerald Schaefer <gerald.schaefer@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>

s390/dumpstack: use pr_cont within show_stack and die

Use pr_cont instead of printk calls also within show_stack and
die in order to avoid extra line breaks.

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

xfs: clear cowblocks tag when cow fork is emptied

The background cowblocks scan job takes care of scanning for inodes with
potentially lingering blocks in the cow fork and clearing them out. If
the background scanner reclaims the cow fork blocks, however, it doesn't
immediately clear the cowblocks tag from the inode. Instead, the inode
remains tagged until the background scanner comes around again,
discovers the inode cow fork has no blocks, clears the tag and fires the
trace_xfs_inode_free_cowblocks_invalid() tracepoint to indicate that the
inode may have been incorrectly tagged.

This is not a major functional problem as the tag is ultimately cleared.
Nonetheless, clear the tag when an inode cow fork is explicitly emptied
to avoid the extra round trip through the background scanner and
spurious "invalid" tracepoint.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

xfs: fix up inode cowblocks tracking tracepoints

These calls are still using the eofblocks tracepoints. The cowblocks
equivalents are already defined, we just aren't actually calling them.

Signed-off-by: Brian Foster <bfoster@redhat.com>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>
Signed-off-by: Dave Chinner <david@fromorbit.com>

fs: Do to trim high file position bits in iomap_page_mkwrite_actor

iomap_page_mkwrite_actor() calls __block_write_begin_int() with position
masked as pos & ~PAGE_MASK which is equivalent to pos & (PAGE_SIZE-1).
Thus it masks off high bits of file position. However
__block_write_begin_int() expects full file position on input. This does
not cause any visible issues because all __block_write_begin_int()
really cares about are low file position bits but still it is a bug
waiting to happen.

Signed-off-by: Jan Kara <jack@suse.cz>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Dave Chinner <david@fromorbit.com>

cxl: Fix leaking pid refs in some error paths

In some error paths in functions cxl_start_context and
afu_ioctl_start_work pid references to the current & group-leader tasks
can leak after they are taken. This patch fixes these error paths to
release these pid references before exiting the error path.

Fixes: 7b8ad495d592 ("cxl: Fix DSI misses when the context owning task exits")
Cc: stable@vger.kernel.org # v4.5+
Reviewed-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Reported-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

gpio: mpc8xxx: Correct irq handler function

From the beginning of the gpio-mpc8xxx.c, the "handle_level_irq"
has being used to handle GPIO interrupts in the PowerPC/Layerscape
platforms. But actually, almost all PowerPC/Layerscape platforms
assert an interrupt request upon either a high-to-low change or
any change on the state of the signal.

So the "handle_level_irq" is not reasonable for PowerPC/Layerscape
GPIO interrupt, it should be "handle_edge_irq". Otherwise the system
may lost some interrupts from the PIN's state changes.

Signed-off-by: Liu Gang <Gang.Liu@nxp.com>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

Linux 4.9-rc2

Merge tag 'upstream-4.9-rc2' of git://git.infradead.org/linux-ubifs

Pull UBI[FS] fixes from Richard Weinberger:
 "This contains fixes for issues in both UBI and UBIFS:

   - Fallout from the merge window, refactoring UBI code introduced some
     issues.

   - Fixes for an UBIFS readdir bug which can cause getdents() to busy
     loop for ever and a bug in the UBIFS xattr code"

* tag 'upstream-4.9-rc2' of git://git.infradead.org/linux-ubifs:
  ubifs: Abort readdir upon error
  UBI: Fix crash in try_recover_peb()
  ubi: fix swapped arguments to call to ubi_alloc_aeb
  ubifs: Fix xattr_names length in exit paths
  ubifs: Rename ubifs_rename2

Merge tag 'ext4_for_linus_stable' of git://git./linux/kernel/git/tytso/ext4

Pull ext4 fixes from Ted Ts'o:
 "A few bug fixes and add some missing KERN_CONT annotations"

* tag 'ext4_for_linus_stable' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4:
  ext4: add missing KERN_CONT to a few more debugging uses
  fscrypto: lock inode while setting encryption policy
  ext4: correct endianness conversion in __xattr_check_inode()
  fscrypto: make XTS tweak initialization endian-independent
  ext4: do not advertise encryption support when disabled
  jbd2: fix incorrect unlock on j_list_lock
  ext4: super.c: Update logging style using KERN_CONT

Merge git://git./linux/kernel/git/nab/target-pending

Pull SCSI target fixes from Nicholas Bellinger:
 "Here are the outstanding target-pending fixes for v4.9-rc2.

  This includes:

   - Fix v4.1.y+ reference leak regression with concurrent TMR
     ABORT_TASK + session shutdown. (Vaibhav Tandon)

   - Enable tcm_fc w/ SCF_USE_CPUID to avoid host exchange timeouts
     (Hannes)

   - target/user error sense handling fixes. (Andy + MNC + HCH)

   - Fix iscsi-target NOP_OUT error path iscsi_cmd descriptor leak
     (Varun)

   - Two EXTENDED_COPY SCSI status fixes for ESX VAAI (Dinesh Israni +
     Nixon Vincent)

   - Revert a v4.8 residual overflow change, that breaks sg_inq with
     small allocation lengths.

  There are a number of folks stress testing the v4.1.y regression fix
  in their environments, and more folks doing iser-target I/O stress
  testing atop recent v4.x.y code.

  There is also one v4.2.y+ RCU conversion regression related to
  explicit NodeACL configfs changes, that is still being tracked down"

* git://git.kernel.org/pub/scm/linux/kernel/git/nab/target-pending:
  target/tcm_fc: use CPU affinity for responses
  target/tcm_fc: Update debugging statements to match libfc usage
  target/tcm_fc: return detailed error in ft_sess_create()
  target/tcm_fc: print command pointer in debug message
  target: fix potential race window in target_sess_cmd_list_waiting()
  Revert "target: Fix residual overflow handling in target_complete_cmd_with_length"
  target: Don't override EXTENDED_COPY xcopy_pt_cmd SCSI status code
  target: Make EXTENDED_COPY 0xe4 failure return COPY TARGET DEVICE NOT REACHABLE
  target: Re-add missing SCF_ACK_KREF assignment in v4.1.y
  iscsi-target: fix iscsi cmd leak
  iscsi-target: fix spelling mistake "Unsolicitied" -> "Unsolicited"
  target/user: Fix comments to not refer to data ring
  target/user: Return an error if cmd data size is too large
  target/user: Use sense_reason_t in tcmu_queue_cmd_ring

Merge tag 'hwmon-for-linus-v4.9-rc2' of git://git./linux/kernel/git/groeck/linux-staging

Pull hwmon fixes from Guenter Roeck:
 "Couple of hwmon fixes:

  Fix a potential ERR_PTR dereference in max31790 driver, and handle
  temperature readings below 0 in adm9240 driver"

* tag 'hwmon-for-linus-v4.9-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/groeck/linux-staging:
  hwmon: (max31790) potential ERR_PTR dereference
  hwmon: (adm9240) handle temperature readings below 0

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

Pull IPMI updates from Corey Minyard:
 "A small bug fix and a new driver for acting as an IPMI device.

  I was on vacation during the merge window (a long vacation) but this
  is a bug fix that should go in and a new driver that shouldn't hurt
  anything.

  This has been in linux-next for a month or so"

* tag 'for-linus-4.9-2' of git://git.code.sf.net/p/openipmi/linux-ipmi:
  ipmi: fix crash on reading version from proc after unregisted bmc
  ipmi/bt-bmc: remove redundant return value check of platform_get_resource()
  ipmi/bt-bmc: add a dependency on ARCH_ASPEED
  ipmi: Fix ioremap error handling in bt-bmc
  ipmi: add an Aspeed BT IPMI BMC driver

gpio: ath79: Fix module autoload

If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.

Export the module alias information using the MODULE_DEVICE_TABLE() macro.

Before this patch:

$ modinfo drivers/gpio/gpio-ath79.ko | grep alias
$

After this patch:

$ modinfo drivers/gpio/gpio-ath79.ko | grep alias
alias:          of:N*T*Cqca,ar9340-gpioC*
alias:          of:N*T*Cqca,ar9340-gpio
alias:          of:N*T*Cqca,ar7100-gpioC*
alias:          of:N*T*Cqca,ar7100-gpio

Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com>
Acked-by: Aban Bedel <albeu@free.fr>
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>

iio: accel: sca3000_core: avoid potentially uninitialized variable

The newly added __sca3000_get_base_freq function handles all valid
modes of the SCA3000_REG_ADDR_MODE register, but gcc notices
that any other value (i.e. 0x00) causes the base_freq variable to
not get initialized:

drivers/staging/iio/accel/sca3000_core.c: In function 'sca3000_write_raw':
drivers/staging/iio/accel/sca3000_core.c:527:23: error: 'base_freq' may be used uninitialized in this function [-Werror=maybe-uninitialized]

This adds explicit error handling for unexpected register values,
to ensure this cannot happen.

Fixes: e0f3fc9b47e6 ("iio: accel: sca3000_core: implemented IIO_CHAN_INFO_SAMP_FREQ")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Cc: Ico Doornekamp <ico@pruts.nl>
Cc: Jonathan Cameron <jic23@kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

iio:chemical:atlas-ph-sensor: Fix use of 32 bit int to hold 16 bit big endian value

This will result in a random value being reported on big endian architectures.
(thanks to Lars-Peter Clausen for pointing out the effects of this bug)

Only effects a value printed to the log, but as this reports the settings of
the probe in question it may be of direct interest to users.

Also, fixes the following sparse endianness warnings:

drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16
drivers/iio/chemical/atlas-ph-sensor.c:215:9: warning: cast to restricted __be16

Signed-off-by: Sandhya Bankar <bankarsandhya512@gmail.com>
Fixes: e8dd92bfbff25 ("iio: chemical: atlas-ph-sensor: add EC feature")
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>

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

Pull timer updates from Thomas Gleixner:
 "This updates contains:

   - A revert which addresses a boot failure on ARM Sun5i platforms

   - A new clocksource driver, which has been delayed beyond rc1 due to
     an interrupt driver issue which was unearthed by this driver. The
     debugging of that issue and the discussion about the proper
     solution made this driver miss the merge window. There is no point
     in delaying it for a full cycle as it completes the basic mainline
     support for the new JCore platform and does not create any risk
     outside of that platform"

* 'timers-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  Revert "clocksource/drivers/timer_sun5i: Replace code by clocksource_mmio_init"
  clocksource: Add J-Core timer/clocksource driver
  of: Add J-Core timer bindings

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

Pull x86 fixes from Ingo Molnar:
 "Three fixes, a hw-enablement and a cross-arch fix/enablement change:

   - SGI/UV fix for older platforms

   - x32 signal handling fix

   - older x86 platform bootup APIC fix

   - AVX512-4VNNIW (Neural Network Instructions) and AVX512-4FMAPS
     (Multiply Accumulation Single precision instructions) enablement.

   - move thread_info back into x86 specific code, to make life easier
     for other architectures trying to make use of
     CONFIG_THREAD_INFO_IN_TASK_STRUCT=y"

* 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/boot/smp: Don't try to poke disabled/non-existent APIC
  sched/core, x86: Make struct thread_info arch specific again
  x86/signal: Remove bogus user_64bit_mode() check from sigaction_compat_abi()
  x86/platform/UV: Fix support for EFI_OLD_MEMMAP after BIOS callback updates
  x86/cpufeature: Add AVX512_4VNNIW and AVX512_4FMAPS features
  x86/vmware: Skip timer_irq_works() check on VMware

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

Pull vmap stack fixes from Ingo Molnar:
 "This is fallout from CONFIG_HAVE_ARCH_VMAP_STACK=y on x86: stack
  accesses that used to be just somewhat questionable are now totally
  buggy.

  These changes try to do it without breaking the ABI: the fields are
  left there, they are just reporting zero, or reporting narrower
  information (the maps file change)"

* 'mm-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  mm: Change vm_is_stack_for_task() to vm_is_stack_for_current()
  fs/proc: Stop trying to report thread stacks
  fs/proc: Stop reporting eip and esp in /proc/PID/stat
  mm/numa: Remove duplicated include from mprotect.c

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

Pull irq fixes from Ingo Molnar:
 "Mostly irqchip driver fixes, plus a symbol export"

* 'irq-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  kernel/irq: Export irq_set_parent()
  irqchip/gic: Add missing \n to CPU IF adjustment message
  irqchip/jcore: Don't show Kconfig menu item for driver
  irqchip/eznps: Drop pointless static qualifier in nps400_of_init()
  irqchip/gic-v3-its: Fix entry size mask for GITS_BASER
  irqchip/gic-v3-its: Fix 64bit GIC{R,ITS}_TYPER accesses

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

Pull EFI fixes from Ingo Molnar:
 "Add Ard Biesheuvel as EFI co-maintainer, plus fix an ARM build bug
  with older toolchains"

* 'efi-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  efi/arm: Fix absolute relocation detection for older toolchains
  MAINTAINERS: Add myself as EFI maintainer

Merge tag 'usb-serial-4.9-rc2' of git://git./linux/kernel/git/johan/usb-serial into usb-linus

Johan writes:

USB-serial fixes for v4.9-rc2

Here's a fix for a NULL-deref during probe which could be triggered by a
malicious device, and a fix for some missing error handling in cp210x
that also leaked some bits from the stack. Included is also a new device
id for ftdi_sio.

Signed-off-by: Johan Hovold <johan@kernel.org>

x86/boot/smp: Don't try to poke disabled/non-existent APIC

Apparently trying to poke a disabled or non-existent APIC
leads to a box that doesn't even boot. Let's not do that.

No real clue if this is the right fix, but at least my
P3 machine boots again.

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Borislav Petkov <bp@alien8.de>
Cc: Borislav Petkov <bp@suse.de>
Cc: Brian Gerst <brgerst@gmail.com>
Cc: Denys Vlasenko <dvlasenk@redhat.com>
Cc: Eric Biederman <ebiederm@xmission.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Juergen Gross <jgross@suse.com>
Cc: Len Brown <len.brown@intel.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Prarit Bhargava <prarit@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: dyoung@redhat.com
Cc: kexec@lists.infradead.org
Cc: stable@vger.kernel.org
Fixes: 2a51fe083eba ("arch/x86: Handle non enumerated CPU after physical hotplug")
Link: http://lkml.kernel.org/r/1477102684-5092-1-git-send-email-ville.syrjala@linux.intel.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>

Merge tag 'powerpc-4.9-3' of git://git./linux/kernel/git/powerpc/linux

Pull powerpc fixes from Michael Ellerman:
 "Fixes marked for stable:
   - Prevent unlikely crash in copro_calculate_slb() (Frederic Barrat)
   - cxl: Prevent adapter reset if an active context exists (Vaibhav Jain)

  Fixes for code merged this cycle:
   - Fix boot on systems with uncompressed kernel image (Heiner Kallweit)
   - Drop dump_numa_memory_topology() (Michael Ellerman)
   - Fix numa topology console print (Aneesh Kumar K.V)
   - Ignore the pkey system calls for now (Stephen Rothwell)"

* tag 'powerpc-4.9-3' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux:
  powerpc: Ignore the pkey system calls for now
  powerpc: Fix numa topology console print
  powerpc/mm: Drop dump_numa_memory_topology()
  cxl: Prevent adapter reset if an active context exists
  powerpc/boot: Fix boot on systems with uncompressed kernel image
  powerpc/mm: Prevent unlikely crash in copro_calculate_slb()

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

Pull KVM fixes from Radim Krčmář:
 "ARM:
   - avoid livelock when walking guest page tables
   - fix HYP mode static keys without CC_HAVE_ASM_GOTO

  MIPS:
   - fix a build error without TRACEPOINTS_ENABLED

  s390:
   - reject a malformed userspace configuration

  x86:
   - suppress a warning without CONFIG_CPU_FREQ
   - initialize whole irq_eoi array"

* tag 'for-linus' of git://git.kernel.org/pub/scm/virt/kvm/kvm:
  arm/arm64: KVM: Map the BSS at HYP
  arm64: KVM: Take S1 walks into account when determining S2 write faults
  KVM: s390: reject invalid modes for runtime instrumentation
  kvm: x86: memset whole irq_eoi
  kvm/x86: Fix unused variable warning in kvm_timer_init()
  KVM: MIPS: Add missing uaccess.h include

Merge tag 'nfs-for-4.9-2' of git://git.linux-nfs.org/projects/anna/linux-nfs

Pull NFS client bugfixes from Anna Schumaker:
 "Just two bugfixes this time:

  Stable bugfix:
   - Fix last_write_offset incorrectly set to page boundary

  Other bugfix:
   - Fix missing-braces warning"

* tag 'nfs-for-4.9-2' of git://git.linux-nfs.org/projects/anna/linux-nfs:
  nfs4: fix missing-braces warning
  pnfs/blocklayout: fix last_write_offset incorrectly set to page boundary

Merge tag 'acpi-4.9-rc2' of git://git./linux/kernel/git/rafael/linux-pm

Pull ACPI fixes from Rafael Wysocki:
 "These fix an issue related to system resume in the new WDAT-based
  watchdog driver and a return value of a stub function in the ACPI CPPC
  framework.

  Specifics:

   - Update the ACPI WDAT-based watchdog driver to ping the hardware
     during system resume to prevent a reset from occurring after the
     resume is complete (Mika Westerberg).

   - Fix the return value of the pcc_mbox_request_channel() stub for
     CONFIG_PCC unset (Hoan Tran)"

* tag 'acpi-4.9-rc2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
  watchdog: wdat_wdt: Ping the watchdog on resume
  mailbox: PCC: Fix return value of pcc_mbox_request_channel()

badblocks: badblocks_set/clear update unacked_exist

When bandblocks_set acknowledges a range or badblocks_clear a range,
it's possible all badblocks are acknowledged. We should update
unacked_exist if this occurs.

Signed-off-by: Shaohua Li <shli@fb.com>
Reviewed-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
Tested-by: Tomasz Majchrzak <tomasz.majchrzak@intel.com>
Signed-off-by: Jens Axboe <axboe@fb.com>

softirq: Display IRQ_POLL for irq-poll statistics

This library was moved to the generic area and was
renamed to irq-poll. Hence, update proc/softirqs output accordingly.

Signed-off-by: Sagi Grimberg <sagi@grimberg.me>
Reviewed-by: Johannes Thumshirn <jthumshirn@suse.de>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Jens Axboe <axboe@fb.com>

powerpc: Convert cmp to cmpd in idle enter sequence

PowerPC's "cmp" instruction has four operands. Normally people write
"cmpw" or "cmpd" for the second cmp operand 0 or 1. But, frequently
people forget, and write "cmp" with just three operands.

With older binutils this is silently accepted as if this was "cmpw",
while often "cmpd" is wanted. With newer binutils GAS will complain
about this for 64-bit code. For 32-bit code it still silently assumes
"cmpw" is what is meant.

In this instance the code comes directly from ISA v2.07, including the
cmp, but cmpd is correct. Backport to stable so that new toolchains can
build old kernels.

Fixes: 948cf67c4726 ("powerpc: Add NAP mode support on Power7 in HV mode")
Cc: stable@vger.kernel.org # v3.0
Reviewed-by: Vaidyanathan Srinivasan <svaidy@linux.vnet.ibm.com>
Signed-off-by: Segher Boessenkool <segher@kernel.crashing.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>

KVM: PPC: Book3S HV: Fix build error when SMP=n

Commit 5d375199ea96 ("KVM: PPC: Book3S HV: Set server for passed-through
interrupts") broke the SMP=n build:

  arch/powerpc/kvm/book3s_hv_rm_xics.c:758:2: error: implicit declaration of function 'get_hard_smp_processor_id'

That is because we lost the implicit include of asm/smp.h, so include it
explicitly to get the definition for get_hard_smp_processor_id().

Fixes: 5d375199ea96 ("KVM: PPC: Book3S HV: Set server for passed-through interrupts")
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>