1. 11 8月, 2015 1 次提交
    • J
      HID: wacom: Report correct device resolution when using the wireless adapater · 0be01712
      Jason Gerecke 提交于
      The 'wacom_wireless_work' function does not recalculate the tablet's
      resolution, causing the value contained in the 'features' struct to
      always be reported to userspace. This value is valid only for the pen
      interface, meaning that the value will be incorrect for the touchpad (if
      present). This in particular causes problems for libinput which relies
      on the reported resolution being correct.
      
      This patch adds the necessary calls to recalculate the resolution for
      each interface. This requires a little bit of code shuffling since both
      the 'wacom_set_default_phy' and 'wacom_calculate_res' are declared below
      their new first point of use in 'wacom_wireless_work'.
      Signed-off-by: NJason Gerecke <jason.gerecke@wacom.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.cz>
      0be01712
  2. 10 8月, 2015 14 次提交
  3. 08 8月, 2015 1 次提交
  4. 07 8月, 2015 2 次提交
  5. 06 8月, 2015 8 次提交
  6. 05 8月, 2015 5 次提交
  7. 04 8月, 2015 9 次提交
    • R
      xen/events/fifo: Handle linked events when closing a port · fcdf31a7
      Ross Lagerwall 提交于
      An event channel bound to a CPU that was offlined may still be linked
      on that CPU's queue.  If this event channel is closed and reused,
      subsequent events will be lost because the event channel is never
      unlinked and thus cannot be linked onto the correct queue.
      
      When a channel is closed and the event is still linked into a queue,
      ensure that it is unlinked before completing.
      
      If the CPU to which the event channel bound is online, spin until the
      event is handled by that CPU. If that CPU is offline, it can't handle
      the event, so clear the event queue during the close, dropping the
      events.
      
      This fixes the missing interrupts (and subsequent disk stalls etc.)
      when offlining a CPU.
      Signed-off-by: NRoss Lagerwall <ross.lagerwall@citrix.com>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NDavid Vrabel <david.vrabel@citrix.com>
      fcdf31a7
    • K
      HID: hid-input: Fix accessing freed memory during device disconnect · 0621809e
      Krzysztof Kozlowski 提交于
      During unbinding the driver was dereferencing a pointer to memory
      already freed by power_supply_unregister().
      
      Driver was freeing its internal description of battery through pointers
      stored in power_supply structure. However, because the core owns the
      power supply instance, after calling power_supply_unregister() this
      memory is freed and the driver cannot access these members.
      
      Fix this by storing the pointer to internal description of battery in a
      local variable before calling power_supply_unregister(), so the pointer
      remains valid.
      Signed-off-by: NKrzysztof Kozlowski <k.kozlowski@samsung.com>
      Reported-by: NH.J. Lu <hjl.tools@gmail.com>
      Fixes: 297d716f ("power_supply: Change ownership from driver to core")
      Cc: <stable@vger.kernel.org>
      Reviewed-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Signed-off-by: NJiri Kosina <jkosina@suse.com>
      0621809e
    • D
      drm/atomic-helpers: Make encoder picking more robust · 6ea76f3c
      Daniel Vetter 提交于
      We've had a few issues with atomic where subtle bugs in the encoder
      picking logic lead to accidental self-stealing of the encoder,
      resulting in a NULL connector_state->crtc in update_connector_routing
      and subsequent.
      
      Linus applied some duct-tape for an mst regression in
      
      commit 27667f47
      Author: Linus Torvalds <torvalds@linux-foundation.org>
      Date:   Wed Jul 29 22:18:16 2015 -0700
      
          i915: temporary fix for DP MST docking station NULL pointer dereference
      
      But that was incomplete (the code will still oops when debuggin is
      enabled) and mangled the state even further. So instead WARN and bail
      out as the more future-proof option.
      
      Cc: Theodore Ts'o <tytso@mit.edu>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Reviewed-by: NThierry Reding <treding@nvidia.com>
      Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      6ea76f3c
    • D
      drm/dp-mst: Remove debug WARN_ON · 42639ba5
      Daniel Vetter 提交于
      Apparently been in there since forever and fairly easy to hit when
      hotplugging really fast. I can do that since my mst hub has a manual
      button to flick the hpd line for reprobing. The resulting WARNING spam
      isn't pretty.
      
      Cc: Dave Airlie <airlied@gmail.com>
      Cc: stable@vger.kernel.org
      Reviewed-by: NThierry Reding <treding@nvidia.com>
      Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      42639ba5
    • D
      drm/i915: Fixup dp mst encoder selection · 459485ad
      Daniel Vetter 提交于
      In
      
      commit 8c7b5ccb
      Author: Ander Conselvan de Oliveira <ander.conselvan.de.oliveira@intel.com>
      Date:   Tue Apr 21 17:13:19 2015 +0300
      
          drm/i915: Use atomic helpers for computing changed flags
      
      we've switched over to the atomic version to compute the
      crtc->encoder->connector routing from the i915 variant. That one
      relies upon the ->best_encoder callback, but the i915-private version
      relied upon intel_find_encoder. Which didn't matter except for dp mst,
      where the encoder depends upon the selected crtc.
      
      Fix this functional bug by implemented a correct atomic-state based
      encoder selector for dp mst.
      
      Note that we can't get rid of the legacy best_encoder callback since
      the fbdev emulation uses that still. That means it's incorrect there
      still, but that's been the case ever since i915 dp mst support was
      merged so not a regression. Best to fix that by converting fbdev over
      to atomic too.
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      459485ad
    • D
      drm/atomic-helper: Add an atomice best_encoder callback · 3b8a684b
      Daniel Vetter 提交于
      With legacy helpers all the routing was already set up when calling
      best_encoder and so could be inspected. But with atomic it's staged,
      hence we need a new atomic compliant callback for drivers which need
      to inspect the requested state and can't just decided the best encoder
      statically.
      
      This is needed to fix up i915 dp mst where we need to pick the right
      encoder depending upon the requested CRTC for the connector.
      
      v2: Don't forget to amend the kerneldoc
      
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Theodore Ts'o <tytso@mit.edu>
      Acked-by: NThierry Reding <treding@nvidia.com>
      Reviewed-by: NAnder Conselvan de Oliveira <conselvan2@gmail.com>
      Signed-off-by: NDaniel Vetter <daniel.vetter@intel.com>
      3b8a684b
    • M
      dm: fix dm_merge_bvec regression on 32 bit systems · bd4aaf8f
      Mike Snitzer 提交于
      A DM regression on 32 bit systems was reported against v4.2-rc3 here:
      https://lkml.org/lkml/2015/7/29/401
      
      Fix this by reverting both commit 1c220c69 ("dm: fix casting bug in
      dm_merge_bvec()") and 148e51ba ("dm: improve documentation and code
      clarity in dm_merge_bvec").  This combined revert is done to eliminate
      the possibility of a partial revert in stable@ kernels.
      
      In hindsight the correct fix, at the time 1c220c69 was applied to fix
      the regression that 148e51ba introduced, should've been to simply revert
      148e51ba.
      Reported-by: NJosh Boyer <jwboyer@fedoraproject.org>
      Tested-by: NAdam Williamson <awilliam@redhat.com>
      Acked-by: NJoe Thornber <ejt@redhat.com>
      Signed-off-by: NMike Snitzer <snitzer@redhat.com>
      Cc: stable@vger.kernel.org # 3.19+
      bd4aaf8f
    • M
      staging: vt6655: vnt_bss_info_changed check conf->beacon_rate is not NULL · 1f171240
      Malcolm Priestley 提交于
      conf->beacon_rate can be NULL on association. So check conf->beacon_rate
      
      BSS_CHANGED_BEACON_INFO needs to flagged in changed as the beacon_rate
      will appear later.
      Signed-off-by: NMalcolm Priestley <tvboxspy@gmail.com>
      Cc: <stable@vger.kernel.org> # v3.19+
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1f171240
    • G
      drivers/usb: Delete XHCI command timer if necessary · ffe5adcb
      Gavin Shan 提交于
      When xhci_mem_cleanup() is called, it's possible that the command
      timer isn't initialized and scheduled. For those cases, to delete
      the command timer causes soft-lockup as below stack dump shows.
      
      The patch avoids deleting the command timer if it's not scheduled
      with the help of timer_pending().
      
      NMI watchdog: BUG: soft lockup - CPU#40 stuck for 23s! [kworker/40:1:8140]
            :
      NIP [c000000000150b30] lock_timer_base.isra.34+0x90/0xa0
      LR [c000000000150c24] try_to_del_timer_sync+0x34/0xa0
      Call Trace:
      [c000000f67c975e0] [c0000000015b84f8] mon_ops+0x0/0x8 (unreliable)
      [c000000f67c97620] [c000000000150c24] try_to_del_timer_sync+0x34/0xa0
      [c000000f67c97660] [c000000000150cf0] del_timer_sync+0x60/0x80
      [c000000f67c97690] [c00000000070ac0c] xhci_mem_cleanup+0x5c/0x5e0
      [c000000f67c97740] [c00000000070c2e8] xhci_mem_init+0x1158/0x13b0
      [c000000f67c97860] [c000000000700978] xhci_init+0x88/0x110
      [c000000f67c978e0] [c000000000701644] xhci_gen_setup+0x2b4/0x590
      [c000000f67c97970] [c0000000006d4410] xhci_pci_setup+0x40/0x190
      [c000000f67c979f0] [c0000000006b1af8] usb_add_hcd+0x418/0xba0
      [c000000f67c97ab0] [c0000000006cb15c] usb_hcd_pci_probe+0x1dc/0x5c0
      [c000000f67c97b50] [c0000000006d3ba4] xhci_pci_probe+0x64/0x1f0
      [c000000f67c97ba0] [c0000000004fe9ac] local_pci_probe+0x6c/0x130
      [c000000f67c97c30] [c0000000000e5ce8] work_for_cpu_fn+0x38/0x60
      [c000000f67c97c60] [c0000000000eacb8] process_one_work+0x198/0x470
      [c000000f67c97cf0] [c0000000000eb6ac] worker_thread+0x37c/0x5a0
      [c000000f67c97d80] [c0000000000f2730] kthread+0x110/0x130
      [c000000f67c97e30] [c000000000009660] ret_from_kernel_thread+0x5c/0x7c
      
      Cc: <stable@vger.kernel.org>
      Reported-by: NPriya M. A <priyama2@in.ibm.com>
      Signed-off-by: NGavin Shan <gwshan@linux.vnet.ibm.com>
      Signed-off-by: NMathias Nyman <mathias.nyman@linux.intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ffe5adcb