1. 14 Feb, 2017 19 commits
  2. 09 Feb, 2017 21 commits
    • Greg Kroah-Hartman's avatar
      Linux 4.9.9 · d2e4b66b
      Greg Kroah-Hartman authored
      d2e4b66b
    • Chris Wilson's avatar
      drm/i915/execlists: Reset RING registers upon resume · f2a0409a
      Chris Wilson authored
      commit bafb2f7d upstream.
      
      There is a disparity in the context image saved to disk and our own
      bookkeeping - that is we presume the RING_HEAD and RING_TAIL match our
      stored ce->ring->tail value. However, as we emit WA_TAIL_DWORDS into the
      ring but may not tell the GPU about them, the GPU may be lagging behind
      our bookkeeping. Upon hibernation we do not save stolen pages, presuming
      that their contents are volatile. This means that although we start
      writing into the ring at tail, the GPU starts executing from its HEAD
      and there may be some garbage in between and so the GPU promptly hangs
      upon resume.
      
      Testcase: igt/gem_exec_suspend/basic-S4
      Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=96526Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
      Link: http://patchwork.freedesktop.org/patch/msgid/20160921135108.29574-3-chris@chris-wilson.co.uk
      Cc: Eric Blau <eblau1@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f2a0409a
    • Michal Hocko's avatar
      fs: break out of iomap_file_buffered_write on fatal signals · 72cd604c
      Michal Hocko authored
      commit d1908f52 upstream.
      
      Tetsuo has noticed that an OOM stress test which performs large write
      requests can cause the full memory reserves depletion.  He has tracked
      this down to the following path
      
      	__alloc_pages_nodemask+0x436/0x4d0
      	alloc_pages_current+0x97/0x1b0
      	__page_cache_alloc+0x15d/0x1a0          mm/filemap.c:728
      	pagecache_get_page+0x5a/0x2b0           mm/filemap.c:1331
      	grab_cache_page_write_begin+0x23/0x40   mm/filemap.c:2773
      	iomap_write_begin+0x50/0xd0             fs/iomap.c:118
      	iomap_write_actor+0xb5/0x1a0            fs/iomap.c:190
      	? iomap_write_end+0x80/0x80             fs/iomap.c:150
      	iomap_apply+0xb3/0x130                  fs/iomap.c:79
      	iomap_file_buffered_write+0x68/0xa0     fs/iomap.c:243
      	? iomap_write_end+0x80/0x80
      	xfs_file_buffered_aio_write+0x132/0x390 [xfs]
      	? remove_wait_queue+0x59/0x60
      	xfs_file_write_iter+0x90/0x130 [xfs]
      	__vfs_write+0xe5/0x140
      	vfs_write+0xc7/0x1f0
      	? syscall_trace_enter+0x1d0/0x380
      	SyS_write+0x58/0xc0
      	do_syscall_64+0x6c/0x200
      	entry_SYSCALL64_slow_path+0x25/0x25
      
      the oom victim has access to all memory reserves to make a forward
      progress to exit easier.  But iomap_file_buffered_write and other
      callers of iomap_apply loop to complete the full request.  We need to
      check for fatal signals and back off with a short write instead.
      
      As the iomap_apply delegates all the work down to the actor we have to
      hook into those.  All callers that work with the page cache are calling
      iomap_write_begin so we will check for signals there.  dax_iomap_actor
      has to handle the situation explicitly because it copies data to the
      userspace directly.  Other callers like iomap_page_mkwrite work on a
      single page or iomap_fiemap_actor do not allocate memory based on the
      given len.
      
      Fixes: 68a9f5e7 ("xfs: implement iomap based buffered write path")
      Link: http://lkml.kernel.org/r/20170201092706.9966-2-mhocko@kernel.orgSigned-off-by: default avatarMichal Hocko <mhocko@suse.com>
      Reported-by: default avatarTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Al Viro <viro@zeniv.linux.org.uk>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      72cd604c
    • Steve Wise's avatar
      iw_cxgb4: set correct FetchBurstMax for QPs · bf9ab22c
      Steve Wise authored
      commit b414fa01 upstream.
      
      The current QP FetchBurstMax value is 256B, which
      is incorrect since a WR can exceed that value.  The
      result being a partial WR fetched by hardware, and
      a fatal "bad WR" error posted by the SGE.
      
      So bump the FetchBurstMax to 512B.
      Signed-off-by: default avatarSteve Wise <swise@opengridcomputing.com>
      Signed-off-by: default avatarDoug Ledford <dledford@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bf9ab22c
    • Thomas Gleixner's avatar
      x86/irq: Make irq activate operations symmetric · 13363b69
      Thomas Gleixner authored
      commit aaaec6fc upstream.
      
      The recent commit which prevents double activation of interrupts unearthed
      interesting code in x86. The code (ab)uses irq_domain_activate_irq() to
      reconfigure an already activated interrupt. That trips over the prevention
      code now.
      
      Fix it by deactivating the interrupt before activating the new configuration.
      
      Fixes: 08d85f3e "irqdomain: Avoid activating interrupts more than once"
      Reported-and-tested-by: default avatarMike Galbraith <efault@gmx.de>
      Reported-and-tested-by: default avatarBorislav Petkov <bp@alien8.de>
      Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Cc: Andrey Ryabinin <aryabinin@virtuozzo.com>
      Cc: Marc Zyngier <marc.zyngier@arm.com>
      Link: http://lkml.kernel.org/r/alpine.DEB.2.20.1701311901580.3457@nanosSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      13363b69
    • Marc Zyngier's avatar
      irqdomain: Avoid activating interrupts more than once · e0213628
      Marc Zyngier authored
      commit 08d85f3e upstream.
      
      Since commit f3b0946d ("genirq/msi: Make sure PCI MSIs are
      activated early"), we can end-up activating a PCI/MSI twice (once
      at allocation time, and once at startup time).
      
      This is normally of no consequences, except that there is some
      HW out there that may misbehave if activate is used more than once
      (the GICv3 ITS, for example, uses the activate callback
      to issue the MAPVI command, and the architecture spec says that
      "If there is an existing mapping for the EventID-DeviceID
      combination, behavior is UNPREDICTABLE").
      
      While this could be worked around in each individual driver, it may
      make more sense to tackle the issue at the core level. In order to
      avoid getting in that situation, let's have a per-interrupt flag
      to remember if we have already activated that interrupt or not.
      
      Fixes: f3b0946d ("genirq/msi: Make sure PCI MSIs are activated early")
      Reported-and-tested-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Link: http://lkml.kernel.org/r/1484668848-24361-1-git-send-email-marc.zyngier@arm.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e0213628
    • Matt Ranostay's avatar
      iio: health: max30100: fixed parenthesis around FIFO count check · c6b0333b
      Matt Ranostay authored
      commit 828f84ee upstream.
      
      FIFO was being read every sample after the "almost full" state was
      reached. This was due to an incorrect placement of the parenthesis
      in the while condition check.
      
      Note - the fixes tag is not actually correct, but the fix in this patch
      would also be needed for it to function correctly so we'll go with that
      one.  Backports should pick up both.
      Signed-off-by: default avatarMatt Ranostay <matt@ranostay.consulting>
      Fixes: b74fccad ("iio: health: max30100: correct FIFO check condition")
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c6b0333b
    • John Brooks's avatar
      iio: dht11: Use usleep_range instead of msleep for start signal · 12c2fcf6
      John Brooks authored
      commit 5c113b5e upstream.
      
      The DHT22 (AM2302) datasheet specifies that the LOW start pulse should not
      exceed 20ms. However, observations with an oscilloscope of an RPi Model 2B
      (rev 1.1) communicating with a DHT22 sensor showed that the driver was
      consistently sending start pulses longer than 20ms:
      
      Kernel 4.7.10-v7+ (n=132):
          Minimum pulse length: 20.20ms
          Maximum:              29.84ms
          Mean:                 24.96ms
          StDev:                2.82ms
          Sensor response rate: 100%
          Read success rate:    76%
      
      On kernel 4.8, the start pulse was so long that the sensor would not even
      respond 97% of the time:
      
      Kernel 4.8.16-v7+ (n=100):
          Minimum pulse length: 30.4ms
          Maximum:              74.4ms
          Mean:                 39.3ms
          StDev:                10.2ms
          Sensor response rate: 3%
          Read success rate:    3%
      
      The driver would return ETIMEDOUT and write log messages like this:
      
      [   51.430987] dht11 dht11@0: Only 1 signal edges detected
      [   66.311019] dht11 dht11@0: Only 0 signal edges detected
      
      Replacing msleep(18) with usleep_range(18000, 20000) made the pulse length
      sane again and restored responsiveness:
      
      Kernel 4.8.16-v7+ with usleep_range (n=123):
          Minimum pulse length: 18.16ms
          Maximum:              20.20ms
          Mean:                 19.85ms
          StDev:                0.51ms
          Sensor response rate: 100%
          Read success rate:    84%
      Signed-off-by: default avatarJohn Brooks <john@fastquake.com>
      Reviewed-by: default avatarHarald Geyer <harald@ccbib.org>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      12c2fcf6
    • Alison Schofield's avatar
      iio: health: afe4403: retrieve a valid iio_dev in suspend/resume · 7baa8491
      Alison Schofield authored
      commit a5badd1e upstream.
      
      The suspend/resume functions were using dev_to_iio_dev() to get
      the iio_dev. That only works on IIO dev's.  Replace it with spi
      functions to get the correct iio_dev.
      Signed-off-by: default avatarAlison Schofield <amsfield22@gmail.com>
      Acked-by: default avatarAndrew F. Davis <afd@ti.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7baa8491
    • Alison Schofield's avatar
      iio: health: afe4404: retrieve a valid iio_dev in suspend/resume · 5f0ee562
      Alison Schofield authored
      commit 802ecfc1 upstream.
      
      The suspend/resume functions were using dev_to_iio_dev() to get
      the iio_dev. That only works on IIO dev's.  Replace it with i2c
      functions to get the correct iio_dev.
      Signed-off-by: default avatarAlison Schofield <amsfield22@gmail.com>
      Acked-by: default avatarAndrew F. Davis <afd@ti.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5f0ee562
    • Alison Schofield's avatar
      iio: adc: palmas_gpadc: retrieve a valid iio_dev in suspend/resume · 54d2ccc4
      Alison Schofield authored
      commit d1aaf20e upstream.
      
      The suspend/resume functions were using dev_to_iio_dev() to get
      the iio_dev. That only works on IIO dev's.  Use dev_get_drvdata()
      for a platform device to get the correct iio_dev.
      Signed-off-by: default avatarAlison Schofield <amsfield22@gmail.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      54d2ccc4
    • Rui Miguel Silva's avatar
      staging: greybus: timesync: validate platform state callback · db0e02ef
      Rui Miguel Silva authored
      commit b17c1bba upstream.
      
      When tearingdown timesync, and not in arche platform, the state platform
      callback is not initialized. That will trigger the following NULL
      dereferencing.
      CallTrace:
      
       ? gb_timesync_platform_unlock_bus+0x11/0x20 [greybus]
       gb_timesync_teardown+0x85/0xc0 [greybus]
       gb_timesync_svc_remove+0xab/0x190 [greybus]
       gb_svc_del+0x29/0x110 [greybus]
       gb_hd_del+0x14/0x20 [greybus]
       ap_disconnect+0x24/0x60 [gb_es2]
       usb_unbind_interface+0x7a/0x2c0
       __device_release_driver+0x96/0x150
       device_release_driver+0x1e/0x30
       bus_remove_device+0xe7/0x130
       device_del+0x116/0x230
       usb_disable_device+0x97/0x1f0
       usb_disconnect+0x80/0x260
       hub_event+0x5ca/0x10e0
       process_one_work+0x126/0x3b0
       worker_thread+0x55/0x4c0
       ? process_one_work+0x3b0/0x3b0
       kthread+0xc4/0xe0
       ? kthread_park+0xb0/0xb0
       ret_from_fork+0x22/0x30
      
      So, fix that by adding checks before use the callback.
      
      Fixes: 970dc85b ("greybus: timesync: Add timesync core driver")
      Signed-off-by: default avatarRui Miguel Silva <rmfrfs@gmail.com>
      Reviewed-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Reviewed-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db0e02ef
    • Bjørn Mork's avatar
      USB: serial: option: add device ID for HP lt2523 (Novatel E371) · 89cc65c1
      Bjørn Mork authored
      commit 5d03a2fd upstream.
      
      Yet another laptop vendor rebranded Novatel E371.
      Signed-off-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      89cc65c1
    • Vincent Pelletier's avatar
      usb: gadget: f_fs: Assorted buffer overflow checks. · 12a9c11c
      Vincent Pelletier authored
      commit 83e526f2 upstream.
      
      OS descriptor head, when flagged as provided, is accessed without
      checking if it fits in provided buffer. Verify length before access.
      Also, there are other places where buffer length it checked
      after accessing offsets which are potentially past the end. Check
      buffer length before as well to fail cleanly.
      Signed-off-by: default avatarVincent Pelletier <plr.vincent@gmail.com>
      Acked-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      12a9c11c
    • Tony Lindgren's avatar
      usb: musb: Fix host mode error -71 regression · e40d15fc
      Tony Lindgren authored
      commit 407788b5 upstream.
      
      Commit 467d5c98 ("usb: musb: Implement session bit based runtime PM for
      musb-core") started implementing musb generic runtime PM support by
      introducing devctl register session bit based state control.
      
      This caused a regression where if a USB mass storage device is connected
      to a USB hub, we can get:
      
      usb 1-1: reset high-speed USB device number 2 using musb-hdrc
      usb 1-1: device descriptor read/64, error -71
      usb 1-1.1: new high-speed USB device number 4 using musb-hdrc
      
      This is because before the USB storage device is connected, musb is
      in OTG_STATE_A_SUSPEND. And we currently only set need_finish_resume
      in musb_stage0_irq() and the related code calling finish_resume_work
      in musb_resume() and musb_runtime_resume() never gets called.
      
      To fix the issue, we can call schedule_delayed_work() directly in
      musb_stage0_irq() to have finish_resume_work run.
      
      And we should no longer never get interrupts when when suspended.
      We have changed musb to no longer need pm_runtime_irqsafe().
      The need_finish_resume flag was added in commit 9298b4aa ("usb:
      musb: fix device hotplug behind hub") and no longer applies as far
      as I can tell. So let's just remove the earlier code that no longer
      is needed.
      
      Fixes: 467d5c98 ("usb: musb: Implement session bit based runtime PM for musb-core")
      Reported-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Signed-off-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e40d15fc
    • Lukáš Lalinský's avatar
      USB: Add quirk for WORLDE easykey.25 MIDI keyboard · cbd819e7
      Lukáš Lalinský authored
      commit d9b2997e upstream.
      
      Add a quirk for WORLDE easykey.25 MIDI keyboard (idVendor=0218,
      idProduct=0401). The device reports that it has config string
      descriptor at index 3, but when the system selects the configuration
      and tries to get the description, it returns a -EPROTO error,
      the communication restarts and this keeps repeating over and over again.
      Not requesting the string descriptor makes the device work correctly.
      
      Relevant info from Wireshark:
      
      [...]
      
      CONFIGURATION DESCRIPTOR
          bLength: 9
          bDescriptorType: 0x02 (CONFIGURATION)
          wTotalLength: 101
          bNumInterfaces: 2
          bConfigurationValue: 1
          iConfiguration: 3
          Configuration bmAttributes: 0xc0  SELF-POWERED  NO REMOTE-WAKEUP
              1... .... = Must be 1: Must be 1 for USB 1.1 and higher
              .1.. .... = Self-Powered: This device is SELF-POWERED
              ..0. .... = Remote Wakeup: This device does NOT support remote wakeup
          bMaxPower: 50  (100mA)
      
      [...]
      
           45 0.369104       host                  2.38.0                USB      64     GET DESCRIPTOR Request STRING
      
      [...]
      
      URB setup
          bmRequestType: 0x80
              1... .... = Direction: Device-to-host
              .00. .... = Type: Standard (0x00)
              ...0 0000 = Recipient: Device (0x00)
          bRequest: GET DESCRIPTOR (6)
          Descriptor Index: 0x03
          bDescriptorType: 0x03
          Language Id: English (United States) (0x0409)
          wLength: 255
      
           46 0.369255       2.38.0                host                  USB      64     GET DESCRIPTOR Response STRING[Malformed Packet]
      
      [...]
      
      Frame 46: 64 bytes on wire (512 bits), 64 bytes captured (512 bits) on interface 0
      USB URB
          [Source: 2.38.0]
          [Destination: host]
          URB id: 0xffff88021f62d480
          URB type: URB_COMPLETE ('C')
          URB transfer type: URB_CONTROL (0x02)
          Endpoint: 0x80, Direction: IN
          Device: 38
          URB bus id: 2
          Device setup request: not relevant ('-')
          Data: present (0)
          URB sec: 1484896277
          URB usec: 455031
          URB status: Protocol error (-EPROTO) (-71)
          URB length [bytes]: 0
          Data length [bytes]: 0
          [Request in: 45]
          [Time from request: 0.000151000 seconds]
          Unused Setup Header
          Interval: 0
          Start frame: 0
          Copy of Transfer Flags: 0x00000200
          Number of ISO descriptors: 0
      [Malformed Packet: USB]
          [Expert Info (Error/Malformed): Malformed Packet (Exception occurred)]
              [Malformed Packet (Exception occurred)]
              [Severity level: Error]
              [Group: Malformed]
      Signed-off-by: default avatarLukáš Lalinský <lukas@oxygene.sk>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cbd819e7
    • Marcel J.E. Mol's avatar
      USB: serial: pl2303: add ATEN device ID · 4807725a
      Marcel J.E. Mol authored
      commit d07830db upstream.
      
      Seems that ATEN serial-to-usb devices using pl2303 exist with
      different device ids. This patch adds a missing device ID so it
      is recognised by the driver.
      Signed-off-by: default avatarMarcel J.E. Mol <marcel@mesa.nl>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4807725a
    • Aleksander Morgado's avatar
      USB: serial: qcserial: add Dell DW5570 QDL · 8bc382a9
      Aleksander Morgado authored
      commit 24d615a6 upstream.
      
      The Dell DW5570 is a re-branded Sierra Wireless MC8805 which will by
      default boot with vid 0x413c and pid 0x81a3. When triggered QDL download
      mode, the device switches to pid 0x81a6 and provides the standard TTY
      used for firmware upgrade.
      Signed-off-by: default avatarAleksander Morgado <aleksander@aleksander.es>
      Signed-off-by: default avatarJohan Hovold <johan@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8bc382a9
    • Radim Krčmář's avatar
      KVM: x86: do not save guest-unsupported XSAVE state · 0dcbd0aa
      Radim Krčmář authored
      commit 00c87e9a upstream.
      
      Saving unsupported state prevents migration when the new host does not
      support a XSAVE feature of the original host, even if the feature is not
      exposed to the guest.
      
      We've masked host features with guest-visible features before, with
      4344ee98 ("KVM: x86: only copy XSAVE state for the supported
      features") and dropped it when implementing XSAVES.  Do it again.
      
      Fixes: df1daba7 ("KVM: x86: support XSAVES usage in the host")
      Reviewed-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarRadim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0dcbd0aa
    • Tony Lindgren's avatar
      dmaengine: cppi41: Fix oops in cppi41_runtime_resume · bc05a2e9
      Tony Lindgren authored
      commit 362f4562 upstream.
      
      Commit fdea2d09 ("dmaengine: cppi41: Add basic PM runtime support")
      together with recent MUSB changes allowed USB and DMA on BeagleBone to idle
      when no cable is connected. But looks like few corner case issues still
      remain.
      
      Looks like just by re-plugging USB cable about ten or so times on BeagleBone
      when configured in USB peripheral mode we can get warnings and eventually
      trigger an oops in cppi41 DMA:
      
      WARNING: CPU: 0 PID: 14 at drivers/dma/cppi41.c:1154 cppi41_runtime_suspend+
      x28/0x38 [cppi41]
      ...
      
      WARNING: CPU: 0 PID: 14 at drivers/dma/cppi41.c:452
      push_desc_queue+0x94/0x9c [cppi41]
      ...
      
      Unable to handle kernel NULL pointer dereference at virtual
      address 00000104
      pgd = c0004000
      [00000104] *pgd=00000000
      Internal error: Oops: 805 [#1] SMP ARM
      ...
      [<bf0d92cc>] (cppi41_runtime_resume [cppi41]) from [<c0589838>]
      (__rpm_callback+0xc0/0x214)
      [<c0589838>] (__rpm_callback) from [<c05899ac>] (rpm_callback+0x20/0x80)
      [<c05899ac>] (rpm_callback) from [<c0589460>] (rpm_resume+0x504/0x78c)
      [<c0589460>] (rpm_resume) from [<c058a1a0>] (pm_runtime_work+0x60/0xa8)
      [<c058a1a0>] (pm_runtime_work) from [<c0156120>] (process_one_work+0x2b4/0x808)
      
      This is because of a race with runtime PM and cppi41_dma_issue_pending()
      as reported by Alexandre Bailon <abailon@baylibre.com> in earlier
      set of patches. Based on mailing list discussions we however came to the
      conclusion that a different fix from Alexandre's fix is needed in order
      to guarantee that DMA is really active when we try to use it.
      
      To fix the issue, we need to add a driver specific flag as we otherwise
      can have -EINPROGRESS state set by runtime PM and can't rely on
      pm_runtime_active() to tell us when we can use the DMA.
      
      And we need to make sure the DMA transfers get triggered in the queued
      order. So let's always queue the transfers, then flush the queue
      from both cppi41_dma_issue_pending() and cppi41_runtime_resume()
      as suggested by Grygorii Strashko <grygorii.strashko@ti.com> in an
      earlier example patch.
      
      For reference, this is also documented in Documentation/power/runtime_pm.txt
      in the example at the end of the file as pointed out by Grygorii Strashko
      <grygorii.strashko@ti.com>.
      
      Based on earlier patches from Alexandre Bailon <abailon@baylibre.com>
      and Grygorii Strashko <grygorii.strashko@ti.com> modified based on
      testing and what was discussed on the mailing lists.
      
      Fixes: fdea2d09 ("dmaengine: cppi41: Add basic PM runtime support")
      Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
      Cc: Bin Liu <b-liu@ti.com>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: Patrick Titiano <ptitiano@baylibre.com>
      Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Reported-by: default avatarAlexandre Bailon <abailon@baylibre.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Tested-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bc05a2e9
    • Tony Lindgren's avatar
      dmaengine: cppi41: Fix runtime PM timeouts with USB mass storage · 2c2e7fe7
      Tony Lindgren authored
      commit ae4a3e02 upstream.
      
      Commit fdea2d09 ("dmaengine: cppi41: Add basic PM runtime support")
      added runtime PM support for cppi41, but had corner case issues. Some of
      the issues were fixed with commit 098de42a ("dmaengine: cppi41: Fix
      unpaired pm runtime when only a USB hub is connected"). That fix however
      caused a new regression where we can get error -115 messages with USB on
      BeagleBone when connecting a USB mass storage device to a hub.
      
      This is because when connecting a USB mass storage device to a hub, the
      initial DMA transfers can take over 200ms to complete and cppi41
      autosuspend delay times out.
      
      To fix the issue, we want to implement refcounting for chan_busy array
      that contains the active dma transfers. Increasing the autosuspend delay
      won't help as that the delay could be potentially seconds, and it's best
      to let the USB subsystem to deal with the timeouts on errors.
      
      The earlier attempt for runtime PM was buggy as the pm_runtime_get/put()
      calls could get unpaired easily as they did not follow the state of
      the chan_busy array as described in commit 098de42a ("dmaengine:
      cppi41: Fix unpaired pm runtime when only a USB hub is connected".
      
      Let's fix the issue by adding pm_runtime_get() to where a new transfer
      is added to the chan_busy array, and calls to pm_runtime_put() where
      chan_busy array entry is cleared. This prevents any autosuspend timeouts
      from happening while dma transfers are active.
      
      Fixes: 098de42a ("dmaengine: cppi41: Fix unpaired pm runtime when
      only a USB hub is connected")
      Fixes: fdea2d09 ("dmaengine: cppi41: Add basic PM runtime support")
      Cc: Andy Shevchenko <andy.shevchenko@gmail.com>
      Cc: Bin Liu <b-liu@ti.com>
      Cc: Grygorii Strashko <grygorii.strashko@ti.com>
      Cc: Kevin Hilman <khilman@baylibre.com>
      Cc: Patrick Titiano <ptitiano@baylibre.com>
      Cc: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      Tested-by: default avatarBin Liu <b-liu@ti.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2c2e7fe7