1. 14 Jun, 2017 40 commits
    • Eric Anholt's avatar
      drm/msm: Expose our reservation object when exporting a dmabuf. · a5ab52b3
      Eric Anholt authored
      commit 43523eba upstream.
      
      Without this, polling on the dma-buf (and presumably other devices
      synchronizing against our rendering) would return immediately, even
      while the BO was busy.
      Signed-off-by: default avatarEric Anholt <eric@anholt.net>
      Reviewed-by: default avatarDaniel Vetter <daniel.vetter@ffwll.ch>
      Cc: Rob Clark <robdclark@gmail.com>
      Cc: linux-arm-msm@vger.kernel.org
      Cc: freedreno@lists.freedesktop.org
      Reviewed-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a5ab52b3
    • Nicholas Bellinger's avatar
      target: Re-add check to reject control WRITEs with overflow data · 0354d1d6
      Nicholas Bellinger authored
      commit 4ff83daa upstream.
      
      During v4.3 when the overflow/underflow check was relaxed by
      commit c72c5250:
      
        commit c72c5250
        Author: Roland Dreier <roland@purestorage.com>
        Date:   Wed Jul 22 15:08:18 2015 -0700
      
             target: allow underflow/overflow for PR OUT etc. commands
      
      to allow underflow/overflow for Windows compliance + FCP, a
      consequence was to allow control CDBs to process overflow
      data for iscsi-target with immediate data as well.
      
      As per Roland's original change, continue to allow underflow
      cases for control CDBs to make Windows compliance + FCP happy,
      but until overflow for control CDBs is supported tree-wide,
      explicitly reject all control WRITEs with overflow following
      pre v4.3.y logic.
      Reported-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Cc: Roland Dreier <roland@purestorage.com>
      Signed-off-by: default avatarNicholas Bellinger <nab@linux-iscsi.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0354d1d6
    • David Arcari's avatar
      cpufreq: cpufreq_register_driver() should return -ENODEV if init fails · 0eedb783
      David Arcari authored
      commit 6c770036 upstream.
      
      For a driver that does not set the CPUFREQ_STICKY flag, if all of the
      ->init() calls fail, cpufreq_register_driver() should return an error.
      This will prevent the driver from loading.
      
      Fixes: ce1bcfe9 (cpufreq: check cpufreq_policy_list instead of scanning policies for all CPUs)
      Signed-off-by: default avatarDavid Arcari <darcari@redhat.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0eedb783
    • Jason A. Donenfeld's avatar
      random: invalidate batched entropy after crng init · 86f95e53
      Jason A. Donenfeld authored
      commit b169c13d upstream.
      
      It's possible that get_random_{u32,u64} is used before the crng has
      initialized, in which case, its output might not be cryptographically
      secure. For this problem, directly, this patch set is introducing the
      *_wait variety of functions, but even with that, there's a subtle issue:
      what happens to our batched entropy that was generated before
      initialization. Prior to this commit, it'd stick around, supplying bad
      numbers. After this commit, we force the entropy to be re-extracted
      after each phase of the crng has initialized.
      
      In order to avoid a race condition with the position counter, we
      introduce a simple rwlock for this invalidation. Since it's only during
      this awkward transition period, after things are all set up, we stop
      using it, so that it doesn't have an impact on performance.
      Signed-off-by: default avatarJason A. Donenfeld <Jason@zx2c4.com>
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      86f95e53
    • Pratyush Anand's avatar
      mei: make sysfs modalias format similar as uevent modalias · 0524867e
      Pratyush Anand authored
      commit 6f9193ec upstream.
      
      modprobe is not able to resolve sysfs modalias for mei devices.
      
       # cat
      /sys/class/watchdog/watchdog0/device/watchdog/watchdog0/device/modalias
      mei::05b79a6f-4628-4d7f-899d-a91514cb32ab:
       # modprobe --set-version 4.9.6-200.fc25.x86_64 -R
      mei::05b79a6f-4628-4d7f-899d-a91514cb32ab:
      modprobe: FATAL: Module mei::05b79a6f-4628-4d7f-899d-a91514cb32ab: not
      found in directory /lib/modules/4.9.6-200.fc25.x86_64
       # cat /lib/modules/4.9.6-200.fc25.x86_64/modules.alias | grep
      05b79a6f-4628-4d7f-899d-a91514cb32ab
      alias mei:*:05b79a6f-4628-4d7f-899d-a91514cb32ab:*:* mei_wdt
      
      commit b26864ca ("mei: bus: add client protocol
      version to the device alias"), however sysfs modalias
      is still in formmat mei:S:uuid:*.
      
      This patch equates format of uevent and sysfs modalias so that modprobe
      is able to resolve the aliases.
      
      Fixes: commit b26864ca ("mei: bus: add client protocol version to the device alias")
      Signed-off-by: default avatarPratyush Anand <panand@redhat.com>
      Signed-off-by: default avatarTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      0524867e
    • Bart Van Assche's avatar
      block: Avoid that blk_exit_rl() triggers a use-after-free · 67125548
      Bart Van Assche authored
      commit b425e504 upstream.
      
      Since the introduction of .init_rq_fn() and .exit_rq_fn() it is
      essential that the memory allocated for struct request_queue
      stays around until all blk_exit_rl() calls have finished. Hence
      make blk_init_rl() take a reference on struct request_queue.
      
      This patch fixes the following crash:
      
      general protection fault: 0000 [#2] SMP
      CPU: 3 PID: 28 Comm: ksoftirqd/3 Tainted: G      D         4.12.0-rc2-dbg+ #2
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.0.0-prebuilt.qemu-project.org 04/01/2014
      task: ffff88013a108040 task.stack: ffffc9000071c000
      RIP: 0010:free_request_size+0x1a/0x30
      RSP: 0018:ffffc9000071fd38 EFLAGS: 00010202
      RAX: 6b6b6b6b6b6b6b6b RBX: ffff880067362a88 RCX: 0000000000000003
      RDX: ffff880067464178 RSI: ffff880067362a88 RDI: ffff880135ea4418
      RBP: ffffc9000071fd40 R08: 0000000000000000 R09: 0000000100180009
      R10: ffffc9000071fd38 R11: ffffffff81110800 R12: ffff88006752d3d8
      R13: ffff88006752d3d8 R14: ffff88013a108040 R15: 000000000000000a
      FS:  0000000000000000(0000) GS:ffff88013fd80000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: 00007fa8ec1edb00 CR3: 0000000138ee8000 CR4: 00000000001406e0
      Call Trace:
       mempool_destroy.part.10+0x21/0x40
       mempool_destroy+0xe/0x10
       blk_exit_rl+0x12/0x20
       blkg_free+0x4d/0xa0
       __blkg_release_rcu+0x59/0x170
       rcu_process_callbacks+0x260/0x4e0
       __do_softirq+0x116/0x250
       smpboot_thread_fn+0x123/0x1e0
       kthread+0x109/0x140
       ret_from_fork+0x31/0x40
      
      Fixes: commit e9c787e6 ("scsi: allocate scsi_cmnd structures as part of struct request")
      Signed-off-by: default avatarBart Van Assche <bart.vanassche@sandisk.com>
      Acked-by: default avatarTejun Heo <tj@kernel.org>
      Reviewed-by: default avatarHannes Reinecke <hare@suse.com>
      Reviewed-by: default avatarChristoph Hellwig <hch@lst.de>
      Cc: Jan Kara <jack@suse.cz>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      67125548
    • Matt Ranostay's avatar
      iio: proximity: as3935: fix iio_trigger_poll issue · 698aa720
      Matt Ranostay authored
      commit 9122b54f upstream.
      
      Using iio_trigger_poll() can oops when multiple interrupts
      happen before the first is handled.
      
      Use iio_trigger_poll_chained() instead and use the timestamp
      when processed, since it will be in theory be 2 ms max latency.
      
      Fixes: 24ddb0e4 ("iio: Add AS3935 lightning sensor support")
      Signed-off-by: default avatarMatt Ranostay <matt.ranostay@konsulko.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      698aa720
    • Matt Ranostay's avatar
      iio: proximity: as3935: fix AS3935_INT mask · 71c0950c
      Matt Ranostay authored
      commit 275292d3 upstream.
      
      AS3935 interrupt mask has been incorrect so valid lightning events
      would never trigger an buffer event. Also noise interrupt should be
      BIT(0).
      
      Fixes: 24ddb0e4 ("iio: Add AS3935 lightning sensor support")
      Signed-off-by: default avatarMatt Ranostay <matt.ranostay@konsulko.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      71c0950c
    • Marcin Niestroj's avatar
      iio: trigger: fix NULL pointer dereference in iio_trigger_write_current() · 7b5d3c1a
      Marcin Niestroj authored
      commit 4eecbe81 upstream.
      
      In case oldtrig == trig == NULL (which happens when we set none
      trigger, when there is already none set) there is a NULL pointer
      dereference during iio_trigger_put(trig). Below is kernel output when
      this occurs:
      
      [   26.741790] Unable to handle kernel NULL pointer dereference at virtual address 00000000
      [   26.750179] pgd = cacc0000
      [   26.752936] [00000000] *pgd=8adc6835, *pte=00000000, *ppte=00000000
      [   26.759531] Internal error: Oops: 17 [#1] SMP ARM
      [   26.764261] Modules linked in: usb_f_ncm u_ether usb_f_acm u_serial usb_f_fs libcomposite configfs evbug
      [   26.773844] CPU: 0 PID: 152 Comm: synchro Not tainted 4.12.0-rc1 #2
      [   26.780128] Hardware name: Freescale i.MX6 Ultralite (Device Tree)
      [   26.786329] task: cb1de200 task.stack: cac92000
      [   26.790892] PC is at iio_trigger_write_current+0x188/0x1f4
      [   26.796403] LR is at lock_release+0xf8/0x20c
      [   26.800696] pc : [<c0736f34>]    lr : [<c016efb0>]    psr: 600d0013
      [   26.800696] sp : cac93e30  ip : cac93db0  fp : cac93e5c
      [   26.812193] r10: c0e64fe8  r9 : 00000000  r8 : 00000001
      [   26.817436] r7 : cb190810  r6 : 00000010  r5 : 00000001  r4 : 00000000
      [   26.823982] r3 : 00000000  r2 : 00000000  r1 : cb1de200  r0 : 00000000
      [   26.830528] Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
      [   26.837683] Control: 10c5387d  Table: 8acc006a  DAC: 00000051
      [   26.843448] Process synchro (pid: 152, stack limit = 0xcac92210)
      [   26.849475] Stack: (0xcac93e30 to 0xcac94000)
      [   26.853857] 3e20:                                     00000001 c0736dac c054033c cae6b680
      [   26.862060] 3e40: cae6b680 00000000 00000001 cb3f8610 cac93e74 cac93e60 c054035c c0736db8
      [   26.870264] 3e60: 00000001 c054033c cac93e94 cac93e78 c029bf34 c0540348 00000000 00000000
      [   26.878469] 3e80: cb3f8600 cae6b680 cac93ed4 cac93e98 c029b320 c029bef0 00000000 00000000
      [   26.886672] 3ea0: 00000000 cac93f78 cb2d41fc caed3280 c029b214 cac93f78 00000001 000e20f8
      [   26.894874] 3ec0: 00000001 00000000 cac93f44 cac93ed8 c0221dcc c029b220 c0e1ca39 cb2d41fc
      [   26.903079] 3ee0: cac93f04 cac93ef0 c0183ef0 c0183ab0 cb2d41fc 00000000 cac93f44 cac93f08
      [   26.911282] 3f00: c0225eec c0183ebc 00000001 00000000 c0223728 00000000 c0245454 00000001
      [   26.919485] 3f20: 00000001 caed3280 000e20f8 cac93f78 000e20f8 00000001 cac93f74 cac93f48
      [   26.927690] 3f40: c0223680 c0221da4 c0246520 c0245460 caed3283 caed3280 00000000 00000000
      [   26.935893] 3f60: 000e20f8 00000001 cac93fa4 cac93f78 c0224520 c02235e4 00000000 00000000
      [   26.944096] 3f80: 00000001 000e20f8 00000001 00000004 c0107f84 cac92000 00000000 cac93fa8
      [   26.952299] 3fa0: c0107de0 c02244e8 00000001 000e20f8 0000000e 000e20f8 00000001 fbad2484
      [   26.960502] 3fc0: 00000001 000e20f8 00000001 00000004 beb6b698 00064260 0006421c beb6b4b4
      [   26.968705] 3fe0: 00000000 beb6b450 b6f219a0 b6e2f268 800d0010 0000000e cac93ff4 cac93ffc
      [   26.976896] Backtrace:
      [   26.979388] [<c0736dac>] (iio_trigger_write_current) from [<c054035c>] (dev_attr_store+0x20/0x2c)
      [   26.988289]  r10:cb3f8610 r9:00000001 r8:00000000 r7:cae6b680 r6:cae6b680 r5:c054033c
      [   26.996138]  r4:c0736dac r3:00000001
      [   26.999747] [<c054033c>] (dev_attr_store) from [<c029bf34>] (sysfs_kf_write+0x50/0x54)
      [   27.007686]  r5:c054033c r4:00000001
      [   27.011290] [<c029bee4>] (sysfs_kf_write) from [<c029b320>] (kernfs_fop_write+0x10c/0x224)
      [   27.019579]  r7:cae6b680 r6:cb3f8600 r5:00000000 r4:00000000
      [   27.025271] [<c029b214>] (kernfs_fop_write) from [<c0221dcc>] (__vfs_write+0x34/0x120)
      [   27.033214]  r10:00000000 r9:00000001 r8:000e20f8 r7:00000001 r6:cac93f78 r5:c029b214
      [   27.041059]  r4:caed3280
      [   27.043622] [<c0221d98>] (__vfs_write) from [<c0223680>] (vfs_write+0xa8/0x170)
      [   27.050959]  r9:00000001 r8:000e20f8 r7:cac93f78 r6:000e20f8 r5:caed3280 r4:00000001
      [   27.058731] [<c02235d8>] (vfs_write) from [<c0224520>] (SyS_write+0x44/0x98)
      [   27.065806]  r9:00000001 r8:000e20f8 r7:00000000 r6:00000000 r5:caed3280 r4:caed3283
      [   27.073582] [<c02244dc>] (SyS_write) from [<c0107de0>] (ret_fast_syscall+0x0/0x1c)
      [   27.081179]  r9:cac92000 r8:c0107f84 r7:00000004 r6:00000001 r5:000e20f8 r4:00000001
      [   27.088947] Code: 1a000009 e1a04009 e3a06010 e1a05008 (e5943000)
      [   27.095244] ---[ end trace 06d1dab86d6e6bab ]---
      
      To fix that problem call iio_trigger_put(trig) only when trig is not
      NULL.
      
      Fixes: d5d24bcc ("iio: trigger: close race condition in acquiring trigger reference")
      Signed-off-by: default avatarMarcin Niestroj <m.niestroj@grinn-global.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7b5d3c1a
    • Franziska Naepelt's avatar
      iio: light: ltr501 Fix interchanged als/ps register field · 80c8ac6b
      Franziska Naepelt authored
      commit 7cc3bff4 upstream.
      
      The register mapping for the IIO driver for the Liteon Light and Proximity
      sensor LTR501 interrupt mode is interchanged (ALS/PS).
      There is a register called INTERRUPT register (address 0x8F)
      Bit 0 represents PS measurement trigger.
      Bit 1 represents ALS measurement trigger.
      This two bit fields are interchanged within the driver.
      see datasheet page 24:
      http://optoelectronics.liteon.com/upload/download/DS86-2012-0006/S_110_LTR-501ALS-01_PrelimDS_ver1%5B1%5D.pdfSigned-off-by: default avatarFranziska Naepelt <franziska.naepelt@idt.com>
      Fixes: 7ac702b3 ("iio: ltr501: Add interrupt support")
      Acked-by: default avatarPeter Meerwald-Stadler <pmeerw@pmeerw.net>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      80c8ac6b
    • Raveendra Padasalagi's avatar
      iio: adc: bcm_iproc_adc: swap primary and secondary isr handler's · 1cb7bbe7
      Raveendra Padasalagi authored
      commit f7d86ecf upstream.
      
      The third argument of devm_request_threaded_irq() is the primary
      handler. It is called in hardirq context and checks whether the
      interrupt is relevant to the device. If the primary handler returns
      IRQ_WAKE_THREAD, the secondary handler (a.k.a. handler thread) is
      scheduled to run in process context.
      
      bcm_iproc_adc.c uses the secondary handler as the primary one
      and the other way around. So this patch fixes the same, along with
      re-naming the secondary handler and primary handler names properly.
      
      Tested on the BCM9583XX iProc SoC based boards.
      
      Fixes: 4324c97e ("iio: Add driver for Broadcom iproc-static-adc")
      Reported-by: default avatarPavel Roskin <plroskin@gmail.com>
      Signed-off-by: default avatarRaveendra Padasalagi <raveendra.padasalagi@broadcom.com>
      Signed-off-by: default avatarJonathan Cameron <jic23@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1cb7bbe7
    • Oleg Drokin's avatar
      staging/lustre/lov: remove set_fs() call from lov_getstripe() · d9b0c955
      Oleg Drokin authored
      commit 0a33252e upstream.
      
      lov_getstripe() calls set_fs(KERNEL_DS) so that it can handle a struct
      lov_user_md pointer from user- or kernel-space.  This changes the
      behavior of copy_from_user() on SPARC and may result in a misaligned
      access exception which in turn oopses the kernel.  In fact the
      relevant argument to lov_getstripe() is never called with a
      kernel-space pointer and so changing the address limits is unnecessary
      and so we remove the calls to save, set, and restore the address
      limits.
      Signed-off-by: default avatarJohn L. Hammond <john.hammond@intel.com>
      Reviewed-on: http://review.whamcloud.com/6150
      Intel-bug-id: https://jira.hpdd.intel.com/browse/LU-3221Reviewed-by: default avatarAndreas Dilger <andreas.dilger@intel.com>
      Reviewed-by: default avatarLi Wei <wei.g.li@intel.com>
      Signed-off-by: default avatarOleg Drokin <green@linuxhacker.ru>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d9b0c955
    • Michael Thalmeier's avatar
      usb: chipidea: debug: check before accessing ci_role · dd8980bb
      Michael Thalmeier authored
      commit 0340ff83 upstream.
      
      ci_role BUGs when the role is >= CI_ROLE_END.
      Signed-off-by: default avatarMichael Thalmeier <michael.thalmeier@hale.at>
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dd8980bb
    • Jisheng Zhang's avatar
      usb: chipidea: udc: fix NULL pointer dereference if udc_start failed · f2967b72
      Jisheng Zhang authored
      commit aa1f058d upstream.
      
      Fix below NULL pointer dereference. we set ci->roles[CI_ROLE_GADGET]
      too early in ci_hdrc_gadget_init(), if udc_start() fails due to some
      reason, the ci->roles[CI_ROLE_GADGET] check in  ci_hdrc_gadget_destroy
      can't protect us.
      
      We fix this issue by only setting ci->roles[CI_ROLE_GADGET] if
      udc_start() succeed.
      
      [    1.398550] Unable to handle kernel NULL pointer dereference at
      virtual address 00000000
      ...
      [    1.448600] PC is at dma_pool_free+0xb8/0xf0
      [    1.453012] LR is at dma_pool_free+0x28/0xf0
      [    2.113369] [<ffffff80081817d8>] dma_pool_free+0xb8/0xf0
      [    2.118857] [<ffffff800841209c>] destroy_eps+0x4c/0x68
      [    2.124165] [<ffffff8008413770>] ci_hdrc_gadget_destroy+0x28/0x50
      [    2.130461] [<ffffff800840fa30>] ci_hdrc_probe+0x588/0x7e8
      [    2.136129] [<ffffff8008380fb8>] platform_drv_probe+0x50/0xb8
      [    2.142066] [<ffffff800837f494>] driver_probe_device+0x1fc/0x2a8
      [    2.148270] [<ffffff800837f68c>] __device_attach_driver+0x9c/0xf8
      [    2.154563] [<ffffff800837d570>] bus_for_each_drv+0x58/0x98
      [    2.160317] [<ffffff800837f174>] __device_attach+0xc4/0x138
      [    2.166072] [<ffffff800837f738>] device_initial_probe+0x10/0x18
      [    2.172185] [<ffffff800837e58c>] bus_probe_device+0x94/0xa0
      [    2.177940] [<ffffff800837c560>] device_add+0x3f0/0x560
      [    2.183337] [<ffffff8008380d20>] platform_device_add+0x180/0x240
      [    2.189541] [<ffffff800840f0e8>] ci_hdrc_add_device+0x440/0x4f8
      [    2.195654] [<ffffff8008414194>] ci_hdrc_usb2_probe+0x13c/0x2d8
      [    2.201769] [<ffffff8008380fb8>] platform_drv_probe+0x50/0xb8
      [    2.207705] [<ffffff800837f494>] driver_probe_device+0x1fc/0x2a8
      [    2.213910] [<ffffff800837f5ec>] __driver_attach+0xac/0xb0
      [    2.219575] [<ffffff800837d4b0>] bus_for_each_dev+0x60/0xa0
      [    2.225329] [<ffffff800837ec80>] driver_attach+0x20/0x28
      [    2.230816] [<ffffff800837e880>] bus_add_driver+0x1d0/0x238
      [    2.236571] [<ffffff800837fdb0>] driver_register+0x60/0xf8
      [    2.242237] [<ffffff8008380ef4>] __platform_driver_register+0x44/0x50
      [    2.248891] [<ffffff80086fd440>] ci_hdrc_usb2_driver_init+0x18/0x20
      [    2.255365] [<ffffff8008082950>] do_one_initcall+0x38/0x128
      [    2.261121] [<ffffff80086e0d00>] kernel_init_freeable+0x1ac/0x250
      [    2.267414] [<ffffff800852f0b8>] kernel_init+0x10/0x100
      [    2.272810] [<ffffff8008082680>] ret_from_fork+0x10/0x50
      
      Fixes: 3f124d23 ("usb: chipidea: add role init and destroy APIs")
      Signed-off-by: default avatarJisheng Zhang <jszhang@marvell.com>
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f2967b72
    • Andrey Smirnov's avatar
      usb: chipidea: imx: Do not access CLKONOFF on i.MX51 · f26ac1fc
      Andrey Smirnov authored
      commit 62b97d50 upstream.
      
      Unlike i.MX53, i.MX51's USBOH3 register file does not implemenent
      registers past offset 0x018, which includes
      MX53_USB_CLKONOFF_CTRL_OFFSET and trying to access that register on
      said platform results in external abort.
      
      Fix it by enabling CLKONOFF accessing codepath only for i.MX53.
      
      Fixes 3be3251d ("usb: chipidea: imx: Disable internal 60Mhz clock with ULPI PHY")
      Cc: cphealy@gmail.com
      Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
      Cc: linux-usb@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: default avatarAndrey Smirnov <andrew.smirnov@gmail.com>
      Signed-off-by: default avatarPeter Chen <peter.chen@nxp.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f26ac1fc
    • Bin Liu's avatar
      usb: musb: dsps: keep VBUS on for host-only mode · b89de040
      Bin Liu authored
      commit b3addcf0 upstream.
      
      Currently VBUS is turned off while a usb device is detached, and turned
      on again by the polling routine. This short period VBUS loss prevents
      usb modem to switch mode.
      
      VBUS should be constantly on for host-only mode, so this changes the
      driver to not turn off VBUS for host-only mode.
      
      Fixes: 2f3fd2c5 ("usb: musb: Prepare dsps glue layer for PM runtime support")
      Reported-by: default avatarMoreno Bartalucci <moreno.bartalucci@tecnorama.it>
      Acked-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>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b89de040
    • Thinh Nguyen's avatar
      usb: gadget: f_mass_storage: Serialize wake and sleep execution · c33b087c
      Thinh Nguyen authored
      commit dc9217b6 upstream.
      
      f_mass_storage has a memorry barrier issue with the sleep and wake
      functions that can cause a deadlock. This results in intermittent hangs
      during MSC file transfer. The host will reset the device after receiving
      no response to resume the transfer. This issue is seen when dwc3 is
      processing 2 transfer-in-progress events at the same time, invoking
      completion handlers for CSW and CBW. Also this issue occurs depending on
      the system timing and latency.
      
      To increase the chance to hit this issue, you can force dwc3 driver to
      wait and process those 2 events at once by adding a small delay (~100us)
      in dwc3_check_event_buf() whenever the request is for CSW and read the
      event count again. Avoid debugging with printk and ftrace as extra
      delays and memory barrier will mask this issue.
      
      Scenario which can lead to failure:
      -----------------------------------
      1) The main thread sleeps and waits for the next command in
         get_next_command().
      2) bulk_in_complete() wakes up main thread for CSW.
      3) bulk_out_complete() tries to wake up the running main thread for CBW.
      4) thread_wakeup_needed is not loaded with correct value in
         sleep_thread().
      5) Main thread goes to sleep again.
      
      The pattern is shown below. Note the 2 critical variables.
       * common->thread_wakeup_needed
       * bh->state
      
      	CPU 0 (sleep_thread)		CPU 1 (wakeup_thread)
      	==============================  ===============================
      
      					bh->state = BH_STATE_FULL;
      					smp_wmb();
      	thread_wakeup_needed = 0;	thread_wakeup_needed = 1;
      	smp_rmb();
      	if (bh->state != BH_STATE_FULL)
      		sleep again ...
      
      As pointed out by Alan Stern, this is an R-pattern issue. The issue can
      be seen when there are two wakeups in quick succession. The
      thread_wakeup_needed can be overwritten in sleep_thread, and the read of
      the bh->state maybe reordered before the write to thread_wakeup_needed.
      
      This patch applies full memory barrier smp_mb() in both sleep_thread()
      and wakeup_thread() to ensure the order which the thread_wakeup_needed
      and bh->state are written and loaded.
      
      However, a better solution in the future would be to use wait_queue
      method that takes care of managing memory barrier between waker and
      waiter.
      Acked-by: default avatarAlan Stern <stern@rowland.harvard.edu>
      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>
      c33b087c
    • Hans de Goede's avatar
      drm: Fix oops + Xserver hang when unplugging USB drm devices · 3d7ba52b
      Hans de Goede authored
      commit 75fb6363 upstream.
      
      commit a39be606 ("drm: Do a full device unregister when unplugging")
      causes backtraces like this one when unplugging an usb drm device while
      it is in use:
      
      usb 2-3: USB disconnect, device number 25
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 242 at drivers/gpu/drm/drm_mode_config.c:424
         drm_mode_config_cleanup+0x220/0x280 [drm]
      ...
      RIP: 0010:drm_mode_config_cleanup+0x220/0x280 [drm]
      ...
      Call Trace:
       gm12u320_modeset_cleanup+0xe/0x10 [gm12u320]
       gm12u320_driver_unload+0x35/0x70 [gm12u320]
       drm_dev_unregister+0x3c/0xe0 [drm]
       drm_unplug_dev+0x12/0x60 [drm]
       gm12u320_usb_disconnect+0x36/0x40 [gm12u320]
       usb_unbind_interface+0x72/0x280
       device_release_driver_internal+0x158/0x210
       device_release_driver+0x12/0x20
       bus_remove_device+0x104/0x180
       device_del+0x1d2/0x350
       usb_disable_device+0x9f/0x270
       usb_disconnect+0xc6/0x260
      ...
      [drm:drm_mode_config_cleanup [drm]] *ERROR* connector Unknown-1 leaked!
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 242 at drivers/gpu/drm/drm_mode_config.c:458
         drm_mode_config_cleanup+0x268/0x280 [drm]
      ...
      <same Call Trace>
      ---[ end trace 80df975dae439ed6 ]---
      general protection fault: 0000 [#1] SMP
      ...
      Call Trace:
       ? __switch_to+0x225/0x450
       drm_mode_rmfb_work_fn+0x55/0x70 [drm]
       process_one_work+0x193/0x3c0
       worker_thread+0x4a/0x3a0
      ...
      RIP: drm_framebuffer_remove+0x62/0x3f0 [drm] RSP: ffffb776c39dfd98
      ---[ end trace 80df975dae439ed7 ]---
      
      After which the system is unusable this is caused by drm_dev_unregister
      getting called immediately on unplug, which calls the drivers unload
      function which calls drm_mode_config_cleanup which removes the framebuffer
      object while userspace is still holding a reference to it.
      
      Reverting commit a39be606 ("drm: Do a full device unregister
      when unplugging") leads to the following oops on unplug instead,
      when userspace closes the last fd referencing the drm_dev:
      
      sysfs group 'power' not found for kobject 'card1-Unknown-1'
      ------------[ cut here ]------------
      WARNING: CPU: 0 PID: 2459 at fs/sysfs/group.c:237
         sysfs_remove_group+0x80/0x90
      ...
      RIP: 0010:sysfs_remove_group+0x80/0x90
      ...
      Call Trace:
       dpm_sysfs_remove+0x57/0x60
       device_del+0xfd/0x350
       device_unregister+0x1a/0x60
       drm_sysfs_connector_remove+0x39/0x50 [drm]
       drm_connector_unregister+0x5a/0x70 [drm]
       drm_connector_unregister_all+0x45/0xa0 [drm]
       drm_modeset_unregister_all+0x12/0x30 [drm]
       drm_dev_unregister+0xca/0xe0 [drm]
       drm_put_dev+0x32/0x60 [drm]
       drm_release+0x2f3/0x380 [drm]
       __fput+0xdf/0x1e0
      ...
      ---[ end trace ecfb91ac85688bbe ]---
      BUG: unable to handle kernel NULL pointer dereference at 00000000000000a8
      IP: down_write+0x1f/0x40
      ...
      Call Trace:
       debugfs_remove_recursive+0x55/0x1b0
       drm_debugfs_connector_remove+0x21/0x40 [drm]
       drm_connector_unregister+0x62/0x70 [drm]
       drm_connector_unregister_all+0x45/0xa0 [drm]
       drm_modeset_unregister_all+0x12/0x30 [drm]
       drm_dev_unregister+0xca/0xe0 [drm]
       drm_put_dev+0x32/0x60 [drm]
       drm_release+0x2f3/0x380 [drm]
       __fput+0xdf/0x1e0
      ...
      ---[ end trace ecfb91ac85688bbf ]---
      
      This is caused by the revert moving back to drm_unplug_dev calling
      drm_minor_unregister which does:
      
              device_del(minor->kdev);
              dev_set_drvdata(minor->kdev, NULL); /* safety belt */
              drm_debugfs_cleanup(minor);
      
      Causing the sysfs entries to already be removed even though we still
      have references to them in e.g. drm_connector.
      
      Note we must call drm_minor_unregister to notify userspace of the unplug
      of the device, so calling drm_dev_unregister is not completely wrong the
      problem is that drm_dev_unregister does too much.
      
      This commit fixes drm_unplug_dev by not only reverting
      commit a39be606 ("drm: Do a full device unregister when unplugging")
      but by also adding a call to drm_modeset_unregister_all before the
      drm_minor_unregister calls to make sure all sysfs entries are removed
      before calling device_del(minor->kdev) thereby also fixing the second
      set of oopses caused by just reverting the commit.
      
      Fixes: a39be606 ("drm: Do a full device unregister when unplugging")
      Cc: Chris Wilson <chris@chris-wilson.co.uk>
      Cc: Jeffy <jeffy.chen@rock-chips.com>
      Cc: Marco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
      Reported-by: default avatarMarco Diego Aurélio Mesquita <marcodiegomesquita@gmail.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Reviewed-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
      Signed-off-by: default avatarSean Paul <seanpaul@chromium.org>
      Link: http://patchwork.freedesktop.org/patch/msgid/20170601115430.4113-1-hdegoede@redhat.comSigned-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3d7ba52b
    • Jan Kara's avatar
      ext4: fix fdatasync(2) after extent manipulation operations · de8f4aea
      Jan Kara authored
      commit 67a7d5f5 upstream.
      
      Currently, extent manipulation operations such as hole punch, range
      zeroing, or extent shifting do not record the fact that file data has
      changed and thus fdatasync(2) has a work to do. As a result if we crash
      e.g. after a punch hole and fdatasync, user can still possibly see the
      punched out data after journal replay. Test generic/392 fails due to
      these problems.
      
      Fix the problem by properly marking that file data has changed in these
      operations.
      
      Fixes: a4bb6b64Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de8f4aea
    • Jan Kara's avatar
      ext4: fix data corruption with EXT4_GET_BLOCKS_ZERO · 875d084e
      Jan Kara authored
      commit 4f8caa60 upstream.
      
      When ext4_map_blocks() is called with EXT4_GET_BLOCKS_ZERO to zero-out
      allocated blocks and these blocks are actually converted from unwritten
      extent the following race can happen:
      
      CPU0					CPU1
      
      page fault				page fault
      ...					...
      ext4_map_blocks()
        ext4_ext_map_blocks()
          ext4_ext_handle_unwritten_extents()
            ext4_ext_convert_to_initialized()
      	- zero out converted extent
      	ext4_zeroout_es()
      	  - inserts extent as initialized in status tree
      
      					ext4_map_blocks()
      					  ext4_es_lookup_extent()
      					    - finds initialized extent
      					write data
        ext4_issue_zeroout()
          - zeroes out new extent overwriting data
      
      This problem can be reproduced by generic/340 for the fallocated case
      for the last block in the file.
      
      Fix the problem by avoiding zeroing out the area we are mapping with
      ext4_map_blocks() in ext4_ext_convert_to_initialized(). It is pointless
      to zero out this area in the first place as the caller asked us to
      convert the area to initialized because he is just going to write data
      there before the transaction finishes. To achieve this we delete the
      special case of zeroing out full extent as that will be handled by the
      cases below zeroing only the part of the extent that needs it. We also
      instruct ext4_split_extent() that the middle of extent being split
      contains data so that ext4_split_extent_at() cannot zero out full extent
      in case of ENOSPC.
      
      Fixes: 12735f88Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      875d084e
    • Konstantin Khlebnikov's avatar
      ext4: keep existing extra fields when inode expands · 22fb074c
      Konstantin Khlebnikov authored
      commit 887a9730 upstream.
      
      ext4_expand_extra_isize() should clear only space between old and new
      size.
      
      Fixes: 6dd4ee7c # v2.6.23
      Signed-off-by: default avatarKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      22fb074c
    • Jan Kara's avatar
      ext4: fix SEEK_HOLE · 699dc108
      Jan Kara authored
      commit 7d95eddf upstream.
      
      Currently, SEEK_HOLE implementation in ext4 may both return that there's
      a hole at some offset although that offset already has data and skip
      some holes during a search for the next hole. The first problem is
      demostrated by:
      
      xfs_io -c "falloc 0 256k" -c "pwrite 0 56k" -c "seek -h 0" file
      wrote 57344/57344 bytes at offset 0
      56 KiB, 14 ops; 0.0000 sec (2.054 GiB/sec and 538461.5385 ops/sec)
      Whence	Result
      HOLE	0
      
      Where we can see that SEEK_HOLE wrongly returned offset 0 as containing
      a hole although we have written data there. The second problem can be
      demonstrated by:
      
      xfs_io -c "falloc 0 256k" -c "pwrite 0 56k" -c "pwrite 128k 8k"
             -c "seek -h 0" file
      
      wrote 57344/57344 bytes at offset 0
      56 KiB, 14 ops; 0.0000 sec (1.978 GiB/sec and 518518.5185 ops/sec)
      wrote 8192/8192 bytes at offset 131072
      8 KiB, 2 ops; 0.0000 sec (2 GiB/sec and 500000.0000 ops/sec)
      Whence	Result
      HOLE	139264
      
      Where we can see that hole at offsets 56k..128k has been ignored by the
      SEEK_HOLE call.
      
      The underlying problem is in the ext4_find_unwritten_pgoff() which is
      just buggy. In some cases it fails to update returned offset when it
      finds a hole (when no pages are found or when the first found page has
      higher index than expected), in some cases conditions for detecting hole
      are just missing (we fail to detect a situation where indices of
      returned pages are not contiguous).
      
      Fix ext4_find_unwritten_pgoff() to properly detect non-contiguous page
      indices and also handle all cases where we got less pages then expected
      in one place and handle it properly there.
      
      Fixes: c8c0df24
      CC: Zheng Liu <wenqing.lz@taobao.com>
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarTheodore Ts'o <tytso@mit.edu>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      699dc108
    • Julien Grall's avatar
      xen/privcmd: Support correctly 64KB page granularity when mapping memory · 628ee504
      Julien Grall authored
      commit 753c09b5 upstream.
      
      Commit 5995a68a "xen/privcmd: Add support for Linux 64KB page granularity" did
      not go far enough to support 64KB in mmap_batch_fn.
      
      The variable 'nr' is the number of 4KB chunk to map. However, when Linux
      is using 64KB page granularity the array of pages (vma->vm_private_data)
      contain one page per 64KB. Fix it by incrementing st->index correctly.
      
      Furthermore, st->va is not correctly incremented as PAGE_SIZE !=
      XEN_PAGE_SIZE.
      
      Fixes: 5995a68a ("xen/privcmd: Add support for Linux 64KB page granularity")
      Reported-by: default avatarFeng Kan <fkan@apm.com>
      Signed-off-by: default avatarJulien Grall <julien.grall@arm.com>
      Reviewed-by: default avatarBoris Ostrovsky <boris.ostrovsky@oracle.com>
      Signed-off-by: default avatarJuergen Gross <jgross@suse.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      628ee504
    • Marc Gonzalez's avatar
      mtd: nand: tango: Update ecc_stats.corrected · b9d013c0
      Marc Gonzalez authored
      commit 60cf0ce1 upstream.
      
      According to Boris, some user-space tools expect MTD drivers to
      update ecc_stats.corrected, and it's better to provide a lower
      bound than to provide no information at all.
      
      Fixes: 6956e238 ("mtd: nand: add tango NAND flash controller support")
      Reported-by: default avatarPavel Machek <pavel@ucw.cz>
      Signed-off-by: default avatarMarc Gonzalez <marc_gonzalez@sigmadesigns.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b9d013c0
    • Andres Galacho's avatar
      mtd: nand: tango: Export OF device ID table as module aliases · 6d916021
      Andres Galacho authored
      commit 2761b4f1 upstream.
      
      The device table is required to load modules based on
      modaliases. After adding MODULE_DEVICE_TABLE, below entries
      for example will be added to module.alias:
      alias:          of:N*T*Csigma,smp8758-nandC*
      alias:          of:N*T*Csigma,smp8758-nand
      
      Fixes: 6956e238 ("mtd: nand: add tango NAND flash controller support")
      Signed-off-by: default avatarAndres Galacho <andresgalacho@gmail.com>
      Acked-by: default avatarBrian Norris <computersforpeace@gmail.com>
      Signed-off-by: default avatarBoris Brezillon <boris.brezillon@free-electrons.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d916021
    • Jan Kara's avatar
      reiserfs: Make flush bios explicitely sync · f0aa7a04
      Jan Kara authored
      commit d8747d64 upstream.
      
      Commit b685d3d6 "block: treat REQ_FUA and REQ_PREFLUSH as
      synchronous" removed REQ_SYNC flag from WRITE_{FUA|PREFLUSH|...}
      definitions.  generic_make_request_checks() however strips REQ_FUA and
      REQ_PREFLUSH flags from a bio when the storage doesn't report volatile
      write cache and thus write effectively becomes asynchronous which can
      lead to performance regressions
      
      Fix the problem by making sure all bios which are synchronous are
      properly marked with REQ_SYNC.
      
      Fixes: b685d3d6
      CC: reiserfs-devel@vger.kernel.org
      Signed-off-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f0aa7a04
    • Hou Tao's avatar
      cfq-iosched: fix the delay of cfq_group's vdisktime under iops mode · f2fee0c4
      Hou Tao authored
      commit 5be6b756 upstream.
      
      When adding a cfq_group into the cfq service tree, we use CFQ_IDLE_DELAY
      as the delay of cfq_group's vdisktime if there have been other cfq_groups
      already.
      
      When cfq is under iops mode, commit 9a7f38c4 ("cfq-iosched: Convert
      from jiffies to nanoseconds") could result in a large iops delay and
      lead to an abnormal io schedule delay for the added cfq_group. To fix
      it, we just need to revert to the old CFQ_IDLE_DELAY value: HZ / 5
      when iops mode is enabled.
      
      Despite having the same value, the delay of a cfq_queue in idle class
      and the delay of cfq_group are different things, so I define two new
      macros for the delay of a cfq_group under time-slice mode and iops mode.
      
      Fixes: 9a7f38c4 ("cfq-iosched: Convert from jiffies to nanoseconds")
      Signed-off-by: default avatarHou Tao <houtao1@huawei.com>
      Acked-by: default avatarJan Kara <jack@suse.cz>
      Signed-off-by: default avatarJens Axboe <axboe@fb.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      f2fee0c4
    • Thomas Petazzoni's avatar
      dmaengine: mv_xor_v2: set DMA mask to 40 bits · 067b131e
      Thomas Petazzoni authored
      commit b2d3c270 upstream.
      
      The XORv2 engine on Armada 7K/8K can only access the first 40 bits of
      the physical address space, so the DMA mask must be set accordingly.
      
      Fixes: 19a340b1 ("dmaengine: mv_xor_v2: new driver")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      067b131e
    • Thomas Petazzoni's avatar
      dmaengine: mv_xor_v2: remove interrupt coalescing · 6d41a85b
      Thomas Petazzoni authored
      commit 9dd4f319 upstream.
      
      The current implementation of interrupt coalescing doesn't work, because
      it doesn't configure the coalescing timer, which is needed to make sure
      we get an interrupt at some point.
      
      As a fix for stable, we simply remove the interrupt coalescing
      functionality. It will be re-introduced properly in a future commit.
      
      Fixes: 19a340b1 ("dmaengine: mv_xor_v2: new driver")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6d41a85b
    • Thomas Petazzoni's avatar
      dmaengine: mv_xor_v2: fix tx_submit() implementation · 6f4c739d
      Thomas Petazzoni authored
      commit 44d5887a upstream.
      
      The mv_xor_v2_tx_submit() gets the next available HW descriptor by
      calling mv_xor_v2_get_desq_write_ptr(), which reads a HW register
      telling the next available HW descriptor. This was working fine when HW
      descriptors were issued for processing directly in tx_submit().
      
      However, as part of the review process of the driver, a change was
      requested to move the actual kick-off of HW descriptors processing to
      ->issue_pending(). Due to this, reading the HW register to know the next
      available HW descriptor no longer works.
      
      So instead of using this HW register, we implemented a software index
      pointing to the next available HW descriptor.
      
      Fixes: 19a340b1 ("dmaengine: mv_xor_v2: new driver")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6f4c739d
    • Hanna Hawa's avatar
      dmaengine: mv_xor_v2: enable XOR engine after its configuration · a4634dfb
      Hanna Hawa authored
      commit ab2c5f0a upstream.
      
      The engine was enabled prior to its configuration, which isn't
      correct. This patch relocates the activation of the XOR engine, to be
      after the configuration of the XOR engine.
      
      Fixes: 19a340b1 ("dmaengine: mv_xor_v2: new driver")
      Signed-off-by: default avatarHanna Hawa <hannah@marvell.com>
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a4634dfb
    • Thomas Petazzoni's avatar
      dmaengine: mv_xor_v2: do not use descriptors not acked by async_tx · cba2cd6d
      Thomas Petazzoni authored
      commit bc473da1 upstream.
      
      Descriptors that have not been acknowledged by the async_tx layer
      should not be re-used, so this commit adjusts the implementation of
      mv_xor_v2_prep_sw_desc() to skip descriptors for which
      async_tx_test_ack() is false.
      
      Fixes: 19a340b1 ("dmaengine: mv_xor_v2: new driver")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cba2cd6d
    • Thomas Petazzoni's avatar
      dmaengine: mv_xor_v2: properly handle wrapping in the array of HW descriptors · 2384df2b
      Thomas Petazzoni authored
      commit 2aab4e18 upstream.
      
      mv_xor_v2_tasklet() is looping over completed HW descriptors. Before the
      loop, it initializes 'next_pending_hw_desc' to the first HW descriptor
      to handle, and then the loop simply increments this point, without
      taking care of wrapping when we reach the last HW descriptor. The
      'pending_ptr' index was being wrapped back to 0 at the end, but it
      wasn't used in each iteration of the loop to calculate
      next_pending_hw_desc.
      
      This commit fixes that, and makes next_pending_hw_desc a variable local
      to the loop itself.
      
      Fixes: 19a340b1 ("dmaengine: mv_xor_v2: new driver")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2384df2b
    • Thomas Petazzoni's avatar
      dmaengine: mv_xor_v2: handle mv_xor_v2_prep_sw_desc() error properly · fdcadb5f
      Thomas Petazzoni authored
      commit eb8df543 upstream.
      
      The mv_xor_v2_prep_sw_desc() is called from a few different places in
      the driver, but we never take into account the fact that it might
      return NULL. This commit fixes that, ensuring that we don't panic if
      there are no more descriptors available.
      
      Fixes: 19a340b1 ("dmaengine: mv_xor_v2: new driver")
      Signed-off-by: default avatarThomas Petazzoni <thomas.petazzoni@free-electrons.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fdcadb5f
    • Alexander Sverdlin's avatar
      dmaengine: ep93xx: Don't drain the transfers in terminate_all() · 5c039176
      Alexander Sverdlin authored
      commit 98f9de36 upstream.
      
      Draining the transfers in terminate_all callback happens with IRQs disabled,
      therefore induces huge latency:
      
       irqsoff latency trace v1.1.5 on 4.11.0
       --------------------------------------------------------------------
       latency: 39770 us, #57/57, CPU#0 | (M:preempt VP:0, KP:0, SP:0 HP:0)
          -----------------
          | task: process-129 (uid:0 nice:0 policy:2 rt_prio:50)
          -----------------
        => started at: _snd_pcm_stream_lock_irqsave
        => ended at:   snd_pcm_stream_unlock_irqrestore
      
                        _------=> CPU#
                       / _-----=> irqs-off
                      | / _----=> need-resched
                      || / _---=> hardirq/softirq
                      ||| / _--=> preempt-depth
                      |||| /     delay
        cmd     pid   ||||| time  |   caller
           \   /      |||||  \    |   /
      process-129     0d.s.    3us : _snd_pcm_stream_lock_irqsave
      process-129     0d.s1    9us : snd_pcm_stream_lock <-_snd_pcm_stream_lock_irqsave
      process-129     0d.s1   15us : preempt_count_add <-snd_pcm_stream_lock
      process-129     0d.s2   22us : preempt_count_add <-snd_pcm_stream_lock
      process-129     0d.s3   32us : snd_pcm_update_hw_ptr0 <-snd_pcm_period_elapsed
      process-129     0d.s3   41us : soc_pcm_pointer <-snd_pcm_update_hw_ptr0
      process-129     0d.s3   50us : dmaengine_pcm_pointer <-soc_pcm_pointer
      process-129     0d.s3   58us+: snd_dmaengine_pcm_pointer_no_residue <-dmaengine_pcm_pointer
      process-129     0d.s3   96us : update_audio_tstamp <-snd_pcm_update_hw_ptr0
      process-129     0d.s3  103us : snd_pcm_update_state <-snd_pcm_update_hw_ptr0
      process-129     0d.s3  112us : xrun <-snd_pcm_update_state
      process-129     0d.s3  119us : snd_pcm_stop <-xrun
      process-129     0d.s3  126us : snd_pcm_action <-snd_pcm_stop
      process-129     0d.s3  134us : snd_pcm_action_single <-snd_pcm_action
      process-129     0d.s3  141us : snd_pcm_pre_stop <-snd_pcm_action_single
      process-129     0d.s3  150us : snd_pcm_do_stop <-snd_pcm_action_single
      process-129     0d.s3  157us : soc_pcm_trigger <-snd_pcm_do_stop
      process-129     0d.s3  166us : snd_dmaengine_pcm_trigger <-soc_pcm_trigger
      process-129     0d.s3  175us : ep93xx_dma_terminate_all <-snd_dmaengine_pcm_trigger
      process-129     0d.s3  182us : preempt_count_add <-ep93xx_dma_terminate_all
      process-129     0d.s4  189us*: m2p_hw_shutdown <-ep93xx_dma_terminate_all
      process-129     0d.s4 39472us : m2p_hw_setup <-ep93xx_dma_terminate_all
      
       ... rest skipped...
      
      process-129     0d.s. 40080us : <stack trace>
       => ep93xx_dma_tasklet
       => tasklet_action
       => __do_softirq
       => irq_exit
       => __handle_domain_irq
       => vic_handle_irq
       => __irq_usr
       => 0xb66c6668
      
      Just abort the transfers and warn if the HW state is not what we expect.
      Move draining into device_synchronize callback.
      Signed-off-by: default avatarAlexander Sverdlin <alexander.sverdlin@gmail.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      5c039176
    • Alexander Sverdlin's avatar
      dmaengine: ep93xx: Always start from BASE0 · 81a38a59
      Alexander Sverdlin authored
      commit 0037ae47 upstream.
      
      The current buffer is being reset to zero on device_free_chan_resources()
      but not on device_terminate_all(). It could happen that HW is restarted and
      expects BASE0 to be used, but the driver is not synchronized and will start
      from BASE1. One solution is to reset the buffer explicitly in
      m2p_hw_setup().
      Signed-off-by: default avatarAlexander Sverdlin <alexander.sverdlin@gmail.com>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      81a38a59
    • Hiroyuki Yokoyama's avatar
      dmaengine: usb-dmac: Fix DMAOR AE bit definition · 9812dc2a
      Hiroyuki Yokoyama authored
      commit 9a445bbb upstream.
      
      This patch fixes the register definition of AE (Address Error flag) bit.
      
      Fixes: 0c1c8ff3 ("dmaengine: usb-dmac: Add Renesas USB DMA Controller (USB-DMAC) driver")
      Signed-off-by: default avatarHiroyuki Yokoyama <hiroyuki.yokoyama.vx@renesas.com>
      [Shimoda: add Fixes and Cc tags in the commit log]
      Signed-off-by: default avatarYoshihiro Shimoda <yoshihiro.shimoda.uh@renesas.com>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: default avatarVinod Koul <vinod.koul@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9812dc2a
    • Wanpeng Li's avatar
      KVM: async_pf: avoid async pf injection when in guest mode · 3e456059
      Wanpeng Li authored
      commit 9bc1f09f upstream.
      
       INFO: task gnome-terminal-:1734 blocked for more than 120 seconds.
             Not tainted 4.12.0-rc4+ #8
       "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
       gnome-terminal- D    0  1734   1015 0x00000000
       Call Trace:
        __schedule+0x3cd/0xb30
        schedule+0x40/0x90
        kvm_async_pf_task_wait+0x1cc/0x270
        ? __vfs_read+0x37/0x150
        ? prepare_to_swait+0x22/0x70
        do_async_page_fault+0x77/0xb0
        ? do_async_page_fault+0x77/0xb0
        async_page_fault+0x28/0x30
      
      This is triggered by running both win7 and win2016 on L1 KVM simultaneously,
      and then gives stress to memory on L1, I can observed this hang on L1 when
      at least ~70% swap area is occupied on L0.
      
      This is due to async pf was injected to L2 which should be injected to L1,
      L2 guest starts receiving pagefault w/ bogus %cr2(apf token from the host
      actually), and L1 guest starts accumulating tasks stuck in D state in
      kvm_async_pf_task_wait() since missing PAGE_READY async_pfs.
      
      This patch fixes the hang by doing async pf when executing L1 guest.
      
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Radim Krčmář <rkrcmar@redhat.com>
      Signed-off-by: default avatarWanpeng Li <wanpeng.li@hotmail.com>
      Signed-off-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e456059
    • Marc Zyngier's avatar
      arm: KVM: Allow unaligned accesses at HYP · 37b15215
      Marc Zyngier authored
      commit 33b5c388 upstream.
      
      We currently have the HSCTLR.A bit set, trapping unaligned accesses
      at HYP, but we're not really prepared to deal with it.
      
      Since the rest of the kernel is pretty happy about that, let's follow
      its example and set HSCTLR.A to zero. Modern CPUs don't really care.
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      37b15215
    • Marc Zyngier's avatar
      arm64: KVM: Allow unaligned accesses at EL2 · d06ca326
      Marc Zyngier authored
      commit 78fd6dcf upstream.
      
      We currently have the SCTLR_EL2.A bit set, trapping unaligned accesses
      at EL2, but we're not really prepared to deal with it. So far, this
      has been unnoticed, until GCC 7 started emitting those (in particular
      64bit writes on a 32bit boundary).
      
      Since the rest of the kernel is pretty happy about that, let's follow
      its example and set SCTLR_EL2.A to zero. Modern CPUs don't really
      care.
      Reported-by: default avatarAlexander Graf <agraf@suse.de>
      Signed-off-by: default avatarMarc Zyngier <marc.zyngier@arm.com>
      Signed-off-by: default avatarChristoffer Dall <cdall@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d06ca326