1. 20 Oct, 2016 1 commit
  2. 16 Oct, 2016 38 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 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: 30fc8d13 ("tpm: TPM 2.0 CRB Interface")
      Signed-off-by: 's avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Signed-off-by: 's 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 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: 0fe54803 ("keys, trusted: seal/unseal with TPM 2.0 chips")
      Signed-off-by: 's avatarJarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
      Reviewed-by: 's avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      17b6c49b
    • Miklos Szeredi's avatar
      ima: use file_dentry() · a8284cff
      Miklos Szeredi authored
      commit e71b9dff0634edb127f449e076e883ef24a8c76c upstream.
      
      Ima tries to call ->setxattr() on overlayfs dentry after having locked
      underlying inode, which results in a deadlock.
      Reported-by: 's 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: 's avatarMiklos Szeredi <mszeredi@redhat.com>
      Cc: Mimi Zohar <zohar@linux.vnet.ibm.com>
      Signed-off-by: 's 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 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: 's avatarDmitry Tunin <hanipouspilot@gmail.com>
      Signed-off-by: 's avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8af6ecc2
    • Christophe Jaillet's avatar
      ARM: cpuidle: Fix error return code · ec07719b
      Christophe Jaillet authored
      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: a0d46a3d ("ARM: cpuidle: Register per cpuidle device")
      Signed-off-by: 's avatarChristophe Jaillet <christophe.jaillet@wanadoo.fr>
      Acked-by: 's avatarLorenzo Pieralisi <lorenzo.pieralisi@arm.com>
      Signed-off-by: 's avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: 's 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 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: 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: 's avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: 's avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: 's 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 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: 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: 's avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: 's avatarAndy Gross <andy.gross@linaro.org>
      Signed-off-by: 's 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 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: 's avatarGrzegorz Jaszczyk <jaz@semihalf.com>
      Acked-by: 's avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      Fixes 538da83d ("ARM: mvebu: add Device Tree files for Armada 39x SoC and board")
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: 's avatarGregory CLEMENT <gregory.clement@free-electrons.com>
      c018058d
    • Russell King's avatar
      ARM: fix delays · 47d2e117
      Russell King authored
      commit fb833b1fbb68461772dbf5e91bddea5e839187e9 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: 's avatarNicolas Pitre <nico@linaro.org>
      Signed-off-by: 's avatarRussell King <rmk+kernel@armlinux.org.uk>
      Signed-off-by: 's 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 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: 's 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: 's avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      73933444
    • Nicolas Iooss's avatar
      x86/mm/pkeys: Do not skip PKRU register if debug registers are not used · 36fc8758
      Nicolas Iooss authored
      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:c0b17b5b ("x86/mm/pkeys: Dump PKRU with other kernel registers")
      Signed-off-by: 's avatarNicolas Iooss <nicolas.iooss_linux@m4x.org>
      Acked-by: 's avatarDave Hansen <dave.hansen@linux.intel.com>
      Link: http://lkml.kernel.org/r/20160910183045.4618-1-nicolas.iooss_linux@m4x.orgSigned-off-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      36fc8758
    • Prarit Bhargava's avatar
      arch/x86: Handle non enumerated CPU after physical hotplug · 0480b221
      Prarit Bhargava authored
      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: 's avatarPrarit Bhargava <prarit@redhat.com>
      Fixes: 1f12e32f ("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.comSigned-off-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0480b221
    • Denys Vlasenko's avatar
      x86/apic: Get rid of apic_version[] array · 720aa4d9
      Denys Vlasenko authored
      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: 's avatarDenys 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.comSigned-off-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      720aa4d9
    • Andy Shevchenko's avatar
      x86/platform/intel-mid: Keep SRAM powered on at boot · 4c314987
      Andy Shevchenko authored
      commit f43ea76cf310c3be95cb75ae1350cbe76a8f2380 upstream.
      
      On Penwell SRAM has to be powered on, otherwise it prevents booting.
      Signed-off-by: 's avatarAndy 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: ca22312d ("x86/platform/intel-mid: Extend PWRMU to support Penwell")
      Link: http://lkml.kernel.org/r/20160908103232.137587-2-andriy.shevchenko@linux.intel.comSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4c314987
    • Andy Shevchenko's avatar
      x86/platform/intel-mid: Add Intel Penwell to ID table · 768235b2
      Andy Shevchenko authored
      commit 8e522e1d321b12829960c9b26668c92f14c68d7f upstream.
      
      Commit:
      
        ca22312d ("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: 's avatarAndy 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: ca22312d ("x86/platform/intel-mid: Extend PWRMU to support Penwell")
      Link: http://lkml.kernel.org/r/20160908103232.137587-1-andriy.shevchenko@linux.intel.comSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      768235b2
    • Andy Shevchenko's avatar
      x86/cpu: Rename Merrifield2 to Moorefield · 70c6cb0f
      Andy Shevchenko authored
      commit f5fbf848303c8704d0e1a1e7cabd08fd0a49552f upstream.
      
      Merrifield2 is actually Moorefield.
      
      Rename it accordingly and drop tail digit from Merrifield1.
      Signed-off-by: 's avatarAndy 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.comSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      70c6cb0f
    • Dave Hansen's avatar
      x86/pkeys: Make protection keys an "eager" feature · 6a667db2
      Dave Hansen authored
      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: c8df4009 ("x86/fpu, x86/mm/pkeys: Add PKRU xsave fields and data structures")
      Signed-off-by: 's avatarDave Hansen <dave.hansen@intel.com>
      Cc: Dave Hansen <dave@sr71.net>
      Link: http://lkml.kernel.org/r/20161007162342.28A49813@viggo.jf.intel.comSigned-off-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6a667db2
    • Mika Westerberg's avatar
      x86/irq: Prevent force migration of irqs which are not in the vector domain · b36aa579
      Mika Westerberg authored
      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: 's avatarSakari Ailus <sakari.ailus@linux.intel.com>
      Signed-off-by: 's avatarMika Westerberg <mika.westerberg@linux.intel.com>
      Link: http://lkml.kernel.org/r/20161003101708.34795-1-mika.westerberg@linux.intel.comSigned-off-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b36aa579
    • Dan Williams's avatar
      x86/boot: Fix kdump, cleanup aborted E820_PRAM max_pfn manipulation · ebf5f663
      Dan Williams authored
      commit 917db484dc6a69969d317b3e57add4208a8d9d42 upstream.
      
      In commit:
      
        ec776ef6 ("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: 's avatarZhang Yi <yizhan@redhat.com>
      Reported-by: 's avatarJeff Moyer <jmoyer@redhat.com>
      Tested-by: 's avatarZhang Yi <yizhan@redhat.com>
      Signed-off-by: 's avatarDan Williams <dan.j.williams@intel.com>
      Reviewed-by: 's avatarJeff 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: ec776ef6 ("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.comSigned-off-by: 's avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ebf5f663
    • Mark Rutland's avatar
      arm64: fix dump_backtrace/unwind_frame with NULL tsk · 0efaa26d
      Mark Rutland authored
      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 a80a0eb7 ("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: 's avatarMark Rutland <mark.rutland@arm.com>
      Fixes: a80a0eb7 ("arm64: make irq_stack_ptr more robust")
      Acked-by: 's avatarJames 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: 's avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0efaa26d
    • Dan Carpenter's avatar
      KVM: PPC: BookE: Fix a sanity check · c9eb7cf7
      Dan Carpenter authored
      commit ac0e89bb4744d3882ccd275f2416d9ce22f4e1e7 upstream.
      
      We use logical negate where bitwise negate was intended.  It means that
      we never return -EINVAL here.
      
      Fixes: ce11e48b ('KVM: PPC: E500: Add userspace debug stub support')
      Signed-off-by: 's avatarDan Carpenter <dan.carpenter@oracle.com>
      Reviewed-by: 's avatarAlexander Graf <agraf@suse.de>
      Signed-off-by: 's avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c9eb7cf7
    • Christoffer Dall's avatar
      KVM: arm/arm64: vgic: Don't flush/sync without a working vgic · ebc12d64
      Christoffer Dall authored
      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: 0919e84c ("KVM: arm/arm64: vgic-new: Add IRQ sync/flush framework")
      Reported-by: 's avatarAlexander Graf <agraf@suse.de>
      Acked-by: 's avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: 's avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ebc12d64
    • Christoffer Dall's avatar
      KVM: arm64: Require in-kernel irqchip for PMU support · 46848795
      Christoffer Dall authored
      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: 's avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: 's avatarChristoffer Dall <christoffer.dall@linaro.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      46848795
    • James Hogan's avatar
      KVM: MIPS: Drop other CPU ASIDs on guest MMU changes · 92b23841
      James Hogan authored
      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: 's avatarJames 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: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      92b23841
    • Thomas Huth's avatar
      KVM: PPC: Book3s PR: Allow access to unprivileged MMCR2 register · 759896fa
      Thomas Huth authored
      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 8dd75ccb ("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: 8dd75ccbSigned-off-by: 's avatarThomas Huth <thuth@redhat.com>
      Signed-off-by: 's avatarPaul Mackerras <paulus@ozlabs.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      759896fa
    • Boris Ostrovsky's avatar
      xen/x86: Update topology map for PV VCPUs · 88540ad0
      Boris Ostrovsky authored
      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: 's avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: 's avatarDavid Vrabel <david.vrabel@citrix.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      88540ad0
    • Uwe Kleine-König's avatar
      mfd: wm8350-i2c: Make sure the i2c regmap functions are compiled · c64c7600
      Uwe Kleine-König authored
      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: 52b461b8 ("mfd: Add regmap cache support for wm8350")
      Signed-off-by: 's avatarUwe Kleine-König <u.kleine-koenig@pengutronix.de>
      Acked-by: 's avatarCharles Keepax <ckeepax@opensource.wolfsonmicro.com>
      Signed-off-by: 's avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c64c7600
    • Dan Carpenter's avatar
      mfd: 88pm80x: Double shifting bug in suspend/resume · ceeddeea
      Dan Carpenter authored
      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: 70c6cce0 ('mfd: Support 88pm80x in 80x driver')
      Signed-off-by: 's avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: 's avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ceeddeea
    • Boris Brezillon's avatar
      mfd: atmel-hlcdc: Do not sleep in atomic context · 0187dcde
      Boris Brezillon authored
      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: ea31c0cf ("mfd: atmel-hlcdc: Implement config synchronization")
      Signed-off-by: 's avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: 's avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0187dcde
    • Lu Baolu's avatar
      mfd: rtsx_usb: Avoid setting ucr->current_sg.status · 6c4c6ae5
      Lu Baolu authored
      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: 's avatarLu Baolu <baolu.lu@linux.intel.com>
      Signed-off-by: 's avatarLee Jones <lee.jones@linaro.org>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6c4c6ae5
    • Takashi Sakamoto's avatar
      ALSA: usb-line6: use the same declaration as definition in header for MIDI manufacturer ID · 14ca6ce4
      Takashi Sakamoto authored
      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: 705ececd ("Staging: add line6 usb driver")
      Signed-off-by: 's avatarTakashi Sakamoto <o-takashi@sakamocchi.jp>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      14ca6ce4
    • Anssi Hannula's avatar
      ALSA: usb-audio: Extend DragonFly dB scale quirk to cover other variants · e09db64b
      Anssi Hannula authored
      commit eb1a74b7bea17eea31915c4f76385cefe69d9795 upstream.
      
      The DragonFly quirk added in 42e3121d ("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: 42e3121d ("ALSA: usb-audio: Add a more accurate volume quirk for AudioQuest DragonFly")
      Signed-off-by: 's avatarAnssi Hannula <anssi.hannula@iki.fi>
      Reported-by: 's avatarDavid W <regulars@d-dub.org.uk>
      Tested-by: 's avatarDavid W <regulars@d-dub.org.uk>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e09db64b
    • Takashi Iwai's avatar
      ALSA: ali5451: Fix out-of-bound position reporting · 80e84e00
      Takashi Iwai authored
      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: 's avatarEnrico Mioso <mrkiko.rs@gmail.com>
      Tested-by: 's avatarEnrico Mioso <mrkiko.rs@gmail.com>
      Signed-off-by: 's avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80e84e00
    • Chen-Yu Tsai's avatar
      phy: sun4i-usb: Use spinlock to guard phyctl register access · 72c6187f
      Chen-Yu Tsai authored
      commit 919ab2524c52e5f801d8873f09145ce822cdd43a upstream.
      
      The musb driver calls into this phy driver to disable/enable squelch
      detection. This function was introduced in 24fe86a6 ("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: ba4bdc9e ("PHY: sunxi: Add driver for sunxi usb phy")
      Cc: Hans de Goede <hdegoede@redhat.com>
      Signed-off-by: 's avatarChen-Yu Tsai <wens@csie.org>
      Reviewed-by: 's avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: 's avatarKishon Vijay Abraham I <kishon@ti.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      72c6187f
    • Lu Baolu's avatar
      usb: dwc3: fix Clear Stall EP command failure · ac8aa11e
      Lu Baolu authored
      commit 5e6c88d28ccbe72bedee1fbf4f9fea4764208598 upstream.
      
      Commit 50c763f8 ("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: 50c763f8 ("usb: dwc3: Set the ClearPendIN bit on Clear Stall EP command")
      Signed-off-by: 's avatarLu Baolu <baolu.lu@linux.intel.com>
      Signed-off-by: 's avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ac8aa11e
    • John Stultz's avatar
      timekeeping: Fix __ktime_get_fast_ns() regression · 4e584cfe
      John Stultz authored
      commit 58bfea9532552d422bde7afa207e1a0f08dffa7d upstream.
      
      In commit 27727df2 ("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: 27727df2 "timekeeping: Avoid taking lock in NMI path with CONFIG_DEBUG_TIMEKEEPING"
      Reported-by: 's avatarBrendan Gregg <bgregg@netflix.com>
      Reported-by: 's avatarAlexei Starovoitov <alexei.starovoitov@gmail.com>
      Tested-and-reviewed-by: 's avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: 's avatarJohn 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.orgSigned-off-by: 's avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4e584cfe
    • Heiner Kallweit's avatar
      usb: storage: fix runtime pm issue in usb_stor_probe2 · c8661aaa
      Heiner Kallweit authored
      commit a094760b9a77f81ee3cbeff323ee77c928f41106 upstream.
      
      Since commit 71723f95 "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 cd998ded "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: 's avatarHeiner Kallweit <hkallweit1@gmail.com>
      Acked-by: 's avatarAlan Stern <stern@rowland.harvard.edu>
      Signed-off-by: 's avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c8661aaa
  3. 07 Oct, 2016 1 commit