1. 22 Oct, 2016 24 commits
  2. 20 Oct, 2016 5 commits
  3. 16 Oct, 2016 11 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.8.2 · cb5d016a
      Greg Kroah-Hartman authored
      cb5d016a
    • Jarkko Sakkinen's avatar
      tpm_crb: fix crb_req_canceled behavior · 87d6616d
      Jarkko Sakkinen authored
      commit 72fd50e1 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: 30fc8d13 ("tpm: TPM 2.0 CRB Interface")
      Signed-off-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      87d6616d
    • Jarkko Sakkinen's avatar
      tpm: fix a race condition in tpm2_unseal_trusted() · 17b6c49b
      Jarkko Sakkinen authored
      commit d4816edf 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: 0fe54803 ("keys, trusted: seal/unseal with TPM 2.0 chips")
      Signed-off-by: default avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Reviewed-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      17b6c49b
    • Miklos Szeredi's avatar
      ima: use file_dentry() · a8284cff
      Miklos Szeredi authored
      commit e71b9dff upstream.
      
      Ima tries to call ->setxattr() on overlayfs dentry after having locked
      underlying inode, which results in a deadlock.
      Reported-by: default avatarKrisztian Litkey <kli@iki.fi>
      Fixes: 4bacc9c9 ("overlayfs: Make f_path always point to the overlay and f_inode to the underlay")
      Signed-off-by: default avatarMiklos Szeredi <mszeredi@redhat.com>
      Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a8284cff
    • Dmitry Tunin's avatar
      Bluetooth: Add a new 04ca:3011 QCA_ROME device · 8af6ecc2
      Dmitry Tunin authored
      commit 1144a4ee 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: default avatarDmitry Tunin <hanipouspilot@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8af6ecc2
    • Christophe Jaillet's avatar
      ARM: cpuidle: Fix error return code · ec07719b
      Christophe Jaillet authored
      commit af48d7bc 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: a0d46a3d ("ARM: cpuidle: Register per cpuidle device")
      Signed-off-by: default avatarChristophe Jaillet <christophe.jaillet@wanadoo.fr>
      Acked-by: default avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ec07719b
    • Linus Walleij's avatar
      ARM: dts: MSM8660 remove flags from SPMI/MPP IRQs · 88277ac7
      Linus Walleij authored
      commit dcf5907e 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: 0840ea9e ("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: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      88277ac7
    • Linus Walleij's avatar
      ARM: dts: MSM8064 remove flags from SPMI/MPP IRQs · 150b065d
      Linus Walleij authored
      commit ca88696e 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: bce36046 ("ARM: dts: apq8064: add pm8921 mpp support")
      Fixes: 874443fe ("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: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      150b065d
    • Grzegorz Jaszczyk's avatar
      ARM: dts: mvebu: armada-390: add missing compatibility string and bracket · c018058d
      Grzegorz Jaszczyk authored
      commit 061492cf 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: default avatarGrzegorz Jaszczyk <jaz@semihalf.com>
      Acked-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Fixes 538da83d ("ARM: mvebu: add Device Tree files for Armada 39x SoC and board")
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      c018058d
    • Russell King's avatar
      ARM: fix delays · 47d2e117
      Russell King authored
      commit fb833b1f upstream.
      
      Commit 215e362d ("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: 215e362d ("ARM: 8306/1: loop_udelay: remove bogomips value limitation")
      Reviewed-by: default avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: default avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      47d2e117
    • Josh Poimboeuf's avatar
      x86/dumpstack: Fix x86_32 kernel_stack_pointer() previous stack access · 73933444
      Josh Poimboeuf authored
      commit 72b4f6a5 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: default avatarJosh 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: 0788aa6a ("x86: Prepare removal of previous_esp from i386 thread_info structure")
      Link: http://lkml.kernel.org/r/472453d6e9f6a2d4ab16aaed4935f43117111566.1471535549.git.jpoimboe@redhat.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73933444