1. 03 Mar, 2018 26 commits
  2. 28 Feb, 2018 14 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.4.119 · 5e0c4113
      Greg Kroah-Hartman authored
      5e0c4113
    • Eric Biggers's avatar
      binder: add missing binder_unlock() · bf5a6a72
      Eric Biggers authored
      When commit 4be5a281 ("binder: check for binder_thread allocation
      failure in binder_poll()") was applied to 4.4-stable and 4.9-stable it
      was forgotten to release the global binder lock in the new error path.
      The global binder lock wasn't removed until v4.14, by commit
      a60b890f ("binder: remove global binder lock").
      
      Fix the new error path to release the lock.
      Reported-by: default avatarGuenter Roeck <linux@roeck-us.net>
      Signed-off-by: default avatarEric Biggers <ebiggers@google.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bf5a6a72
    • Alex Deucher's avatar
      drm/amdgpu: Avoid leaking PM domain on driver unbind (v2) · 2938d3b2
      Alex Deucher authored
      commit 458d876e upstream.
      
      We only support vga_switcheroo and runtime pm on PX/HG systems
      so forcing runpm to 1 doesn't do anything useful anyway.
      
      Only call vga_switcheroo_init_domain_pm_ops() for PX/HG so
      that the cleanup path is correct as well.  This mirrors what
      radeon does as well.
      
      v2: rework the patch originally sent by Lukas (Alex)
      Acked-by: default avatarLukas Wunner <lukas@wunner.de>
      Reported-by: default avatarLukas Wunner <lukas@wunner.de>
      Signed-off-by: default avatarAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: Lukas Wunner <lukas@wunner.de> (v1)
      Cc: stable@vger.kernel.org
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2938d3b2
    • Yoshihiro Shimoda's avatar
      usb: renesas_usbhs: missed the "running" flag in usb_dmac with rx path · 8565e400
      Yoshihiro Shimoda authored
      commit 17aa31f1 upstream.
      
      This fixes an issue that a gadget driver (usb_f_fs) is possible to
      stop rx transactions after the usb-dmac is used because the following
      functions missed to set/check the "running" flag.
       - usbhsf_dma_prepare_pop_with_usb_dmac()
       - usbhsf_dma_pop_done_with_usb_dmac()
      
      So, if next transaction uses pio, the usbhsf_prepare_pop() can not
      start the transaction because the "running" flag is 0.
      
      Fixes: 8355b2b3 ("usb: renesas_usbhs: fix the behavior of some usbhs_pkt_handle")
      Cc: <stable@vger.kernel.org> # v3.19+
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8565e400
    • Jack Pham's avatar
      usb: gadget: f_fs: Process all descriptors during bind · 7a67ec75
      Jack Pham authored
      commit 6cf439e0 upstream.
      
      During _ffs_func_bind(), the received descriptors are evaluated
      to prepare for binding with the gadget in order to allocate
      endpoints and optionally set up OS descriptors. However, the
      high- and super-speed descriptors are only parsed based on
      whether the gadget_is_dualspeed() and gadget_is_superspeed()
      calls are true, respectively.
      
      This is a problem in case a userspace program always provides
      all of the {full,high,super,OS} descriptors when configuring a
      function. Then, for example if a gadget device is not capable
      of SuperSpeed, the call to ffs_do_descs() for the SS descriptors
      is skipped, resulting in an incorrect offset calculation for
      the vla_ptr when moving on to the OS descriptors that follow.
      This causes ffs_do_os_descs() to fail as it is now looking at
      the SS descriptors' offset within the raw_descs buffer instead.
      
      _ffs_func_bind() should evaluate the descriptors unconditionally,
      so remove the checks for gadget speed.
      
      Fixes: f0175ab5 ("usb: gadget: f_fs: OS descriptors support")
      Cc: stable@vger.kernel.org
      Co-Developed-by: default avatarMayank Rana <mrana@codeaurora.org>
      Signed-off-by: default avatarMayank Rana <mrana@codeaurora.org>
      Signed-off-by: default avatarJack Pham <jackp@codeaurora.org>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7a67ec75
    • Karsten Koop's avatar
      usb: ldusb: add PIDs for new CASSY devices supported by this driver · c54c3c7c
      Karsten Koop authored
      commit 52ad2bd8 upstream.
      
      This patch adds support for new CASSY devices to the ldusb driver. The
      PIDs are also added to the ignore list in hid-quirks.
      Signed-off-by: default avatarKarsten Koop <kkoop@ld-didactic.de>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c54c3c7c
    • Thinh Nguyen's avatar
      usb: dwc3: gadget: Set maxpacket size for ep0 IN · 2421986b
      Thinh Nguyen authored
      commit 61800263 upstream.
      
      There are 2 control endpoint structures for DWC3. However, the driver
      only updates the OUT direction control endpoint structure during
      ConnectDone event. DWC3 driver needs to update the endpoint max packet
      size for control IN endpoint as well. If the max packet size is not
      properly set, then the driver will incorrectly calculate the data
      transfer size and fail to send ZLP for HS/FS 3-stage control read
      transfer.
      
      The fix is simply to update the max packet size for the ep0 IN direction
      during ConnectDone event.
      
      Cc: stable@vger.kernel.org
      Fixes: 72246da4 ("usb: Introduce DesignWare USB3 DRD Driver")
      Signed-off-by: default avatarThinh Nguyen <thinhn@synopsys.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2421986b
    • Kai-Heng Feng's avatar
      drm/edid: Add 6 bpc quirk for CPT panel in Asus UX303LA · 5b7ed414
      Kai-Heng Feng authored
      commit 06998a75 upstream.
      
      Similar to commit e10aec65 ("drm/edid: Add 6 bpc quirk for display
      AEO model 0."), the EDID reports "DFP 1.x compliant TMDS" but it support
      6bpc instead of 8 bpc.
      
      Hence, use 6 bpc quirk for this panel.
      
      Fixes: 196f954e ("drm/i915/dp: Revert "drm/i915/dp: fall back to 18 bpp when sink capability is unknown"")
      BugLink: https://bugs.launchpad.net/bugs/1749420Signed-off-by: default avatarKai-Heng Feng <kai.heng.feng@canonical.com>
      Reviewed-by: default avatarMario Kleiner <mario.kleiner.de@gmail.com>
      Cc: <stable@vger.kernel.org> # v4.8+
      Signed-off-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/20180218085359.7817-1-kai.heng.feng@canonical.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5b7ed414
    • Jack Stocker's avatar
      Add delay-init quirk for Corsair K70 RGB keyboards · e587f0e7
      Jack Stocker authored
      commit 7a1646d9 upstream.
      
      Following on from this patch: https://lkml.org/lkml/2017/11/3/516,
      Corsair K70 RGB keyboards also require the DELAY_INIT quirk to
      start correctly at boot.
      
      Device ids found here:
      usb 3-3: New USB device found, idVendor=1b1c, idProduct=1b13
      usb 3-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
      usb 3-3: Product: Corsair K70 RGB Gaming Keyboard
      Signed-off-by: default avatarJack Stocker <jackstocker.93@gmail.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e587f0e7
    • Michael Weiser's avatar
      arm64: Disable unhandled signal log messages by default · 56b57bd2
      Michael Weiser authored
      commit 5ee39a71 upstream.
      
      aarch64 unhandled signal kernel messages are very verbose, suggesting
      them to be more of a debugging aid:
      
      sigsegv[33]: unhandled level 2 translation fault (11) at 0x00000000, esr
      0x92000046, in sigsegv[400000+71000]
      CPU: 1 PID: 33 Comm: sigsegv Tainted: G        W        4.15.0-rc3+ #3
      Hardware name: linux,dummy-virt (DT)
      pstate: 60000000 (nZCv daif -PAN -UAO)
      pc : 0x4003f4
      lr : 0x4006bc
      sp : 0000fffffe94a060
      x29: 0000fffffe94a070 x28: 0000000000000000
      x27: 0000000000000000 x26: 0000000000000000
      x25: 0000000000000000 x24: 00000000004001b0
      x23: 0000000000486ac8 x22: 00000000004001c8
      x21: 0000000000000000 x20: 0000000000400be8
      x19: 0000000000400b30 x18: 0000000000484728
      x17: 000000000865ffc8 x16: 000000000000270f
      x15: 00000000000000b0 x14: 0000000000000002
      x13: 0000000000000001 x12: 0000000000000000
      x11: 0000000000000000 x10: 0008000020008008
      x9 : 000000000000000f x8 : ffffffffffffffff
      x7 : 0004000000000000 x6 : ffffffffffffffff
      x5 : 0000000000000000 x4 : 0000000000000000
      x3 : 00000000004003e4 x2 : 0000fffffe94a1e8
      x1 : 000000000000000a x0 : 0000000000000000
      
      Disable them by default, so they can be enabled using
      /proc/sys/debug/exception-trace.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: default avatarMichael Weiser <michael.weiser@gmx.de>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      56b57bd2
    • AMAN DEEP's avatar
      usb: ohci: Proper handling of ed_rm_list to handle race condition between... · 04dcdd0e
      AMAN DEEP authored
      usb: ohci: Proper handling of ed_rm_list to handle race condition between usb_kill_urb() and finish_unlinks()
      
      commit 46408ea5 upstream.
      
      There is a race condition between finish_unlinks->finish_urb() function
      and usb_kill_urb() in ohci controller case. The finish_urb calls
      spin_unlock(&ohci->lock) before usb_hcd_giveback_urb() function call,
      then if during this time, usb_kill_urb is called for another endpoint,
      then new ed will be added to ed_rm_list at beginning for unlink, and
      ed_rm_list will point to newly added.
      
      When finish_urb() is completed in finish_unlinks() and ed->td_list
      becomes empty as in below code (in finish_unlinks() function):
      
              if (list_empty(&ed->td_list)) {
                      *last = ed->ed_next;
                      ed->ed_next = NULL;
              } else if (ohci->rh_state == OHCI_RH_RUNNING) {
                      *last = ed->ed_next;
                      ed->ed_next = NULL;
                      ed_schedule(ohci, ed);
              }
      
      The *last = ed->ed_next will make ed_rm_list to point to ed->ed_next
      and previously added ed by usb_kill_urb will be left unreferenced by
      ed_rm_list. This causes usb_kill_urb() hang forever waiting for
      finish_unlink to remove added ed from ed_rm_list.
      
      The main reason for hang in this race condtion is addition and removal
      of ed from ed_rm_list in the beginning during usb_kill_urb and later
      last* is modified in finish_unlinks().
      
      As suggested by Alan Stern, the solution for proper handling of
      ohci->ed_rm_list is to remove ed from the ed_rm_list before finishing
      any URBs. Then at the end, we can add ed back to the list if necessary.
      
      This properly handle the updated ohci->ed_rm_list in usb_kill_urb().
      
      Fixes: 977dcfdc ("USB: OHCI: don't lose track of EDs when a controller dies")
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      CC: <stable@vger.kernel.org>
      Signed-off-by: default avatarAman Deep <aman.deep@samsung.com>
      Signed-off-by: default avatarJeffy Chen <jeffy.chen@rock-chips.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      
      04dcdd0e
    • Shanker Donthineni's avatar
      irqchip/gic-v3: Use wmb() instead of smb_wmb() in gic_raise_softirq() · 9eda5e8c
      Shanker Donthineni authored
      commit 21ec30c0 upstream.
      
      A DMB instruction can be used to ensure the relative order of only
      memory accesses before and after the barrier. Since writes to system
      registers are not memory operations, barrier DMB is not sufficient
      for observability of memory accesses that occur before ICC_SGI1R_EL1
      writes.
      
      A DSB instruction ensures that no instructions that appear in program
      order after the DSB instruction, can execute until the DSB instruction
      has completed.
      
      Cc: stable@vger.kernel.org
      Acked-by: Will Deacon <will.deacon@arm.com>,
      Signed-off-by: default avatarShanker Donthineni <shankerd@codeaurora.org>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9eda5e8c
    • Arnd Bergmann's avatar
      x86/oprofile: Fix bogus GCC-8 warning in nmi_setup() · e169f13c
      Arnd Bergmann authored
      commit 85c615eb upstream.
      
      GCC-8 shows a warning for the x86 oprofile code that copies per-CPU
      data from CPU 0 to all other CPUs, which when building a non-SMP
      kernel turns into a memcpy() with identical source and destination
      pointers:
      
       arch/x86/oprofile/nmi_int.c: In function 'mux_clone':
       arch/x86/oprofile/nmi_int.c:285:2: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
         memcpy(per_cpu(cpu_msrs, cpu).multiplex,
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                per_cpu(cpu_msrs, 0).multiplex,
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
                sizeof(struct op_msr) * model->num_virt_counters);
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       arch/x86/oprofile/nmi_int.c: In function 'nmi_setup':
       arch/x86/oprofile/nmi_int.c:466:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
       arch/x86/oprofile/nmi_int.c:470:3: error: 'memcpy' source argument is the same as destination [-Werror=restrict]
      
      I have analyzed a number of such warnings now: some are valid and the
      GCC warning is welcome. Others turned out to be false-positives, and
      GCC was changed to not warn about those any more. This is a corner case
      that is a false-positive but the GCC developers feel it's better to keep
      warning about it.
      
      In this case, it seems best to work around it by telling GCC
      a little more clearly that this code path is never hit with
      an IS_ENABLED() configuration check.
      
      Cc:stable as we also want old kernels to build cleanly with GCC-8.
      Signed-off-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: Jessica Yu <jeyu@kernel.org>
      Cc: Kees Cook <keescook@chromium.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Martin Sebor <msebor@gcc.gnu.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Robert Richter <rric@kernel.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: oprofile-list@lists.sf.net
      Cc: stable@vger.kernel.org
      Link: http://lkml.kernel.org/r/20180220205826.2008875-1-arnd@arndb.de
      Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84095Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e169f13c
    • Lars-Peter Clausen's avatar
      iio: adis_lib: Initialize trigger before requesting interrupt · b19f9c43
      Lars-Peter Clausen authored
      commit f027e0b3 upstream.
      
      The adis_probe_trigger() creates a new IIO trigger and requests an
      interrupt associated with the trigger. The interrupt uses the generic
      iio_trigger_generic_data_rdy_poll() function as its interrupt handler.
      
      Currently the driver initializes some fields of the trigger structure after
      the interrupt has been requested. But an interrupt can fire as soon as it
      has been requested. This opens up a race condition.
      
      iio_trigger_generic_data_rdy_poll() will access the trigger data structure
      and dereference the ops field. If the ops field is not yet initialized this
      will result in a NULL pointer deref.
      
      It is not expected that the device generates an interrupt at this point, so
      typically this issue did not surface unless e.g. due to a hardware
      misconfiguration (wrong interrupt number, wrong polarity, etc.).
      
      But some newer devices from the ADIS family start to generate periodic
      interrupts in their power-on reset configuration and unfortunately the
      interrupt can not be masked in the device.  This makes the race condition
      much more visible and the following crash has been observed occasionally
      when booting a system using the ADIS16460.
      
      	Unable to handle kernel NULL pointer dereference at virtual address 00000008
      	pgd = c0004000
      	[00000008] *pgd=00000000
      	Internal error: Oops: 5 [#1] PREEMPT SMP ARM
      	Modules linked in:
      	CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.9.0-04126-gf9739f0-dirty #257
      	Hardware name: Xilinx Zynq Platform
      	task: ef04f640 task.stack: ef050000
      	PC is at iio_trigger_notify_done+0x30/0x68
      	LR is at iio_trigger_generic_data_rdy_poll+0x18/0x20
      	pc : [<c042d868>]    lr : [<c042d924>]    psr: 60000193
      	sp : ef051bb8  ip : 00000000  fp : ef106400
      	r10: c081d80a  r9 : ef3bfa00  r8 : 00000087
      	r7 : ef051bec  r6 : 00000000  r5 : ef3bfa00  r4 : ee92ab00
      	r3 : 00000000  r2 : 00000000  r1 : 00000000  r0 : ee97e400
      	Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment none
      	Control: 18c5387d  Table: 0000404a  DAC: 00000051
      	Process swapper/0 (pid: 1, stack limit = 0xef050210)
      	[<c042d868>] (iio_trigger_notify_done) from [<c0065b10>] (__handle_irq_event_percpu+0x88/0x118)
      	[<c0065b10>] (__handle_irq_event_percpu) from [<c0065bbc>] (handle_irq_event_percpu+0x1c/0x58)
      	[<c0065bbc>] (handle_irq_event_percpu) from [<c0065c30>] (handle_irq_event+0x38/0x5c)
      	[<c0065c30>] (handle_irq_event) from [<c0068e28>] (handle_level_irq+0xa4/0x130)
      	[<c0068e28>] (handle_level_irq) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
      	[<c0064e74>] (generic_handle_irq) from [<c021ab7c>] (zynq_gpio_irqhandler+0xb8/0x13c)
      	[<c021ab7c>] (zynq_gpio_irqhandler) from [<c0064e74>] (generic_handle_irq+0x24/0x34)
      	[<c0064e74>] (generic_handle_irq) from [<c0065370>] (__handle_domain_irq+0x5c/0xb4)
      	[<c0065370>] (__handle_domain_irq) from [<c000940c>] (gic_handle_irq+0x48/0x8c)
      	[<c000940c>] (gic_handle_irq) from [<c0013e8c>] (__irq_svc+0x6c/0xa8)
      
      To fix this make sure that the trigger is fully initialized before
      requesting the interrupt.
      
      Fixes: ccd2b52f ("staging:iio: Add common ADIS library")
      Reported-by: default avatarRobin Getz <Robin.Getz@analog.com>
      Signed-off-by: default avatarLars-Peter Clausen <lars@metafoo.de>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: default avatarJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b19f9c43