commit cb5d016a9dd33c3131efff555d43095caf51f69e
Author: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date:   Sun Oct 16 18:03:56 2016 +0200

    Linux 4.8.2

commit 87d6616d78870ae635ae991d63fbe4eb4a7c82c2
Author: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Date:   Fri Sep 2 22:34:17 2016 +0300

    tpm_crb: fix crb_req_canceled behavior
    
    commit 72fd50e14e46dc0edf360631bdece87c2f066a97 upstream.
    
    The req_canceled() callback is used by tpm_transmit() periodically to
    check whether the request has been canceled while it is receiving a
    response from the TPM.
    
    The TPM_CRB_CTRL_CANCEL register was cleared already in the crb_cancel
    callback, which has two consequences:
    
    * Cancel might not happen.
    * req_canceled() always returns zero.
    
    A better place to clear the register is when starting to send a new
    command. The behavior of TPM_CRB_CTRL_CANCEL is described in the
    section 5.5.3.6 of the PTP specification.
    
    Fixes: 30fc8d138e91 ("tpm: TPM 2.0 CRB Interface")
    Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 17b6c49b083c73bcb84205afd3e6d6b6a7b19459
Author: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
Date:   Tue Aug 16 22:00:38 2016 +0300

    tpm: fix a race condition in tpm2_unseal_trusted()
    
    commit d4816edfe706497a8525480c1685ceb9871bc118 upstream.
    
    Unseal and load operations should be done as an atomic operation. This
    commit introduces unlocked tpm_transmit() so that tpm2_unseal_trusted()
    can do the locking by itself.
    
    Fixes: 0fe5480303a1 ("keys, trusted: seal/unseal with TPM 2.0 chips")
    Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
    Reviewed-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit a8284cfff8f1115ec048c8127bbc34c224e33076
Author: Miklos Szeredi <mszeredi@redhat.com>
Date:   Fri Sep 16 12:44:20 2016 +0200

    ima: use file_dentry()
    
    commit e71b9dff0634edb127f449e076e883ef24a8c76c upstream.
    
    Ima tries to call ->setxattr() on overlayfs dentry after having locked
    underlying inode, which results in a deadlock.
    
    Reported-by: Krisztian Litkey <kli@iki.fi>
    Fixes: 4bacc9c9234c ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
    Signed-off-by: Miklos Szeredi <mszeredi@redhat.com>
    Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 8af6ecc2dbb44c59949cd157598aec59276c98e1
Author: Dmitry Tunin <hanipouspilot@gmail.com>
Date:   Wed Sep 21 19:13:08 2016 +0300

    Bluetooth: Add a new 04ca:3011 QCA_ROME device
    
    commit 1144a4eed04b2c3e7d20146d1b76f7669b55971d upstream.
    
    BugLink: https://bugs.launchpad.net/bugs/1535802
    
    T:  Bus=01 Lev=02 Prnt=02 Port=04 Cnt=01 Dev#=  3 Spd=12  MxCh= 0
    D:  Ver= 1.10 Cls=e0(wlcon) Sub=01 Prot=01 MxPS=64 #Cfgs=  1
    P:  Vendor=04ca ProdID=3011 Rev=00.01
    C:  #Ifs= 2 Cfg#= 1 Atr=e0 MxPwr=100mA
    I:  If#= 0 Alt= 0 #EPs= 3 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    I:  If#= 1 Alt= 0 #EPs= 2 Cls=e0(wlcon) Sub=01 Prot=01 Driver=btusb
    
    Signed-off-by: Dmitry Tunin <hanipouspilot@gmail.com>
    Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ec07719bcdd332849411d57d17608dadfd0bd136
Author: Christophe Jaillet <christophe.jaillet@wanadoo.fr>
Date:   Thu Aug 11 15:02:30 2016 +0200

    ARM: cpuidle: Fix error return code
    
    commit af48d7bc3756a0cd882d65bff14ab39746ba57fe upstream.
    
    We know that 'ret = 0' because it has been tested a few lines above.
    So, if 'kzalloc' fails, 0 will be returned instead of an error code.
    Return -ENOMEM instead.
    
    Fixes: a0d46a3dfdc3 ("ARM: cpuidle: Register per cpuidle device")
    Signed-off-by: Christophe Jaillet <christophe.jaillet@wanadoo.fr>
    Acked-by: Lorenzo Pieralisi <lorenzo.pieralisi@arm.com>
    Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88277ac7c8682d2148351e5eccee76a6bee711f0
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Fri Aug 5 10:38:38 2016 +0200

    ARM: dts: MSM8660 remove flags from SPMI/MPP IRQs
    
    commit dcf5907e0e09a160a57160729f920add5df8e358 upstream.
    
    The Qualcomm SPMI GPIO and MPP lines are problematic: the
    are fetched from the main MFD driver with platform_get_irq()
    which means that at this point they will all be assigned the
    flags set up for the interrupts in the device tree.
    
    That is problematic since these are flagged as rising edge
    and an this point the interrupt descriptor is assigned a
    rising edge, while the only thing the GPIO/MPP drivers really
    do is issue irq_get_irqchip_state() on the line to read it
    out and to provide a .to_irq() helper for *other* IRQ
    consumers.
    
    If another device tree node tries to flag the same IRQ
    for use as something else than rising edge, the kernel
    irqdomain core will protest like this:
    
      type mismatch, failed to map hwirq-NN for <FOO>!
    
    Which is what happens when the device tree defines two
    contradictory flags for the same interrupt line.
    
    To work around this and alleviate the problem, assign 0
    as flag for the interrupts taken by the PM GPIO and MPP
    drivers. This will lead to the flag being unset, and a
    second consumer requesting rising, falling, both or level
    interrupts will be respected. This is what the qcom-pm*.dtsi
    files already do.
    
    Switched to using the symbolic name IRQ_TYPE_NONE so that
    we get this more readable.
    
    This misconfiguration was caused by a copy/pasting the
    APQ8064 set-up, the latter has been fixed in a separate
    patch.
    
    Tested with one of the SPMI GPIOs: after this I can
    successfully request one of these GPIOs as falling edge
    from the device tree.
    
    Fixes: 0840ea9e4457 ("ARM: dts: add GPIO and MPP to MSM8660 PMIC")
    Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Cc: Stephen Boyd <sboyd@codeaurora.org>
    Cc: Björn Andersson <bjorn.andersson@linaro.org>
    Cc: Ivan T. Ivanov <ivan.ivanov@linaro.org>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: Andy Gross <andy.gross@linaro.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Andy Gross <andy.gross@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 150b065da3125872b8a8f0808c712332f25ee425
Author: Linus Walleij <linus.walleij@linaro.org>
Date:   Fri Aug 5 10:38:37 2016 +0200

    ARM: dts: MSM8064 remove flags from SPMI/MPP IRQs
    
    commit ca88696e8b73a9fa2b1de445747e9235c3a7bd50 upstream.
    
    The Qualcomm PMIC GPIO and MPP lines are problematic: the
    are fetched from the main MFD driver with platform_get_irq()
    which means that at this point they will all be assigned the
    flags set up for the interrupts in the device tree.
    
    That is problematic since these are flagged as rising edge
    and an this point the interrupt descriptor is assigned a
    rising edge, while the only thing the GPIO/MPP drivers really
    do is issue irq_get_irqchip_state() on the line to read it
    out and to provide a .to_irq() helper for *other* IRQ
    consumers.
    
    If another device tree node tries to flag the same IRQ
    for use as something else than rising edge, the kernel
    irqdomain core will protest like this:
    
      type mismatch, failed to map hwirq-NN for <FOO>!
    
    Which is what happens when the device tree defines two
    contradictory flags for the same interrupt line.
    
    To work around this and alleviate the problem, assign 0
    as flag for the interrupts taken by the PM GPIO and MPP
    drivers. This will lead to the flag being unset, and a
    second consumer requesting rising, falling, both or level
    interrupts will be respected. This is what the qcom-pm*.dtsi
    files already do.
    
    Switched to using the symbolic name IRQ_TYPE_NONE so that
    we get this more readable.
    
    Fixes: bce360469676 ("ARM: dts: apq8064: add pm8921 mpp support")
    Fixes: 874443fe9e33 ("ARM: dts: apq8064: Add pm8921 mfd and its gpio node")
    Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
    Cc: Stephen Boyd <sboyd@codeaurora.org>
    Cc: Björn Andersson <bjorn.andersson@linaro.org>
    Cc: Ivan T. Ivanov <ivan.ivanov@linaro.org>
    Cc: John Stultz <john.stultz@linaro.org>
    Cc: Andy Gross <andy.gross@linaro.org>
    Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
    Signed-off-by: Andy Gross <andy.gross@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c018058de785a6555ceed5920a160a3cb81fa0f9
Author: Grzegorz Jaszczyk <jaz@semihalf.com>
Date:   Thu Aug 4 12:14:08 2016 +0200

    ARM: dts: mvebu: armada-390: add missing compatibility string and bracket
    
    commit 061492cfad9f11dbc32df741a7164f307b69b6e6 upstream.
    
    The armada-390.dtsi was broken since the first patch which adds Device Tree
    files for Armada 39x SoC was introduced.
    
    Signed-off-by: Grzegorz Jaszczyk <jaz@semihalf.com>
    Acked-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
    Fixes 538da83 ("ARM: mvebu: add Device Tree files for Armada 39x SoC and board")
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
    
    Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>

commit 47d2e117d6463a5a9ac36f1391ce31a9a34929c8
Author: Russell King <rmk+kernel@armlinux.org.uk>
Date:   Wed Oct 5 23:40:43 2016 +0100

    ARM: fix delays
    
    commit fb833b1fbb68461772dbf5e91bddea5e839187e9 upstream.
    
    Commit 215e362dafed ("ARM: 8306/1: loop_udelay: remove bogomips value
    limitation") tried to increase the bogomips limitation, but in doing
    so messed up udelay such that it always gives about a 5% error in the
    delay, even if we use a timer.
    
    The calculation is:
    
            loops = UDELAY_MULT * us_delay * ticks_per_jiffy >> UDELAY_SHIFT
    
    Originally, UDELAY_MULT was ((UL(2199023) * HZ) >> 11) and UDELAY_SHIFT
    30.  Assuming HZ=100, us_delay of 1000 and ticks_per_jiffy of 1660000
    (eg, 166MHz timer, 1ms delay) this would calculate:
    
            ((UL(2199023) * HZ) >> 11) * 1000 * 1660000 >> 30
                    => 165999
    
    With the new values of 2047 * HZ + 483648 * HZ / 1000000 and 31, we get:
    
            (2047 * HZ + 483648 * HZ / 1000000) * 1000 * 1660000 >> 31
                    => 158269
    
    which is incorrect.  This is due to a typo - correcting it gives:
    
            (2147 * HZ + 483648 * HZ / 1000000) * 1000 * 1660000 >> 31
                    => 165999
    
    i.o.w, the original value.
    
    Fixes: 215e362dafed ("ARM: 8306/1: loop_udelay: remove bogomips value limitation")
    Reviewed-by: Nicolas Pitre <nico@linaro.org>
    Signed-off-by: Russell King <rmk+kernel@armlinux.org.uk>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 73933444b82e46faaa74055b36acee975a898ac9
Author: Josh Poimboeuf <jpoimboe@redhat.com>
Date:   Thu Aug 18 10:59:06 2016 -0500

    x86/dumpstack: Fix x86_32 kernel_stack_pointer() previous stack access
    
    commit 72b4f6a5e903b071f2a7c4eb1418cbe4eefdc344 upstream.
    
    On x86_32, when an interrupt happens from kernel space, SS and SP aren't
    pushed and the existing stack is used.  So pt_regs is effectively two
    words shorter, and the previous stack pointer is normally the memory
    after the shortened pt_regs, aka '&regs->sp'.
    
    But in the rare case where the interrupt hits right after the stack
    pointer has been changed to point to an empty stack, like for example
    when call_on_stack() is used, the address immediately after the
    shortened pt_regs is no longer on the stack.  In that case, instead of
    '&regs->sp', the previous stack pointer should be retrieved from the
    beginning of the current stack page.
    
    kernel_stack_pointer() wants to do that, but it forgets to dereference
    the pointer.  So instead of returning a pointer to the previous stack,
    it returns a pointer to the beginning of the current stack.
    
    Note that it's probably outside of kernel_stack_pointer()'s scope to be
    switching stacks at all.  The x86_64 version of this function doesn't do
    it, and it would be better for the caller to do it if necessary.  But
    that's a patch for another day.  This just fixes the original intent.
    
    Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
    Cc: Andy Lutomirski <luto@amacapital.net>
    Cc: Andy Lutomirski <luto@kernel.org>
    Cc: Borislav Petkov <bp@alien8.de>
    Cc: Brian Gerst <brgerst@gmail.com>
    Cc: Byungchul Park <byungchul.park@lge.com>
    Cc: Denys Vlasenko <dvlasenk@redhat.com>
    Cc: Frederic Weisbecker <fweisbec@gmail.com>
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Kees Cook <keescook@chromium.org>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Nilay Vaish <nilayvaish@gmail.com>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Fixes: 0788aa6a23cb ("x86: Prepare removal of previous_esp from i386 thread_info structure")
    Link: http://lkml.kernel.org/r/472453d6e9f6a2d4ab16aaed4935f43117111566.1471535549.git.jpoimboe@redhat.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 36fc8758ef87039b33840f2761e6776dcda03645
Author: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
Date:   Sat Sep 10 20:30:45 2016 +0200

    x86/mm/pkeys: Do not skip PKRU register if debug registers are not used
    
    commit ba6d018e3d2f6a0fad58a668cadf66b2d1f80f59 upstream.
    
    __show_regs() fails to dump the PKRU state when the debug registers are in
    their default state because there is a return statement on the debug
    register state.
    
    Change the logic to report PKRU value even when debug registers are in
    their default state.
    
    Fixes:c0b17b5bd4b7 ("x86/mm/pkeys: Dump PKRU with other kernel registers")
    Signed-off-by: Nicolas Iooss <nicolas.iooss_linux@m4x.org>
    Acked-by: Dave Hansen <dave.hansen@linux.intel.com>
    Link: http://lkml.kernel.org/r/20160910183045.4618-1-nicolas.iooss_linux@m4x.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0480b221143bfaefd4a65f885cd7ba81459d968a
Author: Prarit Bhargava <prarit@redhat.com>
Date:   Mon Oct 3 13:07:12 2016 -0400

    arch/x86: Handle non enumerated CPU after physical hotplug
    
    commit 2a51fe083eba7f99cbda72f5ef90cdf2f4df882c upstream.
    
    When a CPU is physically added to a system then the MADT table is not
    updated.
    
    If subsequently a kdump kernel is started on that physically added CPU then
    the ACPI enumeration fails to provide the information for this CPU which is
    now the boot CPU of the kdump kernel.
    
    As a consequence, generic_processor_info() is not invoked for that CPU so
    the number of enumerated processors is 0 and none of the initializations,
    including the logical package id management, are performed.
    
    We have code which relies on the correctness of the logical package map and
    other information which is initialized via generic_processor_info().
    Executing such code will result in undefined behaviour or kernel crashes.
    
    This problem applies only to the kdump kernel because a normal kexec will
    switch to the original boot CPU, which is enumerated in MADT, before
    jumping into the kexec kernel.
    
    The boot code already has a check for num_processors equal 0 in
    prefill_possible_map(). We can use that check as an indicator that the
    enumeration of the boot CPU did not happen and invoke generic_processor_info()
    for it. That initializes the relevant data for the boot CPU and therefore
    prevents subsequent failure.
    
    [ tglx: Refined the code and rewrote the changelog ]
    
    Signed-off-by: Prarit Bhargava <prarit@redhat.com>
    Fixes: 1f12e32f4cd5 ("x86/topology: Create logical package id")
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Len Brown <len.brown@intel.com>
    Cc: Borislav Petkov <bp@suse.de>
    Cc: Andi Kleen <ak@linux.intel.com>
    Cc: Jiri Olsa <jolsa@redhat.com>
    Cc: Juergen Gross <jgross@suse.com>
    Cc: dyoung@redhat.com
    Cc: Eric Biederman <ebiederm@xmission.com>
    Cc: kexec@lists.infradead.org
    Link: http://lkml.kernel.org/r/1475514432-27682-1-git-send-email-prarit@redhat.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 720aa4d9794f14940c38ada893ab9f2a2107b562
Author: Denys Vlasenko <dvlasenk@redhat.com>
Date:   Tue Sep 13 20:12:32 2016 +0200

    x86/apic: Get rid of apic_version[] array
    
    commit cff9ab2b291e64259d97add48fe073c081afe4e2 upstream.
    
    The array has a size of MAX_LOCAL_APIC, which can be as large as 32k, so it
    can consume up to 128k.
    
    The array has been there forever and was never used for anything useful
    other than a version mismatch check which was introduced in 2009.
    
    There is no reason to store the version in an array. The kernel is not
    prepared to handle different APIC versions anyway, so the real important
    part is to detect a version mismatch and warn about it, which can be done
    with a single variable as well.
    
    [ tglx: Massaged changelog ]
    
    Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
    CC: Andy Lutomirski <luto@amacapital.net>
    CC: Borislav Petkov <bp@alien8.de>
    CC: Brian Gerst <brgerst@gmail.com>
    CC: Mike Travis <travis@sgi.com>
    Link: http://lkml.kernel.org/r/20160913181232.30815-1-dvlasenk@redhat.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4c31498751b65ed0944497fc6e666cccb9116727
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Sep 8 13:32:32 2016 +0300

    x86/platform/intel-mid: Keep SRAM powered on at boot
    
    commit f43ea76cf310c3be95cb75ae1350cbe76a8f2380 upstream.
    
    On Penwell SRAM has to be powered on, otherwise it prevents booting.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Fixes: ca22312dc840 ("x86/platform/intel-mid: Extend PWRMU to support Penwell")
    Link: http://lkml.kernel.org/r/20160908103232.137587-2-andriy.shevchenko@linux.intel.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 768235b2aa428f11c60244192ab8bc7cf878e848
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Thu Sep 8 13:32:31 2016 +0300

    x86/platform/intel-mid: Add Intel Penwell to ID table
    
    commit 8e522e1d321b12829960c9b26668c92f14c68d7f upstream.
    
    Commit:
    
      ca22312dc840 ("x86/platform/intel-mid: Extend PWRMU to support Penwell")
    
    ... enabled the PWRMU driver on platforms based on Intel Penwell, but
    unfortunately this is not enough.
    
    Add Intel Penwell ID to pci-mid.c driver as well. To avoid confusion in the
    future add a comment to both drivers.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Fixes: ca22312dc840 ("x86/platform/intel-mid: Extend PWRMU to support Penwell")
    Link: http://lkml.kernel.org/r/20160908103232.137587-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 70c6cb0fad11723faa593da3e952c2c7386bb7e4
Author: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date:   Tue Sep 6 21:42:54 2016 +0300

    x86/cpu: Rename Merrifield2 to Moorefield
    
    commit f5fbf848303c8704d0e1a1e7cabd08fd0a49552f upstream.
    
    Merrifield2 is actually Moorefield.
    
    Rename it accordingly and drop tail digit from Merrifield1.
    
    Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
    Cc: Dave Hansen <dave.hansen@linux.intel.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/20160906184254.94440-1-andriy.shevchenko@linux.intel.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6a667db201271fbf33f3524fea3121eab41699ed
Author: Dave Hansen <dave.hansen@intel.com>
Date:   Fri Oct 7 09:23:42 2016 -0700

    x86/pkeys: Make protection keys an "eager" feature
    
    commit d4b05923f579c234137317cdf9a5eb69ddab76d1 upstream.
    
    Our XSAVE features are divided into two categories: those that
    generate FPU exceptions, and those that do not.  MPX and pkeys do
    not generate FPU exceptions and thus can not be used lazily.  We
    disable them when lazy mode is forced on.
    
    We have a pair of masks to collect these two sets of features, but
    XFEATURE_MASK_PKRU was added to the wrong mask: XFEATURE_MASK_LAZY.
    Fix it by moving the feature to XFEATURE_MASK_EAGER.
    
    Note: this only causes problem if you boot with lazy FPU mode
    (eagerfpu=off) which is *not* the default.  It also only affects
    hardware which is not currently publicly available.  It looks like
    eager mode is going away, but we still need this patch applied
    to any kernel that has protection keys and lazy mode, which is 4.6
    through 4.8 at this point, and 4.9 if the lazy removal isn't sent
    to Linus for 4.9.
    
    Fixes: c8df40098451 ("x86/fpu, x86/mm/pkeys: Add PKRU xsave fields and data structures")
    Signed-off-by: Dave Hansen <dave.hansen@intel.com>
    Cc: Dave Hansen <dave@sr71.net>
    Link: http://lkml.kernel.org/r/20161007162342.28A49813@viggo.jf.intel.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit b36aa5799251720407192800943ed451885f9a24
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date:   Mon Oct 3 13:17:08 2016 +0300

    x86/irq: Prevent force migration of irqs which are not in the vector domain
    
    commit db91aa793ff984ac048e199ea1c54202543952fe upstream.
    
    When a CPU is about to be offlined we call fixup_irqs() that resets IRQ
    affinities related to the CPU in question. The same thing is also done when
    the system is suspended to S-states like S3 (mem).
    
    For each IRQ we try to complete any on-going move regardless whether the
    IRQ is actually part of x86_vector_domain. For each IRQ descriptor we fetch
    its chip_data, assume it is of type struct apic_chip_data and manipulate it
    by clearing old_domain mask etc. For irq_chips that are not part of the
    x86_vector_domain, like those created by various GPIO drivers, will find
    their chip_data being changed unexpectly.
    
    Below is an example where GPIO chip owned by pinctrl-sunrisepoint.c gets
    corrupted after resume:
    
      # cat /sys/kernel/debug/gpio
      gpiochip0: GPIOs 360-511, parent: platform/INT344B:00, INT344B:00:
       gpio-511 (                    |sysfs               ) in  hi
    
      # rtcwake -s10 -mmem
      <10 seconds passes>
    
      # cat /sys/kernel/debug/gpio
      gpiochip0: GPIOs 360-511, parent: platform/INT344B:00, INT344B:00:
       gpio-511 (                    |sysfs               ) in  ?
    
    Note '?' in the output. It means the struct gpio_chip ->get function is
    NULL whereas before suspend it was there.
    
    Fix this by first checking that the IRQ belongs to x86_vector_domain before
    we try to use the chip_data as struct apic_chip_data.
    
    Reported-and-tested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
    Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
    Link: http://lkml.kernel.org/r/20161003101708.34795-1-mika.westerberg@linux.intel.com
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebf5f663edb53d85c1db13d5854a607b6c241d9d
Author: Dan Williams <dan.j.williams@intel.com>
Date:   Wed Sep 21 12:50:45 2016 -0700

    x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation
    
    commit 917db484dc6a69969d317b3e57add4208a8d9d42 upstream.
    
    In commit:
    
      ec776ef6bbe1 ("x86/mm: Add support for the non-standard protected e820 type")
    
    Christoph references the original patch I wrote implementing pmem support.
    The intent of the 'max_pfn' changes in that commit were to enable persistent
    memory ranges to be covered by the struct page memmap by default.
    
    However, that approach was abandoned when Christoph ported the patches [1], and
    that functionality has since been replaced by devm_memremap_pages().
    
    In the meantime, this max_pfn manipulation is confusing kdump [2] that
    assumes that everything covered by the max_pfn is "System RAM".  This
    results in kdump hanging or crashing.
    
     [1]: https://lists.01.org/pipermail/linux-nvdimm/2015-March/000348.html
     [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1351098
    
    So fix it.
    
    Reported-by: Zhang Yi <yizhan@redhat.com>
    Reported-by: Jeff Moyer <jmoyer@redhat.com>
    Tested-by: Zhang Yi <yizhan@redhat.com>
    Signed-off-by: Dan Williams <dan.j.williams@intel.com>
    Reviewed-by: Jeff Moyer <jmoyer@redhat.com>
    Cc: Andrew Morton <akpm@linux-foundation.org>
    Cc: Boaz Harrosh <boaz@plexistor.com>
    Cc: Christoph Hellwig <hch@lst.de>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Ross Zwisler <ross.zwisler@linux.intel.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Cc: linux-nvdimm@lists.01.org
    Fixes: ec776ef6bbe1 ("x86/mm: Add support for the non-standard protected e820 type")
    Link: http://lkml.kernel.org/r/147448744538.34910.11287693517367139607.stgit@dwillia2-desk3.amr.corp.intel.com
    Signed-off-by: Ingo Molnar <mingo@kernel.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0efaa26dabcd50d6bf11e5502229fb9ab02fe35e
Author: Mark Rutland <mark.rutland@arm.com>
Date:   Fri Sep 23 17:55:05 2016 +0100

    arm64: fix dump_backtrace/unwind_frame with NULL tsk
    
    commit b5e7307d9d5a340d2c9fabbe1cee137d4c682c71 upstream.
    
    In some places, dump_backtrace() is called with a NULL tsk parameter,
    e.g. in bug_handler() in arch/arm64, or indirectly via show_stack() in
    core code. The expectation is that this is treated as if current were
    passed instead of NULL. Similar is true of unwind_frame().
    
    Commit a80a0eb70c358f8c ("arm64: make irq_stack_ptr more robust") didn't
    take this into account. In dump_backtrace() it compares tsk against
    current *before* we check if tsk is NULL, and in unwind_frame() we never
    set tsk if it is NULL.
    
    Due to this, we won't initialise irq_stack_ptr in either function. In
    dump_backtrace() this results in calling dump_mem() for memory
    immediately above the IRQ stack range, rather than for the relevant
    range on the task stack. In unwind_frame we'll reject unwinding frames
    on the IRQ stack.
    
    In either case this results in incomplete or misleading backtrace
    information, but is not otherwise problematic. The initial percpu areas
    (including the IRQ stacks) are allocated in the linear map, and dump_mem
    uses __get_user(), so we shouldn't access anything with side-effects,
    and will handle holes safely.
    
    This patch fixes the issue by having both functions handle the NULL tsk
    case before doing anything else with tsk.
    
    Signed-off-by: Mark Rutland <mark.rutland@arm.com>
    Fixes: a80a0eb70c358f8c ("arm64: make irq_stack_ptr more robust")
    Acked-by: James Morse <james.morse@arm.com>
    Cc: Catalin Marinas <catalin.marinas@arm.com>
    Cc: Will Deacon <will.deacon@arm.com>
    Cc: Yang Shi <yang.shi@linaro.org>
    Signed-off-by: Will Deacon <will.deacon@arm.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c9eb7cf7f1d5724c7124d09eaa8737c264bc13a1
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Jul 14 13:15:46 2016 +0300

    KVM: PPC: BookE: Fix a sanity check
    
    commit ac0e89bb4744d3882ccd275f2416d9ce22f4e1e7 upstream.
    
    We use logical negate where bitwise negate was intended.  It means that
    we never return -EINVAL here.
    
    Fixes: ce11e48b7fdd ('KVM: PPC: E500: Add userspace debug stub support')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Reviewed-by: Alexander Graf <agraf@suse.de>
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ebc12d64e70139b9d5720914d62e5efba295d98f
Author: Christoffer Dall <christoffer.dall@linaro.org>
Date:   Tue Sep 27 18:53:35 2016 +0200

    KVM: arm/arm64: vgic: Don't flush/sync without a working vgic
    
    commit 0099b7701f5296a758d9e6b945ec96f96847cc2f upstream.
    
    If the vgic hasn't been created and initialized, we shouldn't attempt to
    look at its data structures or flush/sync anything to the GIC hardware.
    
    This fixes an issue reported by Alexander Graf when using a userspace
    irqchip.
    
    Fixes: 0919e84c0fc1 ("KVM: arm/arm64: vgic-new: Add IRQ sync/flush framework")
    Reported-by: Alexander Graf <agraf@suse.de>
    Acked-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 46848795ad096ece83489bbc8f6c8f32f42b21e8
Author: Christoffer Dall <christoffer.dall@linaro.org>
Date:   Mon Sep 26 18:51:47 2016 -0700

    KVM: arm64: Require in-kernel irqchip for PMU support
    
    commit 6fe407f2d18a4f94216263f91cb7d1f08fa5887c upstream.
    
    If userspace creates a PMU for the VCPU, but doesn't create an in-kernel
    irqchip, then we end up in a nasty path where we try to take an
    uninitialized spinlock, which can lead to all sorts of breakages.
    
    Luckily, QEMU always creates the VGIC before the PMU, so we can
    establish this as ABI and check for the VGIC in the PMU init stage.
    This can be relaxed at a later time if we want to support PMU with a
    userspace irqchip.
    
    Cc: Shannon Zhao <shannon.zhao@linaro.org>
    Acked-by: Marc Zyngier <marc.zyngier@arm.com>
    Signed-off-by: Christoffer Dall <christoffer.dall@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 92b23841fcf85e3fe85b7ee70418965b404d5754
Author: James Hogan <james.hogan@imgtec.com>
Date:   Thu Sep 15 17:20:06 2016 +0100

    KVM: MIPS: Drop other CPU ASIDs on guest MMU changes
    
    commit 91e4f1b6073dd680d86cdb7e42d7cccca9db39d8 upstream.
    
    When a guest TLB entry is replaced by TLBWI or TLBWR, we only invalidate
    TLB entries on the local CPU. This doesn't work correctly on an SMP host
    when the guest is migrated to a different physical CPU, as it could pick
    up stale TLB mappings from the last time the vCPU ran on that physical
    CPU.
    
    Therefore invalidate both user and kernel host ASIDs on other CPUs,
    which will cause new ASIDs to be generated when it next runs on those
    CPUs.
    
    We're careful only to do this if the TLB entry was already valid, and
    only for the kernel ASID where the virtual address it mapped is outside
    of the guest user address range.
    
    Signed-off-by: James Hogan <james.hogan@imgtec.com>
    Cc: Paolo Bonzini <pbonzini@redhat.com>
    Cc: "Radim Krčmář" <rkrcmar@redhat.com>
    Cc: Ralf Baechle <ralf@linux-mips.org>
    Cc: linux-mips@linux-mips.org
    Cc: kvm@vger.kernel.org
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 759896fa82e0e26ed7c048434723565f5d74ee04
Author: Thomas Huth <thuth@redhat.com>
Date:   Wed Sep 21 15:06:45 2016 +0200

    KVM: PPC: Book3s PR: Allow access to unprivileged MMCR2 register
    
    commit fa73c3b25bd8d0d393dc6109a1dba3c2aef0451e upstream.
    
    The MMCR2 register is available twice, one time with number 785
    (privileged access), and one time with number 769 (unprivileged,
    but it can be disabled completely). In former times, the Linux
    kernel was using the unprivileged register 769 only, but since
    commit 8dd75ccb571f3c92c ("powerpc: Use privileged SPR number
    for MMCR2"), it uses the privileged register 785 instead.
    The KVM-PR code then of course also switched to use the SPR 785,
    but this is causing older guest kernels to crash, since these
    kernels still access 769 instead. So to support older kernels
    with KVM-PR again, we have to support register 769 in KVM-PR, too.
    
    Fixes: 8dd75ccb571f3c92c48014b3dabd3d51a115ab41
    Signed-off-by: Thomas Huth <thuth@redhat.com>
    Signed-off-by: Paul Mackerras <paulus@ozlabs.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 88540ad0820ddfb05626e0136c0e5a79cea85fd1
Author: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date:   Wed Oct 5 13:09:33 2016 -0400

    xen/x86: Update topology map for PV VCPUs
    
    commit a6a198bc60e6c980a56eca24d33dc7f29139f8ea upstream.
    
    Early during boot topology_update_package_map() computes
    logical_pkg_ids for all present processors.
    
    Later, when processors are brought up, identify_cpu() updates
    these values based on phys_pkg_id which is a function of
    initial_apicid. On PV guests the latter may point to a
    non-existing node, causing logical_pkg_ids to be set to -1.
    
    Intel's RAPL uses logical_pkg_id (as topology_logical_package_id())
    to index its arrays and therefore in this case will point to index
    65535 (since logical_pkg_id is a u16). This could lead to either a
    crash or may actually access random memory location.
    
    As a workaround, we recompute topology during CPU bringup to reset
    logical_pkg_id to a valid value.
    
    (The reason for initial_apicid being bogus is because it is
    initial_apicid of the processor from which the guest is launched.
    This value is CPUID(1).EBX[31:24])
    
    Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
    Signed-off-by: David Vrabel <david.vrabel@citrix.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c64c7600e60086b658250b9f80b18cb959ed7b0f
Author: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Date:   Fri Jul 29 21:29:15 2016 +0200

    mfd: wm8350-i2c: Make sure the i2c regmap functions are compiled
    
    commit 88003fb10f1fc606e1704611c62ceae95fd1d7da upstream.
    
    This fixes a compile failure:
    
            drivers/built-in.o: In function `wm8350_i2c_probe':
            core.c:(.text+0x828b0): undefined reference to `__devm_regmap_init_i2c'
            Makefile:953: recipe for target 'vmlinux' failed
    
    Fixes: 52b461b86a9f ("mfd: Add regmap cache support for wm8350")
    Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
    Acked-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ceeddeea91552a88740212224df7f425a0e9f1f6
Author: Dan Carpenter <dan.carpenter@oracle.com>
Date:   Thu Aug 4 08:26:56 2016 +0300

    mfd: 88pm80x: Double shifting bug in suspend/resume
    
    commit 9a6dc644512fd083400a96ac4a035ac154fe6b8d upstream.
    
    set_bit() and clear_bit() take the bit number so this code is really
    doing "1 << (1 << irq)" which is a double shift bug.  It's done
    consistently so it won't cause a problem unless "irq" is more than 4.
    
    Fixes: 70c6cce04066 ('mfd: Support 88pm80x in 80x driver')
    Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 0187dcdecf86887b011a3a0fce23b48e049b7ece
Author: Boris Brezillon <boris.brezillon@free-electrons.com>
Date:   Tue Sep 6 14:19:29 2016 +0200

    mfd: atmel-hlcdc: Do not sleep in atomic context
    
    commit 2c2469bc03d569c49119db2cccb5cb3f0c6a5b33 upstream.
    
    readl_poll_timeout() calls usleep_range(), but
    regmap_atmel_hlcdc_reg_write() is called in atomic context (regmap
    spinlock held).
    
    Replace the readl_poll_timeout() call by readl_poll_timeout_atomic().
    
    Fixes: ea31c0cf9b07 ("mfd: atmel-hlcdc: Implement config synchronization")
    Signed-off-by: Boris Brezillon <boris.brezillon@free-electrons.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 6c4c6ae5725b670d6470958bc99ee7022cd357ce
Author: Lu Baolu <baolu.lu@linux.intel.com>
Date:   Thu Aug 11 10:39:03 2016 +0800

    mfd: rtsx_usb: Avoid setting ucr->current_sg.status
    
    commit 8dcc5ff8fcaf778bb57ab4448fedca9e381d088f upstream.
    
    Member "status" of struct usb_sg_request is managed by usb core. A
    spin lock is used to serialize the change of it. The driver could
    check the value of req->status, but should avoid changing it without
    the hold of the spinlock. Otherwise, it could cause race or error
    in usb core.
    
    This patch could be backported to stable kernels with version later
    than v3.14.
    
    Cc: Alan Stern <stern@rowland.harvard.edu>
    Cc: Roger Tseng <rogerable@realtek.com>
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Lee Jones <lee.jones@linaro.org>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 14ca6ce4528d834c9c2abe4b3423e58df2390c0f
Author: Takashi Sakamoto <o-takashi@sakamocchi.jp>
Date:   Sun Sep 25 22:00:20 2016 +0900

    ALSA: usb-line6: use the same declaration as definition in header for MIDI manufacturer ID
    
    commit 8da08ca03b73593d5299893bf29fc08569c3fb5f upstream.
    
    Currently, usb-line6 module exports an array of MIDI manufacturer ID and
    usb-pod module uses it. However, the declaration is not the definition in
    common header. The difference is explicit length of array. Although
    compiler calculates it and everything goes well, it's better to use the
    same representation between definition and declaration.
    
    This commit fills the length of array for usb-line6 module. As a small
    good sub-effect, this commit suppress below warnings from static analysis
    by sparse v0.5.0.
    
    sound/usb/line6/driver.c:274:43: error: cannot size expression
    sound/usb/line6/driver.c:275:16: error: cannot size expression
    sound/usb/line6/driver.c:276:16: error: cannot size expression
    sound/usb/line6/driver.c:277:16: error: cannot size expression
    
    Fixes: 705ececd1c60 ("Staging: add line6 usb driver")
    Signed-off-by: Takashi Sakamoto <o-takashi@sakamocchi.jp>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit e09db64b3e100e7c021b8d34ef2f92c888eec95b
Author: Anssi Hannula <anssi.hannula@iki.fi>
Date:   Fri Sep 23 06:43:47 2016 +0300

    ALSA: usb-audio: Extend DragonFly dB scale quirk to cover other variants
    
    commit eb1a74b7bea17eea31915c4f76385cefe69d9795 upstream.
    
    The DragonFly quirk added in 42e3121d90f4 ("ALSA: usb-audio: Add a more
    accurate volume quirk for AudioQuest DragonFly") applies a custom dB map
    on the volume control when its range is reported as 0..50 (0 .. 0.2dB).
    
    However, there exists at least one other variant (hw v1.0c, as opposed
    to the tested v1.2) which reports a different non-sensical volume range
    (0..53) and the custom map is therefore not applied for that device.
    
    This results in all of the volume change appearing close to 100% on
    mixer UIs that utilize the dB TLV information.
    
    Add a fallback case where no dB TLV is reported at all if the control
    range is not 0..50 but still 0..N where N <= 1000 (3.9 dB). Also
    restrict the quirk to only apply to the volume control as there is also
    a mute control which would match the check otherwise.
    
    Fixes: 42e3121d90f4 ("ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly")
    Signed-off-by: Anssi Hannula <anssi.hannula@iki.fi>
    Reported-by: David W <regulars@d-dub.org.uk>
    Tested-by: David W <regulars@d-dub.org.uk>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 80e84e00f9c9acbea67bf8badd284ab033da2fbe
Author: Takashi Iwai <tiwai@suse.de>
Date:   Wed Sep 21 14:38:02 2016 +0200

    ALSA: ali5451: Fix out-of-bound position reporting
    
    commit db68577966abc1aeae4ec597b3dcfa0d56e92041 upstream.
    
    The pointer callbacks of ali5451 driver may return the value at the
    boundary occasionally, and it results in the kernel warning like
      snd_ali5451 0000:00:06.0: BUG: , pos = 16384, buffer size = 16384, period size = 1024
    
    It seems that folding the position offset is enough for fixing the
    warning and no ill-effect has been seen by that.
    
    Reported-by: Enrico Mioso <mrkiko.rs@gmail.com>
    Tested-by: Enrico Mioso <mrkiko.rs@gmail.com>
    Signed-off-by: Takashi Iwai <tiwai@suse.de>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 72c6187f03486fbc9e8d8a2aba5f7cb1eb9e8c71
Author: Chen-Yu Tsai <wens@csie.org>
Date:   Fri Sep 9 11:58:18 2016 +0800

    phy: sun4i-usb: Use spinlock to guard phyctl register access
    
    commit 919ab2524c52e5f801d8873f09145ce822cdd43a upstream.
    
    The musb driver calls into this phy driver to disable/enable squelch
    detection. This function was introduced in 24fe86a617c5 ("phy: sun4i-usb:
    Add a sunxi specific function for setting squelch-detect"). This
    function in turn calls sun4i_usb_phy_write, which uses a mutex to
    guard the common access register. Unfortunately musb does this
    in atomic context, which results in the following warning with lock
    debugging enabled:
    
    BUG: sleeping function called from invalid context at kernel/locking/mutex.c:97
    in_atomic(): 1, irqs_disabled(): 128, pid: 96, name: kworker/0:2
    CPU: 0 PID: 96 Comm: kworker/0:2 Not tainted 4.8.0-rc4-00181-gd502f8ad1c3e #13
    Hardware name: Allwinner sun8i Family
    Workqueue: events musb_deassert_reset
    [<c010bc01>] (unwind_backtrace) from [<c0109237>] (show_stack+0xb/0xc)
    [<c0109237>] (show_stack) from [<c02a669b>] (dump_stack+0x67/0x74)
    [<c02a669b>] (dump_stack) from [<c05d68c9>] (mutex_lock+0x15/0x2c)
    [<c05d68c9>] (mutex_lock) from [<c02c3589>] (sun4i_usb_phy_write+0x39/0xec)
    [<c02c3589>] (sun4i_usb_phy_write) from [<c03e6327>] (musb_port_reset+0xfb/0x184)
    [<c03e6327>] (musb_port_reset) from [<c03e4917>] (musb_deassert_reset+0x1f/0x2c)
    [<c03e4917>] (musb_deassert_reset) from [<c012ecb5>] (process_one_work+0x129/0x2b8)
    [<c012ecb5>] (process_one_work) from [<c012f5e3>] (worker_thread+0xf3/0x424)
    [<c012f5e3>] (worker_thread) from [<c0132dbd>] (kthread+0xa1/0xb8)
    [<c0132dbd>] (kthread) from [<c0105f31>] (ret_from_fork+0x11/0x20)
    
    Since the register access is mmio, we can use a spinlock to guard this
    specific access, rather than the mutex that guards the entire phy.
    
    Fixes: ba4bdc9e1dc0 ("PHY: sunxi: Add driver for sunxi usb phy")
    Cc: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Chen-Yu Tsai <wens@csie.org>
    Reviewed-by: Hans de Goede <hdegoede@redhat.com>
    Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit ac8aa11e3d184b4fee37f11b374799447d7f5fb5
Author: Lu Baolu <baolu.lu@linux.intel.com>
Date:   Fri Sep 9 12:51:27 2016 +0800

    usb: dwc3: fix Clear Stall EP command failure
    
    commit 5e6c88d28ccbe72bedee1fbf4f9fea4764208598 upstream.
    
    Commit 50c763f8c1bac ("usb: dwc3: Set the ClearPendIN bit on Clear
    Stall EP command") sets ClearPendIN bit for all IN endpoints of
    v2.60a+ cores. This causes ClearStall command fails on 2.60+ cores
    operating in HighSpeed mode.
    
    In page 539 of 2.60a specification:
    
    "When issuing Clear Stall command for IN endpoints in SuperSpeed
    mode, the software must set the "ClearPendIN" bit to '1' to
    clear any pending IN transcations, so that the device does not
    expect any ACK TP from the host for the data sent earlier."
    
    It's obvious that we only need to apply this rule to those IN
    endpoints that currently operating in SuperSpeed mode.
    
    Fixes: 50c763f8c1bac ("usb: dwc3: Set the ClearPendIN bit on Clear Stall EP command")
    Signed-off-by: Lu Baolu <baolu.lu@linux.intel.com>
    Signed-off-by: Felipe Balbi <felipe.balbi@linux.intel.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit 4e584cfe7da58834d8213d30049daaeb30bf0204
Author: John Stultz <john.stultz@linaro.org>
Date:   Tue Oct 4 19:55:48 2016 -0700

    timekeeping: Fix __ktime_get_fast_ns() regression
    
    commit 58bfea9532552d422bde7afa207e1a0f08dffa7d upstream.
    
    In commit 27727df240c7 ("Avoid taking lock in NMI path with
    CONFIG_DEBUG_TIMEKEEPING"), I changed the logic to open-code
    the timekeeping_get_ns() function, but I forgot to include
    the unit conversion from cycles to nanoseconds, breaking the
    function's output, which impacts users like perf.
    
    This results in bogus perf timestamps like:
     swapper     0 [000]   253.427536:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]   254.426573:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]   254.426687:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]   254.426800:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]   254.426905:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]   254.427022:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]   254.427127:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]   254.427239:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]   254.427346:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]   254.427463:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]   255.426572:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
    
    Instead of more reasonable expected timestamps like:
     swapper     0 [000]    39.953768:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]    40.064839:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]    40.175956:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]    40.287103:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]    40.398217:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]    40.509324:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]    40.620437:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]    40.731546:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]    40.842654:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]    40.953772:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
     swapper     0 [000]    41.064881:  111111111 cpu-clock:  ffffffff810a0de6 native_safe_halt+0x6 ([kernel.kallsyms])
    
    Add the proper use of timekeeping_delta_to_ns() to convert
    the cycle delta to nanoseconds as needed.
    
    Thanks to Brendan and Alexei for finding this quickly after
    the v4.8 release. Unfortunately the problematic commit has
    landed in some -stable trees so they'll need this fix as
    well.
    
    Many apologies for this mistake. I'll be looking to add a
    perf-clock sanity test to the kselftest timers tests soon.
    
    Fixes: 27727df240c7 "timekeeping: Avoid taking lock in NMI path with CONFIG_DEBUG_TIMEKEEPING"
    Reported-by: Brendan Gregg <bgregg@netflix.com>
    Reported-by: Alexei Starovoitov <alexei.starovoitov@gmail.com>
    Tested-and-reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: John Stultz <john.stultz@linaro.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Steven Rostedt <rostedt@goodmis.org>
    Link: http://lkml.kernel.org/r/1475636148-26539-1-git-send-email-john.stultz@linaro.org
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

commit c8661aaae7f119c7a8033f4d822686707e4c5d92
Author: Heiner Kallweit <hkallweit1@gmail.com>
Date:   Wed Aug 3 21:46:47 2016 +0200

    usb: storage: fix runtime pm issue in usb_stor_probe2
    
    commit a094760b9a77f81ee3cbeff323ee77c928f41106 upstream.
    
    Since commit 71723f95463d "PM / runtime: print error when activating a
    child to unactive parent" I see the following error message:
    
    scsi host2: usb-storage 1-3:1.0
    scsi host2: runtime PM trying to activate child device host2 but parent
                (1-3:1.0) is not active
    
    Digging into it it seems to be related to the problem described in the
    commit message for cd998ded5c12 "i2c: designware: Prevent runtime
    suspend during adapter registration" as scsi_add_host also calls
    device_add and after the call to device_add the parent device is
    suspended.
    
    Fix this by using the approach from the mentioned commit and getting
    the runtime pm reference before calling scsi_add_host.
    
    Signed-off-by: Heiner Kallweit <hkallweit1@gmail.com>
    Acked-by: Alan Stern <stern@rowland.harvard.edu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>