1. 11 Jul, 2016 40 commits
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Handle NULL formats in hold_module_trace_bprintk_format() · 335f166e
      Steven Rostedt (Red Hat) authored
      [ Upstream commit 70c8217a ]
      
      If a task uses a non constant string for the format parameter in
      trace_printk(), then the trace_printk_fmt variable is set to NULL. This
      variable is then saved in the __trace_printk_fmt section.
      
      The function hold_module_trace_bprintk_format() checks to see if duplicate
      formats are used by modules, and reuses them if so (saves them to the list
      if it is new). But this function calls lookup_format() that does a strcmp()
      to the value (which is now NULL) and can cause a kernel oops.
      
      This wasn't an issue till 3debb0a9 ("tracing: Fix trace_printk() to print
      when not using bprintk()") which added "__used" to the trace_printk_fmt
      variable, and before that, the kernel simply optimized it out (no NULL value
      was saved).
      
      The fix is simply to handle the NULL pointer in lookup_format() and have the
      caller ignore the value if it was NULL.
      
      Link: http://lkml.kernel.org/r/1464769870-18344-1-git-send-email-zhengjun.xing@intel.comReported-by: default avatarxingzhen <zhengjun.xing@intel.com>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Fixes: 3debb0a9 ("tracing: Fix trace_printk() to print when not using bprintk()")
      Cc: stable@vger.kernel.org # v3.5+
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      335f166e
    • Wolfgang Grandegger's avatar
      can: at91_can: RX queue could get stuck at high bus load · 1105110d
      Wolfgang Grandegger authored
      [ Upstream commit 43200a44 ]
      
      At high bus load it could happen that "at91_poll()" enters with all RX
      message boxes filled up. If then at the end the "quota" is exceeded as
      well, "rx_next" will not be reset to the first RX mailbox and hence the
      interrupts remain disabled.
      Signed-off-by: default avatarWolfgang Grandegger <wg@grandegger.com>
      Tested-by: default avatarAmr Bekhit <amrbekhit@gmail.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      1105110d
    • Thor Thayer's avatar
      can: c_can: Update D_CAN TX and RX functions to 32 bit - fix Altera Cyclone access · 293745be
      Thor Thayer authored
      [ Upstream commit 427460c8 ]
      
      When testing CAN write floods on Altera's CycloneV, the first 2 bytes
      are sometimes 0x00, 0x00 or corrupted instead of the values sent. Also
      observed bytes 4 & 5 were corrupted in some cases.
      
      The D_CAN Data registers are 32 bits and changing from 16 bit writes to
      32 bit writes fixes the problem.
      
      Testing performed on Altera CycloneV (D_CAN).  Requesting tests on other
      C_CAN & D_CAN platforms.
      Reported-by: default avatarRichard Andrysek <richard.andrysek@gomtec.de>
      Signed-off-by: default avatarThor Thayer <tthayer@opensource.altera.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMarc Kleine-Budde <mkl@pengutronix.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      293745be
    • Jason Gunthorpe's avatar
      IB/mlx4: Properly initialize GRH TClass and FlowLabel in AHs · 0764832c
      Jason Gunthorpe authored
      [ Upstream commit 8c5122e4 ]
      
      When this code was reworked for IBoE support the order of assignments
      for the sl_tclass_flowlabel got flipped around resulting in
      TClass & FlowLabel being permanently set to 0 in the packet headers.
      
      This breaks IB routers that rely on these headers, but only affects
      kernel users - libmlx4 does this properly for user space.
      
      Cc: stable@vger.kernel.org
      Fixes: fa417f7b ("IB/mlx4: Add support for IBoE")
      Signed-off-by: default avatarJason Gunthorpe <jgunthorpe@obsidianresearch.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      0764832c
    • Jeff Mahoney's avatar
      btrfs: account for non-CoW'd blocks in btrfs_abort_transaction · efe098c3
      Jeff Mahoney authored
      [ Upstream commit 64c12921 ]
      
      The test for !trans->blocks_used in btrfs_abort_transaction is
      insufficient to determine whether it's safe to drop the transaction
      handle on the floor.  btrfs_cow_block, informed by should_cow_block,
      can return blocks that have already been CoW'd in the current
      transaction.  trans->blocks_used is only incremented for new block
      allocations. If an operation overlaps the blocks in the current
      transaction entirely and must abort the transaction, we'll happily
      let it clean up the trans handle even though it may have modified
      the blocks and will commit an incomplete operation.
      
      In the long-term, I'd like to do closer tracking of when the fs
      is actually modified so we can still recover as gracefully as possible,
      but that approach will need some discussion.  In the short term,
      since this is the only code using trans->blocks_used, let's just
      switch it to a bool indicating whether any blocks were used and set
      it when should_cow_block returns false.
      
      Cc: stable@vger.kernel.org # 3.4+
      Signed-off-by: default avatarJeff Mahoney <jeffm@suse.com>
      Reviewed-by: default avatarFilipe Manana <fdmanana@suse.com>
      Signed-off-by: default avatarDavid Sterba <dsterba@suse.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      efe098c3
    • Jaroslav Kysela's avatar
      ALSA: hdac_regmap - fix the register access for runtime PM · 0b1ca750
      Jaroslav Kysela authored
      [ Upstream commit 8198868f ]
      
      Call path:
      
        1) snd_hdac_power_up_pm()
        2) snd_hdac_power_up()
        3) pm_runtime_get_sync()
        4) __pm_runtime_resume()
        5) rpm_resume()
      
      The rpm_resume() returns 1 when the device is already active.
      Because the return value is unmodified, the hdac regmap read/write
      functions should allow this value for the retry I/O operation, too.
      Signed-off-by: default avatarJaroslav Kysela <perex@perex.cz>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      0b1ca750
    • Takashi Iwai's avatar
      ALSA: hda - Fix possible race on regmap bypass flip · ec3e7322
      Takashi Iwai authored
      [ Upstream commit 3194ed49 ]
      
      HD-audio driver uses regmap cache bypass feature for reading a raw
      value without the cache.  But this is racy since both the cached and
      the uncached reads may occur concurrently.  The former is done via the
      normal control API access while the latter comes from the proc file
      read.
      
      Even though the regmap itself has the protection against the
      concurrent accesses, the flag set/reset is done without the
      protection, so it may lead to inconsistent state of bypass flag that
      doesn't match with the current read and occasionally result in a
      kernel WARNING like:
        WARNING: CPU: 3 PID: 2731 at drivers/base/regmap/regcache.c:499 regcache_cache_only+0x78/0x93
      
      One way to work around such a problem is to wrap with a mutex.  But in
      this case, the solution is simpler: for the uncached read, we just
      skip the regmap and directly calls its accessor.  The verb execution
      there is protected by itself, so basically it's safe to call
      individually.
      
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=116171Signed-off-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ec3e7322
    • Dan Carpenter's avatar
      KEYS: potential uninitialized variable · c262505c
      Dan Carpenter authored
      [ Upstream commit 38327424 ]
      
      If __key_link_begin() failed then "edit" would be uninitialized.  I've
      added a check to fix that.
      
      This allows a random user to crash the kernel, though it's quite
      difficult to achieve.  There are three ways it can be done as the user
      would have to cause an error to occur in __key_link():
      
       (1) Cause the kernel to run out of memory.  In practice, this is difficult
           to achieve without ENOMEM cropping up elsewhere and aborting the
           attempt.
      
       (2) Revoke the destination keyring between the keyring ID being looked up
           and it being tested for revocation.  In practice, this is difficult to
           time correctly because the KEYCTL_REJECT function can only be used
           from the request-key upcall process.  Further, users can only make use
           of what's in /sbin/request-key.conf, though this does including a
           rejection debugging test - which means that the destination keyring
           has to be the caller's session keyring in practice.
      
       (3) Have just enough key quota available to create a key, a new session
           keyring for the upcall and a link in the session keyring, but not then
           sufficient quota to create a link in the nominated destination keyring
           so that it fails with EDQUOT.
      
      The bug can be triggered using option (3) above using something like the
      following:
      
      	echo 80 >/proc/sys/kernel/keys/root_maxbytes
      	keyctl request2 user debug:fred negate @t
      
      The above sets the quota to something much lower (80) to make the bug
      easier to trigger, but this is dependent on the system.  Note also that
      the name of the keyring created contains a random number that may be
      between 1 and 10 characters in size, so may throw the test off by
      changing the amount of quota used.
      
      Assuming the failure occurs, something like the following will be seen:
      
      	kfree_debugcheck: out of range ptr 6b6b6b6b6b6b6b68h
      	------------[ cut here ]------------
      	kernel BUG at ../mm/slab.c:2821!
      	...
      	RIP: 0010:[<ffffffff811600f9>] kfree_debugcheck+0x20/0x25
      	RSP: 0018:ffff8804014a7de8  EFLAGS: 00010092
      	RAX: 0000000000000034 RBX: 6b6b6b6b6b6b6b68 RCX: 0000000000000000
      	RDX: 0000000000040001 RSI: 00000000000000f6 RDI: 0000000000000300
      	RBP: ffff8804014a7df0 R08: 0000000000000001 R09: 0000000000000000
      	R10: ffff8804014a7e68 R11: 0000000000000054 R12: 0000000000000202
      	R13: ffffffff81318a66 R14: 0000000000000000 R15: 0000000000000001
      	...
      	Call Trace:
      	  kfree+0xde/0x1bc
      	  assoc_array_cancel_edit+0x1f/0x36
      	  __key_link_end+0x55/0x63
      	  key_reject_and_link+0x124/0x155
      	  keyctl_reject_key+0xb6/0xe0
      	  keyctl_negate_key+0x10/0x12
      	  SyS_keyctl+0x9f/0xe7
      	  do_syscall_64+0x63/0x13a
      	  entry_SYSCALL64_slow_path+0x25/0x25
      
      Fixes: f70e2e06 ('KEYS: Do preallocation for __key_link()')
      Signed-off-by: default avatarDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: default avatarDavid Howells <dhowells@redhat.com>
      cc: stable@vger.kernel.org
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      c262505c
    • Tejun Heo's avatar
      cgroup: set css->id to -1 during init · 0356b95f
      Tejun Heo authored
      [ Upstream commit 8fa3b8d6 ]
      
      If percpu_ref initialization fails during css_create(), the free path
      can end up trying to free css->id of zero.  As ID 0 is unused, it
      doesn't cause a critical breakage but it does trigger a warning
      message.  Fix it by setting css->id to -1 from init_and_link_css().
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Cc: Wenwei Tao <ww.tao0320@gmail.com>
      Fixes: 01e58659 ("cgroup: release css->id after css_free")
      Cc: stable@vger.kernel.org # v4.0+
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      0356b95f
    • Ocquidant, Sebastien's avatar
      memory: omap-gpmc: Fix omap gpmc EXTRADELAY timing · 4c9b1064
      Ocquidant, Sebastien authored
      [ Upstream commit 8f50b8e5 ]
      
      In the omap gpmc driver it can be noticed that GPMC_CONFIG4_OEEXTRADELAY
      is overwritten by the WEEXTRADELAY value from the device tree and
      GPMC_CONFIG4_WEEXTRADELAY is not updated by the value from the device
      tree.
      
      As a consequence, the memory accesses cannot be configured properly when
      the extra delay are needed for OE and WE.
      
      Fix the update of GPMC_CONFIG4_WEEXTRADELAY with the value from the
      device tree file and prevents GPMC_CONFIG4_OEXTRADELAY
      being overwritten by the WEXTRADELAY value from the device tree.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarOcquidant, Sebastien <sebastienocquidant@eaton.com>
      Signed-off-by: default avatarRoger Quadros <rogerq@ti.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      4c9b1064
    • Xiubo Li's avatar
      kvm: Fix irq route entries exceeding KVM_MAX_IRQ_ROUTES · 31651598
      Xiubo Li authored
      [ Upstream commit caf1ff26 ]
      
      These days, we experienced one guest crash with 8 cores and 3 disks,
      with qemu error logs as bellow:
      
      qemu-system-x86_64: /build/qemu-2.0.0/kvm-all.c:984:
      kvm_irqchip_commit_routes: Assertion `ret == 0' failed.
      
      And then we found one patch(bdf026317d) in qemu tree, which said
      could fix this bug.
      
      Execute the following script will reproduce the BUG quickly:
      
      irq_affinity.sh
      ========================================================================
      
      vda_irq_num=25
      vdb_irq_num=27
      while [ 1 ]
      do
          for irq in {1,2,4,8,10,20,40,80}
              do
                  echo $irq > /proc/irq/$vda_irq_num/smp_affinity
                  echo $irq > /proc/irq/$vdb_irq_num/smp_affinity
                  dd if=/dev/vda of=/dev/zero bs=4K count=100 iflag=direct
                  dd if=/dev/vdb of=/dev/zero bs=4K count=100 iflag=direct
              done
      done
      ========================================================================
      
      The following qemu log is added in the qemu code and is displayed when
      this bug reproduced:
      
      kvm_irqchip_commit_routes: max gsi: 1008, nr_allocated_irq_routes: 1024,
      irq_routes->nr: 1024, gsi_count: 1024.
      
      That's to say when irq_routes->nr == 1024, there are 1024 routing entries,
      but in the kernel code when routes->nr >= 1024, will just return -EINVAL;
      
      The nr is the number of the routing entries which is in of
      [1 ~ KVM_MAX_IRQ_ROUTES], not the index in [0 ~ KVM_MAX_IRQ_ROUTES - 1].
      
      This patch fix the BUG above.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarXiubo Li <lixiubo@cmss.chinamobile.com>
      Signed-off-by: default avatarWei Tang <tangwei@cmss.chinamobile.com>
      Signed-off-by: default avatarZhang Zhuoyu <zhangzhuoyu@cmss.chinamobile.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      31651598
    • Jiri Slaby's avatar
      base: make module_create_drivers_dir race-free · aec2ddb9
      Jiri Slaby authored
      [ Upstream commit 7e1b1fc4 ]
      
      Modules which register drivers via standard path (driver_register) in
      parallel can cause a warning:
      WARNING: CPU: 2 PID: 3492 at ../fs/sysfs/dir.c:31 sysfs_warn_dup+0x62/0x80
      sysfs: cannot create duplicate filename '/module/saa7146/drivers'
      Modules linked in: hexium_gemini(+) mxb(+) ...
      ...
      Call Trace:
      ...
       [<ffffffff812e63a2>] sysfs_warn_dup+0x62/0x80
       [<ffffffff812e6487>] sysfs_create_dir_ns+0x77/0x90
       [<ffffffff8140f2c4>] kobject_add_internal+0xb4/0x340
       [<ffffffff8140f5b8>] kobject_add+0x68/0xb0
       [<ffffffff8140f631>] kobject_create_and_add+0x31/0x70
       [<ffffffff8157a703>] module_add_driver+0xc3/0xd0
       [<ffffffff8155e5d4>] bus_add_driver+0x154/0x280
       [<ffffffff815604c0>] driver_register+0x60/0xe0
       [<ffffffff8145bed0>] __pci_register_driver+0x60/0x70
       [<ffffffffa0273e14>] saa7146_register_extension+0x64/0x90 [saa7146]
       [<ffffffffa0033011>] hexium_init_module+0x11/0x1000 [hexium_gemini]
      ...
      
      As can be (mostly) seen, driver_register causes this call sequence:
        -> bus_add_driver
          -> module_add_driver
            -> module_create_drivers_dir
      The last one creates "drivers" directory in /sys/module/<...>. When
      this is done in parallel, the directory is attempted to be created
      twice at the same time.
      
      This can be easily reproduced by loading mxb and hexium_gemini in
      parallel:
      while :; do
        modprobe mxb &
        modprobe hexium_gemini
        wait
        rmmod mxb hexium_gemini saa7146_vv saa7146
      done
      
      saa7146 calls pci_register_driver for both mxb and hexium_gemini,
      which means /sys/module/saa7146/drivers is to be created for both of
      them.
      
      Fix this by a new mutex in module_create_drivers_dir which makes the
      test-and-create "drivers" dir atomic.
      
      I inverted the condition and removed 'return' to avoid multiple
      unlocks or a goto.
      Signed-off-by: default avatarJiri Slaby <jslaby@suse.cz>
      Fixes: fe480a26 (Modules: only add drivers/ direcory if needed)
      Cc: v2.6.21+ <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      aec2ddb9
    • J. Bruce Fields's avatar
      nfsd4/rpc: move backchannel create logic into rpc code · c2edadb9
      J. Bruce Fields authored
      [ Upstream commit d50039ea ]
      
      Also simplify the logic a bit.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarJ. Bruce Fields <bfields@redhat.com>
      Acked-by: default avatarTrond Myklebust <trondmy@primarydata.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      c2edadb9
    • Andrey Grodzovsky's avatar
      drm/dp/mst: Always clear proposed vcpi table for port. · 040ad2a3
      Andrey Grodzovsky authored
      [ Upstream commit fd2d2bac ]
      
      Not clearing mst manager's proposed vcpis table for destroyed connectors when the manager is stopped leaves it pointing to unrefernced memory, this causes pagefault when the manager is restarted when plugging back a branch.
      
      Fixes: 91a25e46 ("drm/dp/mst: deallocate payload on port destruction")
      Signed-off-by: default avatarAndrey Grodzovsky <Andrey.Grodzovsky@amd.com>
      Reviewed-by: default avatarLyude <cpaul@redhat.com>
      Cc: stable@vger.kernel.org
      Cc: Mykola Lysenko <Mykola.Lysenko@amd.com>
      Cc: Alex Deucher <alexander.deucher@amd.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      040ad2a3
    • Lyude's avatar
      drm/i915/ilk: Don't disable SSC source if it's in use · 5a6c735c
      Lyude authored
      [ Upstream commit 476490a9 ]
      
      Thanks to Ville Syrjälä for pointing me towards the cause of this issue.
      
      Unfortunately one of the sideaffects of having the refclk for a DPLL set
      to SSC is that as long as it's set to SSC, the GPU will prevent us from
      powering down any of the pipes or transcoders using it. A couple of
      BIOSes enable SSC in both PCH_DREF_CONTROL and in the DPLL
      configurations. This causes issues on the first modeset, since we don't
      expect SSC to be left on and as a result, can't successfully power down
      the pipes or the transcoders using it. Here's an example from this Dell
      OptiPlex 990:
      
      [drm:intel_modeset_init] SSC enabled by BIOS, overriding VBT which says disabled
      [drm:intel_modeset_init] 2 display pipes available.
      [drm:intel_update_cdclk] Current CD clock rate: 400000 kHz
      [drm:intel_update_max_cdclk] Max CD clock rate: 400000 kHz
      [drm:intel_update_max_cdclk] Max dotclock rate: 360000 kHz
      vgaarb: device changed decodes: PCI:0000:00:02.0,olddecodes=io+mem,decodes=io+mem:owns=io+mem
      [drm:intel_crt_reset] crt adpa set to 0xf40000
      [drm:intel_dp_init_connector] Adding DP connector on port C
      [drm:intel_dp_aux_init] registering DPDDC-C bus for card0-DP-1
      [drm:ironlake_init_pch_refclk] has_panel 0 has_lvds 0 has_ck505 0
      [drm:ironlake_init_pch_refclk] Disabling SSC entirely
      … later we try committing the first modeset …
      [drm:intel_dump_pipe_config] [CRTC:26][modeset] config ffff88041b02e800 for pipe A
      [drm:intel_dump_pipe_config] cpu_transcoder: A
      …
      [drm:intel_dump_pipe_config] dpll_hw_state: dpll: 0xc4016001, dpll_md: 0x0, fp0: 0x20e08, fp1: 0x30d07
      [drm:intel_dump_pipe_config] planes on this crtc
      [drm:intel_dump_pipe_config] STANDARD PLANE:23 plane: 0.0 idx: 0 enabled
      [drm:intel_dump_pipe_config]     FB:42, fb = 800x600 format = 0x34325258
      [drm:intel_dump_pipe_config]     scaler:0 src (0, 0) 800x600 dst (0, 0) 800x600
      [drm:intel_dump_pipe_config] CURSOR PLANE:25 plane: 0.1 idx: 1 disabled, scaler_id = 0
      [drm:intel_dump_pipe_config] STANDARD PLANE:27 plane: 0.1 idx: 2 disabled, scaler_id = 0
      [drm:intel_get_shared_dpll] CRTC:26 allocated PCH DPLL A
      [drm:intel_get_shared_dpll] using PCH DPLL A for pipe A
      [drm:ilk_audio_codec_disable] Disable audio codec on port C, pipe A
      [drm:intel_disable_pipe] disabling pipe A
      ------------[ cut here ]------------
      WARNING: CPU: 1 PID: 130 at drivers/gpu/drm/i915/intel_display.c:1146 intel_disable_pipe+0x297/0x2d0 [i915]
      pipe_off wait timed out
      …
      ---[ end trace 94fc8aa03ae139e8 ]---
      [drm:intel_dp_link_down]
      [drm:ironlake_crtc_disable [i915]] *ERROR* failed to disable transcoder A
      
      Later modesets succeed since they reset the DPLL's configuration anyway,
      but this is enough to get stuck with a big fat warning in dmesg.
      
      A better solution would be to add refcounts for the SSC source, but for
      now leaving the source clock on should suffice.
      
      Changes since v4:
       - Fix calculation of final for systems with LVDS panels (fixes BUG() on
         CI test suite)
      Changes since v3:
       - Move temp variable into loop
       - Move checks for using_ssc_source to after we've figured out has_ck505
       - Add using_ssc_source to debug output
      Changes since v2:
       - Fix debug output for when we disable the CPU source
      Changes since v1:
       - Leave the SSC source clock on instead of just shutting it off on all
         of the DPLL configurations.
      
      Cc: stable@vger.kernel.org
      Reviewed-by: default avatarVille Syrjälä <ville.syrjala@linux.intel.com>
      Signed-off-by: default avatarLyude <cpaul@redhat.com>
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: http://patchwork.freedesktop.org/patch/msgid/1465916649-10228-1-git-send-email-cpaul@redhat.comSigned-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      5a6c735c
    • Rhyland Klein's avatar
      power_supply: power_supply_read_temp only if use_cnt > 0 · 260c505e
      Rhyland Klein authored
      [ Upstream commit 5bc28b93 ]
      
      Change power_supply_read_temp() to use power_supply_get_property()
      so that it will check the use_cnt and ensure it is > 0. The use_cnt
      will be incremented at the end of __power_supply_register, so this
      will block to case where get_property can be called before the supply
      is fully registered. This fixes the issue show in the stack below:
      
      [    1.452598] power_supply_read_temp+0x78/0x80
      [    1.458680] thermal_zone_get_temp+0x5c/0x11c
      [    1.464765] thermal_zone_device_update+0x34/0xb4
      [    1.471195] thermal_zone_device_register+0x87c/0x8cc
      [    1.477974] __power_supply_register+0x364/0x424
      [    1.484317] power_supply_register_no_ws+0x10/0x18
      [    1.490833] bq27xxx_battery_setup+0x10c/0x164
      [    1.497003] bq27xxx_battery_i2c_probe+0xd0/0x1b0
      [    1.503435] i2c_device_probe+0x174/0x240
      [    1.509172] driver_probe_device+0x1fc/0x29c
      [    1.515167] __driver_attach+0xa4/0xa8
      [    1.520643] bus_for_each_dev+0x58/0x98
      [    1.526204] driver_attach+0x20/0x28
      [    1.531505] bus_add_driver+0x1c8/0x22c
      [    1.537067] driver_register+0x68/0x108
      [    1.542630] i2c_register_driver+0x38/0x7c
      [    1.548457] bq27xxx_battery_i2c_driver_init+0x18/0x20
      [    1.555321] do_one_initcall+0x38/0x12c
      [    1.560886] kernel_init_freeable+0x148/0x1ec
      [    1.566972] kernel_init+0x10/0xfc
      [    1.572101] ret_from_fork+0x10/0x40
      
      Also make the same change to ps_get_max_charge_cntl_limit() and
      ps_get_cur_chrage_cntl_limit() to be safe. Lastly, change the return
      value of power_supply_get_property() to -EAGAIN from -ENODEV if
      use_cnt <= 0.
      
      Fixes: 297d716f ("power_supply: Change ownership from driver to core")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarRhyland Klein <rklein@nvidia.com>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Signed-off-by: default avatarSebastian Reichel <sre@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      260c505e
    • Andrey Ryabinin's avatar
      kernel/sysrq, watchdog, sched/core: Reset watchdog on all CPUs while processing sysrq-w · 9f67dcf6
      Andrey Ryabinin authored
      [ Upstream commit 57675cb9 ]
      
      Lengthy output of sysrq-w may take a lot of time on slow serial console.
      
      Currently we reset NMI-watchdog on the current CPU to avoid spurious
      lockup messages. Sometimes this doesn't work since softlockup watchdog
      might trigger on another CPU which is waiting for an IPI to proceed.
      We reset softlockup watchdogs on all CPUs, but we do this only after
      listing all tasks, and this may be too late on a busy system.
      
      So, reset watchdogs CPUs earlier, in for_each_process_thread() loop.
      Signed-off-by: default avatarAndrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: <stable@vger.kernel.org>
      Link: http://lkml.kernel.org/r/1465474805-14641-1-git-send-email-aryabinin@virtuozzo.comSigned-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      9f67dcf6
    • Masami Hiramatsu's avatar
      kprobes/x86: Clear TF bit in fault on single-stepping · c5ffc99b
      Masami Hiramatsu authored
      [ Upstream commit dcfc4724 ]
      
      Fix kprobe_fault_handler() to clear the TF (trap flag) bit of
      the flags register in the case of a fault fixup on single-stepping.
      
      If we put a kprobe on the instruction which caused a
      page fault (e.g. actual mov instructions in copy_user_*),
      that fault happens on the single-stepping buffer. In this
      case, kprobes resets running instance so that the CPU can
      retry execution on the original ip address.
      
      However, current code forgets to reset the TF bit. Since this
      fault happens with TF bit set for enabling single-stepping,
      when it retries, it causes a debug exception and kprobes
      can not handle it because it already reset itself.
      
      On the most of x86-64 platform, it can be easily reproduced
      by using kprobe tracer. E.g.
      
        # cd /sys/kernel/debug/tracing
        # echo p copy_user_enhanced_fast_string+5 > kprobe_events
        # echo 1 > events/kprobes/enable
      
      And you'll see a kernel panic on do_debug(), since the debug
      trap is not handled by kprobes.
      
      To fix this problem, we just need to clear the TF bit when
      resetting running kprobe.
      Signed-off-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Reviewed-by: default avatarAnanth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Acked-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andy Lutomirski <luto@kernel.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Borislav Petkov <bp@alien8.de>
      Cc: Brian Gerst <brgerst@gmail.com>
      Cc: Denys Vlasenko <dvlasenk@redhat.com>
      Cc: H. Peter Anvin <hpa@zytor.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Vince Weaver <vincent.weaver@maine.edu>
      Cc: systemtap@sourceware.org
      Cc: stable@vger.kernel.org # All the way back to ancient kernels
      Link: http://lkml.kernel.org/r/20160611140648.25885.37482.stgit@devbox
      [ Updated the comments. ]
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      c5ffc99b
    • Michal Suchanek's avatar
      spi: sunxi: fix transfer timeout · 01c93ba6
      Michal Suchanek authored
      [ Upstream commit 719bd654 ]
      
      The trasfer timeout is fixed at 1000 ms. Reading a 4Mbyte flash over
      1MHz SPI bus takes way longer than that. Calculate the timeout from the
      actual time the transfer is supposed to take and multiply by 2 for good
      measure.
      Signed-off-by: default avatarMichal Suchanek <hramrach@gmail.com>
      Acked-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      01c93ba6
    • Michal Suchanek's avatar
      spi: sun4i: fix FIFO limit · fcc5d265
      Michal Suchanek authored
      [ Upstream commit 6d9fe44b ]
      
      When testing SPI without DMA I noticed that filling the FIFO on the
      spi controller causes timeout.
      
      Always leave room for one byte in the FIFO.
      Signed-off-by: default avatarMichal Suchanek <hramrach@gmail.com>
      Acked-by: default avatarMaxime Ripard <maxime.ripard@free-electrons.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      fcc5d265
    • James Hogan's avatar
      MIPS: KVM: Fix modular KVM under QEMU · d1c7fc1c
      James Hogan authored
      [ Upstream commit 797179bc ]
      
      Copy __kvm_mips_vcpu_run() into unmapped memory, so that we can never
      get a TLB refill exception in it when KVM is built as a module.
      
      This was observed to happen with the host MIPS kernel running under
      QEMU, due to a not entirely transparent optimisation in the QEMU TLB
      handling where TLB entries replaced with TLBWR are copied to a separate
      part of the TLB array. Code in those pages continue to be executable,
      but those mappings persist only until the next ASID switch, even if they
      are marked global.
      
      An ASID switch happens in __kvm_mips_vcpu_run() at exception level after
      switching to the guest exception base. Subsequent TLB mapped kernel
      instructions just prior to switching to the guest trigger a TLB refill
      exception, which enters the guest exception handlers without updating
      EPC. This appears as a guest triggered TLB refill on a host kernel
      mapped (host KSeg2) address, which is not handled correctly as user
      (guest) mode accesses to kernel (host) segments always generate address
      error exceptions.
      Signed-off-by: default 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: kvm@vger.kernel.org
      Cc: linux-mips@linux-mips.org
      Cc: <stable@vger.kernel.org> # 3.10.x-
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      d1c7fc1c
    • Oscar's avatar
      usb: common: otg-fsm: add license to usb-otg-fsm · 505291af
      Oscar authored
      [ Upstream commit ea1d39a3 ]
      
      Fix warning about tainted kernel because usb-otg-fsm has no license.
      WARNING: with this patch usb-otg-fsm module can be loaded
      but then the kernel will hang. Tested with a udoo quad board.
      
      Cc: <stable@vger.kernel.org> #v4.1+
      Signed-off-by: default avatarOscar <oscar@naiandei.net>
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      505291af
    • Alex Deucher's avatar
      drm/radeon: fix asic initialization for virtualized environments · d7afed77
      Alex Deucher authored
      [ Upstream commit 05082b8b ]
      
      When executing in a PCI passthrough based virtuzliation environment, the
      hypervisor will usually attempt to send a PCIe bus reset signal to the
      ASIC when the VM reboots. In this scenario, the card is not correctly
      initialized, but we still consider it to be posted. Therefore, in a
      passthrough based environemnt we should always post the card to guarantee
      it is in a good state for driver initialization.
      
      Ported from amdgpu commit:
      amdgpu: fix asic initialization for virtualized environments
      
      Cc: Andres Rodriguez <andres.rodriguez@amd.com>
      Cc: Alex Williamson <alex.williamson@redhat.com>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      d7afed77
    • Junichi Nomura's avatar
      ipmi: Remove smi_msg from waiting_rcv_msgs list before handle_one_recv_msg() · 7ac3a704
      Junichi Nomura authored
      [ Upstream commit ae4ea9a2 ]
      
      Commit 7ea0ed2b ("ipmi: Make the message handler easier to use for
      SMI interfaces") changed handle_new_recv_msgs() to call handle_one_recv_msg()
      for a smi_msg while the smi_msg is still connected to waiting_rcv_msgs list.
      That could lead to following list corruption problems:
      
      1) low-level function treats smi_msg as not connected to list
      
        handle_one_recv_msg() could end up calling smi_send(), which
        assumes the msg is not connected to list.
      
        For example, the following sequence could corrupt list by
        doing list_add_tail() for the entry still connected to other list.
      
          handle_new_recv_msgs()
            msg = list_entry(waiting_rcv_msgs)
            handle_one_recv_msg(msg)
              handle_ipmb_get_msg_cmd(msg)
                smi_send(msg)
                  spin_lock(xmit_msgs_lock)
                  list_add_tail(msg)
                  spin_unlock(xmit_msgs_lock)
      
      2) race between multiple handle_new_recv_msgs() instances
      
        handle_new_recv_msgs() once releases waiting_rcv_msgs_lock before calling
        handle_one_recv_msg() then retakes the lock and list_del() it.
      
        If others call handle_new_recv_msgs() during the window shown below
        list_del() will be done twice for the same smi_msg.
      
        handle_new_recv_msgs()
          spin_lock(waiting_rcv_msgs_lock)
          msg = list_entry(waiting_rcv_msgs)
          spin_unlock(waiting_rcv_msgs_lock)
        |
        | handle_one_recv_msg(msg)
        |
          spin_lock(waiting_rcv_msgs_lock)
          list_del(msg)
          spin_unlock(waiting_rcv_msgs_lock)
      
      Fixes: 7ea0ed2b ("ipmi: Make the message handler easier to use for SMI interfaces")
      Signed-off-by: default avatarJun'ichi Nomura <j-nomura@ce.jp.nec.com>
      [Added a comment to describe why this works.]
      Signed-off-by: default avatarCorey Minyard <cminyard@mvista.com>
      Cc: stable@vger.kernel.org # 3.19
      Tested-by: default avatarYe Feng <yefeng.yl@alibaba-inc.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      7ac3a704
    • Linus Walleij's avatar
      crypto: ux500 - memmove the right size · 4a088cba
      Linus Walleij authored
      [ Upstream commit 19ced623 ]
      
      The hash buffer is really HASH_BLOCK_SIZE bytes, someone
      must have thought that memmove takes n*u32 words by mistake.
      Tests work as good/bad as before after this patch.
      
      Cc: Joakim Bech <joakim.bech@linaro.org>
      Cc: stable@vger.kernel.org
      Reported-by: default avatarDavid Binderman <linuxdev.baldrick@gmail.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      4a088cba
    • Anton Blanchard's avatar
      crypto: vmx - Increase priority of aes-cbc cipher · 9341331d
      Anton Blanchard authored
      [ Upstream commit 12d3f49e ]
      
      All of the VMX AES ciphers (AES, AES-CBC and AES-CTR) are set at
      priority 1000. Unfortunately this means we never use AES-CBC and
      AES-CTR, because the base AES-CBC cipher that is implemented on
      top of AES inherits its priority.
      
      To fix this, AES-CBC and AES-CTR have to be a higher priority. Set
      them to 2000.
      
      Testing on a POWER8 with:
      
      cryptsetup benchmark --cipher aes --key-size 256
      
      Shows decryption speed increase from 402.4 MB/s to 3069.2 MB/s,
      over 7x faster. Thanks to Mike Strosaker for helping me debug
      this issue.
      
      Fixes: 8c755ace ("crypto: vmx - Adding CBC routines for VMX module")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarAnton Blanchard <anton@samba.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      9341331d
    • Steve Capper's avatar
      ARM: 8579/1: mm: Fix definition of pmd_mknotpresent · 515f3035
      Steve Capper authored
      [ Upstream commit 56530f5d ]
      
      Currently pmd_mknotpresent will use a zero entry to respresent an
      invalidated pmd.
      
      Unfortunately this definition clashes with pmd_none, thus it is
      possible for a race condition to occur if zap_pmd_range sees pmd_none
      whilst __split_huge_pmd_locked is running too with pmdp_invalidate
      just called.
      
      This patch fixes the race condition by modifying pmd_mknotpresent to
      create non-zero faulting entries (as is done in other architectures),
      removing the ambiguity with pmd_none.
      
      [catalin.marinas@arm.com: using L_PMD_SECT_VALID instead of PMD_TYPE_SECT]
      
      Fixes: 8d962507 ("ARM: mm: Transparent huge page support for LPAE systems.")
      Cc: <stable@vger.kernel.org> # 3.11+
      Reported-by: default avatarKirill A. Shutemov <kirill.shutemov@linux.intel.com>
      Acked-by: default avatarWill Deacon <will.deacon@arm.com>
      Cc: Russell King <linux@armlinux.org.uk>
      Signed-off-by: default avatarSteve Capper <steve.capper@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      515f3035
    • Will Deacon's avatar
      ARM: 8578/1: mm: ensure pmd_present only checks the valid bit · 017864ed
      Will Deacon authored
      [ Upstream commit 62453188 ]
      
      In a subsequent patch, pmd_mknotpresent will clear the valid bit of the
      pmd entry, resulting in a not-present entry from the hardware's
      perspective. Unfortunately, pmd_present simply checks for a non-zero pmd
      value and will therefore continue to return true even after a
      pmd_mknotpresent operation. Since pmd_mknotpresent is only used for
      managing huge entries, this is only an issue for the 3-level case.
      
      This patch fixes the 3-level pmd_present implementation to take into
      account the valid bit. For bisectability, the change is made before the
      fix to pmd_mknotpresent.
      
      [catalin.marinas@arm.com: comment update regarding pmd_mknotpresent patch]
      
      Fixes: 8d962507 ("ARM: mm: Transparent huge page support for LPAE systems.")
      Cc: <stable@vger.kernel.org> # 3.11+
      Cc: Russell King <linux@armlinux.org.uk>
      Cc: Steve Capper <Steve.Capper@arm.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarCatalin Marinas <catalin.marinas@arm.com>
      Signed-off-by: default avatarRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      017864ed
    • Wei Fang's avatar
      scsi: fix race between simultaneous decrements of ->host_failed · bcef1c81
      Wei Fang authored
      [ Upstream commit 72d8c36e ]
      
      sas_ata_strategy_handler() adds the works of the ata error handler to
      system_unbound_wq. This workqueue asynchronously runs work items, so the
      ata error handler will be performed concurrently on different CPUs. In
      this case, ->host_failed will be decreased simultaneously in
      scsi_eh_finish_cmd() on different CPUs, and become abnormal.
      
      It will lead to permanently inequality between ->host_failed and
      ->host_busy, and scsi error handler thread won't start running. IO
      errors after that won't be handled.
      
      Since all scmds must have been handled in the strategy handler, just
      remove the decrement in scsi_eh_finish_cmd() and zero ->host_busy after
      the strategy handler to fix this race.
      
      Fixes: 50824d6c ("[SCSI] libsas: async ata-eh")
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarWei Fang <fangwei1@huawei.com>
      Reviewed-by: default avatarJames Bottomley <jejb@linux.vnet.ibm.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      bcef1c81
    • Thierry Reding's avatar
      usb: host: ehci-tegra: Grab the correct UTMI pads reset · e342d574
      Thierry Reding authored
      [ Upstream commit f8a15a96 ]
      
      There are three EHCI controllers on Tegra SoCs, each with its own reset
      line. However, the first controller contains a set of UTMI configuration
      registers that are shared with its siblings. These registers will only
      be reset as part of the first controller's reset. For proper operation
      it must be ensured that the UTMI configuration registers are reset
      before any of the EHCI controllers are enabled, irrespective of the
      probe order.
      
      Commit a47cc24c ("USB: EHCI: tegra: Fix probe order issue leading to
      broken USB") introduced code that ensures the first controller is always
      reset before setting up any of the controllers, and is never again reset
      afterwards.
      
      This code, however, grabs the wrong reset. Each EHCI controller has two
      reset controls attached: 1) the USB controller reset and 2) the UTMI
      pads reset (really the first controller's reset). In order to reset the
      UTMI pads registers the code must grab the second reset, but instead it
      grabbing the first.
      
      Fixes: a47cc24c ("USB: EHCI: tegra: Fix probe order issue leading to broken USB")
      Acked-by: default avatarJon Hunter <jonathanh@nvidia.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarThierry Reding <treding@nvidia.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e342d574
    • Andrew Goodbody's avatar
      usb: musb: Stop bulk endpoint while queue is rotated · 5cf1329f
      Andrew Goodbody authored
      [ Upstream commit 7b2c17f8 ]
      
      Ensure that the endpoint is stopped by clearing REQPKT before
      clearing DATAERR_NAKTIMEOUT before rotating the queue on the
      dedicated bulk endpoint.
      This addresses an issue where a race could result in the endpoint
      receiving data before it was reprogrammed resulting in a warning
      about such data from musb_rx_reinit before it was thrown away.
      The data thrown away was a valid packet that had been correctly
      ACKed which meant the host and device got out of sync.
      Signed-off-by: default avatarAndrew Goodbody <andrew.goodbody@cambrionix.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      5cf1329f
    • Andrew Goodbody's avatar
      usb: musb: Ensure rx reinit occurs for shared_fifo endpoints · ffb84c17
      Andrew Goodbody authored
      [ Upstream commit f3eec0cf ]
      
      shared_fifo endpoints would only get a previous tx state cleared
      out, the rx state was only cleared for non shared_fifo endpoints
      Change this so that the rx state is cleared for all endpoints.
      This addresses an issue that resulted in rx packets being dropped
      silently.
      Signed-off-by: default avatarAndrew Goodbody <andrew.goodbody@cambrionix.com>
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      ffb84c17
    • Hans de Goede's avatar
      USB: xhci: Add broken streams quirk for Frescologic device id 1009 · 95cb83b7
      Hans de Goede authored
      [ Upstream commit d95815ba ]
      
      I got one of these cards for testing uas with, it seems that with streams
      it dma-s all over the place, corrupting memory. On my first tests it
      managed to dma over the BIOS of the motherboard somehow and completely
      bricked it.
      
      Tests on another motherboard show that it does work with streams disabled.
      
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      95cb83b7
    • Hans de Goede's avatar
      usb: quirks: Add no-lpm quirk for Acer C120 LED Projector · 378cd9e7
      Hans de Goede authored
      [ Upstream commit 32cb0b37 ]
      
      The Acer C120 LED Projector is a USB-3 connected pico projector which
      takes both its power and video data from USB-3.
      
      In combination with some hubs this device does not play well with
      lpm, so disable lpm for it.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      378cd9e7
    • Hans de Goede's avatar
      usb: quirks: Fix sorting · 7d2831a8
      Hans de Goede authored
      [ Upstream commit 81099f97 ]
      
      Properly sort all the entries by vendor id.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      7d2831a8
    • Thomas Petazzoni's avatar
      usb: xhci-plat: properly handle probe deferral for devm_clk_get() · 0c3f25d8
      Thomas Petazzoni authored
      [ Upstream commit de95c40d ]
      
      On some platforms, the clocks might be registered by a platform
      driver. When this is the case, the clock platform driver may very well
      be probed after xhci-plat, in which case the first probe() invocation
      of xhci-plat will receive -EPROBE_DEFER as the return value of
      devm_clk_get().
      
      The current code handles that as a normal error, and simply assumes
      that this means that the system doesn't have a clock for the XHCI
      controller, and continues probing without calling
      clk_prepare_enable(). Unfortunately, this doesn't work on systems
      where the XHCI controller does have a clock, but that clock is
      provided by another platform driver. In order to fix this situation,
      we handle the -EPROBE_DEFER error condition specially, and abort the
      XHCI controller probe(). It will be retried later automatically, the
      clock will be available, devm_clk_get() will succeed, and the probe()
      will continue with the clock prepared and enabled as expected.
      
      In practice, such issue is seen on the ARM64 Marvell 7K/8K platform,
      where the clocks are registered by a platform driver.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      0c3f25d8
    • Mathias Nyman's avatar
      xhci: Fix handling timeouted commands on hosts in weird states. · e78c8a57
      Mathias Nyman authored
      [ Upstream commit 3425aa03 ]
      
      If commands timeout we mark them for abortion, then stop the command
      ring, and turn the commands to no-ops and finally restart the command
      ring.
      
      If the host is working properly the no-op commands will finish and
      pending completions are called.
      If we notice the host is failing, driver clears the command ring and
      completes, deletes and frees all pending commands.
      
      There are two separate cases reported where host is believed to work
      properly but is not. In the first case we successfully stop the ring
      but no abort or stop command ring event is ever sent and host locks up.
      
      The second case is if a host is removed, command times out and driver
      believes the ring is stopped, and assumes it will be restarted, but
      actually ends up timing out on the same command forever.
      If one of the pending commands has the xhci->mutex held it will block
      xhci_stop() in the remove codepath which otherwise would cleanup pending
      commands.
      
      Add a check that clears all pending commands in case host is removed,
      or we are stuck timing out on the same command. Also restart the
      command timeout timer when stopping the command ring to ensure we
      recive an ring stop/abort event.
      
      Cc: stable <stable@vger.kernel.org>
      Tested-by: default avatarJoe Lawrence <joe.lawrence@stratus.com>
      Signed-off-by: default avatarMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      e78c8a57
    • Oliver Neukum's avatar
      HID: elo: kill not flush the work · b71d1794
      Oliver Neukum authored
      [ Upstream commit ed596a4a ]
      
      Flushing a work that reschedules itself is not a sensible operation. It needs
      to be killed. Failure to do so leads to a kernel panic in the timer code.
      
      CC: stable@vger.kernel.org
      Signed-off-by: default avatarOliver Neukum <ONeukum@suse.com>
      Reviewed-by: default avatarBenjamin Tissoires <benjamin.tissoires@redhat.com>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      b71d1794
    • Bin Liu's avatar
      usb: gadget: fix spinlock dead lock in gadgetfs · 1aaee5de
      Bin Liu authored
      [ Upstream commit d246dcb2 ]
      
      [   40.467381] =============================================
      [   40.473013] [ INFO: possible recursive locking detected ]
      [   40.478651] 4.6.0-08691-g7f3db9a #37 Not tainted
      [   40.483466] ---------------------------------------------
      [   40.489098] usb/733 is trying to acquire lock:
      [   40.493734]  (&(&dev->lock)->rlock){-.....}, at: [<bf129288>] ep0_complete+0x18/0xdc [gadgetfs]
      [   40.502882]
      [   40.502882] but task is already holding lock:
      [   40.508967]  (&(&dev->lock)->rlock){-.....}, at: [<bf12a420>] ep0_read+0x20/0x5e0 [gadgetfs]
      [   40.517811]
      [   40.517811] other info that might help us debug this:
      [   40.524623]  Possible unsafe locking scenario:
      [   40.524623]
      [   40.530798]        CPU0
      [   40.533346]        ----
      [   40.535894]   lock(&(&dev->lock)->rlock);
      [   40.540088]   lock(&(&dev->lock)->rlock);
      [   40.544284]
      [   40.544284]  *** DEADLOCK ***
      [   40.544284]
      [   40.550461]  May be due to missing lock nesting notation
      [   40.550461]
      [   40.557544] 2 locks held by usb/733:
      [   40.561271]  #0:  (&f->f_pos_lock){+.+.+.}, at: [<c02a6114>] __fdget_pos+0x40/0x48
      [   40.569219]  #1:  (&(&dev->lock)->rlock){-.....}, at: [<bf12a420>] ep0_read+0x20/0x5e0 [gadgetfs]
      [   40.578523]
      [   40.578523] stack backtrace:
      [   40.583075] CPU: 0 PID: 733 Comm: usb Not tainted 4.6.0-08691-g7f3db9a #37
      [   40.590246] Hardware name: Generic AM33XX (Flattened Device Tree)
      [   40.596625] [<c010ffbc>] (unwind_backtrace) from [<c010c1bc>] (show_stack+0x10/0x14)
      [   40.604718] [<c010c1bc>] (show_stack) from [<c04207fc>] (dump_stack+0xb0/0xe4)
      [   40.612267] [<c04207fc>] (dump_stack) from [<c01886ec>] (__lock_acquire+0xf68/0x1994)
      [   40.620440] [<c01886ec>] (__lock_acquire) from [<c0189528>] (lock_acquire+0xd8/0x238)
      [   40.628621] [<c0189528>] (lock_acquire) from [<c06ad6b4>] (_raw_spin_lock_irqsave+0x38/0x4c)
      [   40.637440] [<c06ad6b4>] (_raw_spin_lock_irqsave) from [<bf129288>] (ep0_complete+0x18/0xdc [gadgetfs])
      [   40.647339] [<bf129288>] (ep0_complete [gadgetfs]) from [<bf10a728>] (musb_g_giveback+0x118/0x1b0 [musb_hdrc])
      [   40.657842] [<bf10a728>] (musb_g_giveback [musb_hdrc]) from [<bf108768>] (musb_g_ep0_queue+0x16c/0x188 [musb_hdrc])
      [   40.668772] [<bf108768>] (musb_g_ep0_queue [musb_hdrc]) from [<bf12a944>] (ep0_read+0x544/0x5e0 [gadgetfs])
      [   40.678963] [<bf12a944>] (ep0_read [gadgetfs]) from [<c0284470>] (__vfs_read+0x20/0x110)
      [   40.687414] [<c0284470>] (__vfs_read) from [<c0285324>] (vfs_read+0x88/0x114)
      [   40.694864] [<c0285324>] (vfs_read) from [<c0286150>] (SyS_read+0x44/0x9c)
      [   40.702051] [<c0286150>] (SyS_read) from [<c0107820>] (ret_fast_syscall+0x0/0x1c)
      
      This is caused by the spinlock bug in ep0_read().
      Fix the two other deadlock sources in gadgetfs_setup() too.
      
      Cc: <stable@vger.kernel.org> # v3.16+
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      1aaee5de
    • Steinar H. Gunderson's avatar
      usb: dwc3: exynos: Fix deferred probing storm. · a56c72fc
      Steinar H. Gunderson authored
      [ Upstream commit 4879efb3 ]
      
      dwc3-exynos has two problems during init if the regulators are slow
      to come up (for instance if the I2C bus driver is not on the initramfs)
      and return probe deferral. First, every time this happens, the driver
      leaks the USB phys created; they need to be deallocated on error.
      
      Second, since the phy devices are created before the regulators fail,
      this means that there's a new device to re-trigger deferred probing,
      which causes it to essentially go into a busy loop of re-probing the
      device until the regulators come up.
      
      Move the phy creation to after the regulators have succeeded, and also
      fix cleanup on failure. On my ODROID XU4 system (with Debian's initramfs
      which doesn't contain the I2C driver), this reduces the number of probe
      attempts (for each of the two controllers) from more than 2000 to eight.
      Signed-off-by: default avatarSteinar H. Gunderson <sesse@google.com>
      Reviewed-by: default avatarKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Reviewed-by: default avatarVivek Gautam <gautam.vivek@samsung.com>
      Fixes: d720f057 ("usb: dwc3: exynos: add nop transceiver support")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sasha.levin@oracle.com>
      a56c72fc