1. 20 2月, 2019 21 次提交
  2. 15 2月, 2019 19 次提交
    • T
      drm/vmwgfx: Return error code from vmw_execbuf_copy_fence_user · 8274c3d4
      Thomas Hellstrom 提交于
      commit 728354c005c36eaf44b6e5552372b67e60d17f56 upstream.
      
      The function was unconditionally returning 0, and a caller would have to
      rely on the returned fence pointer being NULL to detect errors. However,
      the function vmw_execbuf_copy_fence_user() would expect a non-zero error
      code in that case and would BUG otherwise.
      
      So make sure we return a proper non-zero error code if the fence pointer
      returned is NULL.
      
      Cc: <stable@vger.kernel.org>
      Fixes: ae2a1040: ("vmwgfx: Implement fence objects")
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: NDeepak Rawat <drawat@vmware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8274c3d4
    • T
      drm/vmwgfx: Fix setting of dma masks · d74ff5f6
      Thomas Hellstrom 提交于
      commit 4cbfa1e6c09e98450aab3240e5119b0ab2c9795b upstream.
      
      Previously we set only the dma mask and not the coherent mask. Fix that.
      Also, for clarity, make sure both are initially set to 64 bits.
      
      Cc: <stable@vger.kernel.org>
      Fixes: 0d00c488: ("drm/vmwgfx: Fix the driver for large dma addresses")
      Signed-off-by: NThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: NDeepak Rawat <drawat@vmware.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d74ff5f6
    • L
      drm/i915: always return something on DDI clock selection · c2a354ce
      Lucas De Marchi 提交于
      commit 2a121030d4ee3f84f60c6f415f9c44bffbcde81d upstream.
      
      Even if we don't have the correct clock and get a warning, we should not
      skip the return.
      
      v2: improve commit message (from Joonas)
      
      Fixes: 1fa11ee2 ("drm/i915/icl: start adding the TBT pll")
      Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
      Cc: <stable@vger.kernel.org> # v4.19+
      Signed-off-by: NLucas De Marchi <lucas.demarchi@intel.com>
      Reviewed-by: NMika Kahola <mika.kahola@intel.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190125222444.19926-3-lucas.demarchi@intel.com
      (cherry picked from commit 7a61a6dec3dfb9f2e8c39a337580a3c3036c5cdf)
      Signed-off-by: NJani Nikula <jani.nikula@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c2a354ce
    • G
      drm/amd/powerplay: Fix missing break in switch · b81afe37
      Gustavo A. R. Silva 提交于
      commit 2f10d823739680d2477ce34437e8a08a53117f40 upstream.
      
      Add missing break statement in order to prevent the code from falling
      through to the default case.
      
      The resoning for this is that pclk_vol_table is an automatic variable.
      So, it makes no sense to update it just before falling through to the
      default case and return -EINVAL.
      
      This bug was found thanks to the ongoing efforts to enabling
      -Wimplicit-fallthrough.
      
      Fixes: cd70f3d6 ("drm/amd/powerplay: PP/DAL interface changes for dynamic clock switch")
      Cc: stable@vger.kernel.org
      Signed-off-by: NGustavo A. R. Silva <gustavo@embeddedor.com>
      Signed-off-by: NAlex Deucher <alexander.deucher@amd.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b81afe37
    • T
      drm/modes: Prevent division by zero htotal · 56d31786
      Tina Zhang 提交于
      commit a2fcd5c84f7a7825e028381b10182439067aa90d upstream.
      
      This patch prevents division by zero htotal.
      
      In a follow-up mail Tina writes:
      
      > > How did you manage to get here with htotal == 0? This needs backtraces (or if
      > > this is just about static checkers, a mention of that).
      > > -Daniel
      >
      > In GVT-g, we are trying to enable a virtual display w/o setting timings for a pipe
      > (a.k.a htotal=0), then we met the following kernel panic:
      >
      > [   32.832048] divide error: 0000 [#1] SMP PTI
      > [   32.833614] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc4-sriov+ #33
      > [   32.834438] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.10.1-0-g8891697-dirty-20180511_165818-tinazhang-linux-1 04/01/2014
      > [   32.835901] RIP: 0010:drm_mode_hsync+0x1e/0x40
      > [   32.836004] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
      > [   32.836004] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206
      > [   32.836004] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000
      > [   32.836004] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0
      > [   32.836004] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330
      > [   32.836004] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000
      > [   32.836004] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800
      > [   32.836004] FS:  0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000
      > [   32.836004] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      > [   32.836004] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0
      > [   32.836004] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > [   32.836004] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      > [   32.836004] Call Trace:
      > [   32.836004]  intel_mode_from_pipe_config+0x72/0x90
      > [   32.836004]  intel_modeset_setup_hw_state+0x569/0xf90
      > [   32.836004]  intel_modeset_init+0x905/0x1db0
      > [   32.836004]  i915_driver_load+0xb8c/0x1120
      > [   32.836004]  i915_pci_probe+0x4d/0xb0
      > [   32.836004]  local_pci_probe+0x44/0xa0
      > [   32.836004]  ? pci_assign_irq+0x27/0x130
      > [   32.836004]  pci_device_probe+0x102/0x1c0
      > [   32.836004]  driver_probe_device+0x2b8/0x480
      > [   32.836004]  __driver_attach+0x109/0x110
      > [   32.836004]  ? driver_probe_device+0x480/0x480
      > [   32.836004]  bus_for_each_dev+0x67/0xc0
      > [   32.836004]  ? klist_add_tail+0x3b/0x70
      > [   32.836004]  bus_add_driver+0x1e8/0x260
      > [   32.836004]  driver_register+0x5b/0xe0
      > [   32.836004]  ? mipi_dsi_bus_init+0x11/0x11
      > [   32.836004]  do_one_initcall+0x4d/0x1eb
      > [   32.836004]  kernel_init_freeable+0x197/0x237
      > [   32.836004]  ? rest_init+0xd0/0xd0
      > [   32.836004]  kernel_init+0xa/0x110
      > [   32.836004]  ret_from_fork+0x35/0x40
      > [   32.836004] Modules linked in:
      > [   32.859183] ---[ end trace 525608b0ed0e8665 ]---
      > [   32.859722] RIP: 0010:drm_mode_hsync+0x1e/0x40
      > [   32.860287] Code: 31 c0 c3 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 8b 87 d8 00 00 00 85 c0 75 22 8b 4f 68 85 c9 78 1b 69 47 58 e8 03 00 00 99 <f7> f9 b9 d3 4d 62 10 05 f4 01 00 00 f7 e1 89 d0 c1 e8 06 f3 c3 66
      > [   32.862680] RSP: 0000:ffffc900000ebb90 EFLAGS: 00010206
      > [   32.863309] RAX: 0000000000000000 RBX: ffff88001c67c8a0 RCX: 0000000000000000
      > [   32.864182] RDX: 0000000000000000 RSI: ffff88001c67c000 RDI: ffff88001c67c8a0
      > [   32.865206] RBP: ffff88001c7d03a0 R08: ffff88001c67c8a0 R09: ffff88001c7d0330
      > [   32.866359] R10: ffffffff822c3a98 R11: 0000000000000001 R12: ffff88001c67c000
      > [   32.867213] R13: ffff88001c7d0370 R14: ffffffff8207eb78 R15: ffff88001c67c800
      > [   32.868075] FS:  0000000000000000(0000) GS:ffff88001da00000(0000) knlGS:0000000000000000
      > [   32.868983] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      > [   32.869659] CR2: 0000000000000000 CR3: 000000000220a000 CR4: 00000000000006f0
      > [   32.870599] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
      > [   32.871598] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
      > [   32.872549] Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
      >
      > Since drm_mode_hsync() has the logic to check mode->htotal, I just extend it to cover the case htotal==0.
      Signed-off-by: NTina Zhang <tina.zhang@intel.com>
      Cc: Adam Jackson <ajax@redhat.com>
      Cc: Dave Airlie <airlied@redhat.com>
      Cc: Daniel Vetter <daniel@ffwll.ch>
      [danvet: Add additional explanations + cc: stable.]
      Cc: stable@vger.kernel.org
      Signed-off-by: NDaniel Vetter <daniel.vetter@ffwll.ch>
      Link: https://patchwork.freedesktop.org/patch/msgid/1548228539-3061-1-git-send-email-tina.zhang@intel.comSigned-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      56d31786
    • V
      mic: vop: Fix use-after-free on remove · 1ce0fceb
      Vincent Whitchurch 提交于
      commit 70ed7148dadb812f2f7c9927e98ef3cf4869dfa9 upstream.
      
      KASAN detects a use-after-free when vop devices are removed.
      
      This problem was introduced by commit 0063e8bb ("virtio_vop:
      don't kfree device on register failure").  That patch moved the freeing
      of the struct _vop_vdev to the release function, but failed to ensure
      that vop holds a reference to the device when it doesn't want it to go
      away.  A kfree() was replaced with a put_device() in the unregistration
      path, but the last reference to the device is already dropped in
      unregister_virtio_device() so the struct is freed before vop is done
      with it.
      
      Fix it by holding a reference until cleanup is done.  This is similar to
      the fix in virtio_pci in commit 2989be09 ("virtio_pci: fix use
      after free on release").
      
       ==================================================================
       BUG: KASAN: use-after-free in vop_scan_devices+0xc6c/0xe50 [vop]
       Read of size 8 at addr ffff88800da18580 by task kworker/0:1/12
      
       CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.0.0-rc4+ #53
       Workqueue: events vop_hotplug_devices [vop]
       Call Trace:
        dump_stack+0x74/0xbb
        print_address_description+0x5d/0x2b0
        ? vop_scan_devices+0xc6c/0xe50 [vop]
        kasan_report+0x152/0x1aa
        ? vop_scan_devices+0xc6c/0xe50 [vop]
        ? vop_scan_devices+0xc6c/0xe50 [vop]
        vop_scan_devices+0xc6c/0xe50 [vop]
        ? vop_loopback_free_irq+0x160/0x160 [vop_loopback]
        process_one_work+0x7c0/0x14b0
        ? pwq_dec_nr_in_flight+0x2d0/0x2d0
        ? do_raw_spin_lock+0x120/0x280
        worker_thread+0x8f/0xbf0
        ? __kthread_parkme+0x78/0xf0
        ? process_one_work+0x14b0/0x14b0
        kthread+0x2ae/0x3a0
        ? kthread_park+0x120/0x120
        ret_from_fork+0x3a/0x50
      
       Allocated by task 12:
        kmem_cache_alloc_trace+0x13a/0x2a0
        vop_scan_devices+0x473/0xe50 [vop]
        process_one_work+0x7c0/0x14b0
        worker_thread+0x8f/0xbf0
        kthread+0x2ae/0x3a0
        ret_from_fork+0x3a/0x50
      
       Freed by task 12:
        kfree+0x104/0x310
        device_release+0x73/0x1d0
        kobject_put+0x14f/0x420
        unregister_virtio_device+0x32/0x50
        vop_scan_devices+0x19d/0xe50 [vop]
        process_one_work+0x7c0/0x14b0
        worker_thread+0x8f/0xbf0
        kthread+0x2ae/0x3a0
        ret_from_fork+0x3a/0x50
      
       The buggy address belongs to the object at ffff88800da18008
        which belongs to the cache kmalloc-2k of size 2048
       The buggy address is located 1400 bytes inside of
        2048-byte region [ffff88800da18008, ffff88800da18808)
       The buggy address belongs to the page:
       page:ffffea0000368600 count:1 mapcount:0 mapping:ffff88801440dbc0 index:0x0 compound_mapcount: 0
       flags: 0x4000000000010200(slab|head)
       raw: 4000000000010200 ffffea0000378608 ffffea000037a008 ffff88801440dbc0
       raw: 0000000000000000 00000000000d000d 00000001ffffffff 0000000000000000
       page dumped because: kasan: bad access detected
      
       Memory state around the buggy address:
        ffff88800da18480: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
        ffff88800da18500: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       >ffff88800da18580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
                          ^
        ffff88800da18600: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
        ffff88800da18680: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
       ==================================================================
      
      Fixes: 0063e8bb ("virtio_vop: don't kfree device on register failure")
      Signed-off-by: NVincent Whitchurch <vincent.whitchurch@axis.com>
      Cc: stable <stable@vger.kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      1ce0fceb
    • S
      firmware: arm_scmi: provide the mandatory device release callback · d4e7c942
      Sudeep Holla 提交于
      commit 46edb8d1322c1763dd04e179992f8e9996085047 upstream.
      
      The device/driver model clearly mandates that bus driver that discover
      and allocate the device must set the release callback. This callback
      will be used to free the device after all references have gone away.
      
      scmi bus driver is missing the obvious callback which will result in
      the following warning if the device is unregistered:
      
      Device 'scmi_dev.1' does not have a release() function, it is broken and
      must be fixed. See Documentation/kobject.txt.
      WARNING at drivers/base/core.c:922 device_release+0x8c/0xa0
      Hardware name: ARM LTD Juno Development Platform BIOS EDK II Jan 21 2019
      Workqueue: events deferred_probe_work_func
      pstate: 60000005 (nZCv daif -PAN -UAO)
      pc : device_release+0x8c/0xa0
      lr : device_release+0x8c/0xa0
      Call trace:
       device_release+0x8c/0xa0
       kobject_put+0x8c/0x208
       device_unregister+0x30/0x78
       scmi_device_destroy+0x28/0x50
       scmi_probe+0x354/0x5b0
       platform_drv_probe+0x58/0xa8
       really_probe+0x2c4/0x3e8
       driver_probe_device+0x12c/0x148
       __device_attach_driver+0xac/0x150
       bus_for_each_drv+0x78/0xd8
       __device_attach+0xe0/0x168
       device_initial_probe+0x24/0x30
       bus_probe_device+0xa0/0xa8
       deferred_probe_work_func+0x8c/0xe0
       process_one_work+0x1f0/0x478
       worker_thread+0x22c/0x450
       kthread+0x134/0x138
       ret_from_fork+0x10/0x1c
      ---[ end trace 420bdb7f6af50937 ]---
      
      Fix the issue by providing scmi_device_release callback. We have
      everything required for device release already in scmi_device_destroy,
      so we just need to move freeing of the device to scmi_device_release.
      
      Fixes: 933c5044 ("firmware: arm_scmi: add scmi protocol bus to enumerate protocol devices")
      Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      Cc: stable@vger.kernel.org # 4.17+
      Signed-off-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d4e7c942
    • D
      pinctrl: cherryview: fix Strago DMI workaround · 9b66753c
      Dmitry Torokhov 提交于
      commit e3f72b749da2bf63bed7409e416f160418d475b6 upstream.
      
      Well, hopefully 3rd time is a charm. We tried making that check
      DMI_BIOS_VERSION and DMI_BOARD_VERSION, but the real one is
      DMI_PRODUCT_VERSION.
      
      Fixes: 86c5dd68 ("pinctrl: cherryview: limit Strago DMI workarounds to version 1.0")
      Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=197953
      Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1631930
      Cc: stable@vger.kernel.org
      Signed-off-by: NDmitry Torokhov <dmitry.torokhov@gmail.com>
      Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Acked-by: NMika Westerberg <mika.westerberg@linux.intel.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      9b66753c
    • C
      pinctrl: sunxi: Correct number of IRQ banks on H6 main pin controller · 93f6fb60
      Chen-Yu Tsai 提交于
      commit 10098709b4ee6f6f19f25ba81d9c6f83518c584c upstream.
      
      The H6 main pin controller has four banks of interrupt-triggering pins.
      The driver as originally submitted only specified three, but had pin
      descriptions referencing a fourth bank. This results in a out-of-bounds
      access into .irq_array of struct sunxi_pinctrl. This however did not
      result in a crash until v4.20, with commit a66d972465d1 ("devres: Align
      data[] to ARCH_KMALLOC_MINALIGN"), which changed the alignment of memory
      region returned by devm_kcalloc(). The increase likely moved the
      out-of-bounds access into the next, unmapped page.
      
      With KASAN on, the bug is quite clear:
      
          BUG: KASAN: slab-out-of-bounds in sunxi_pinctrl_init_with_variant+0x49c/0x12b8
          Write of size 4 at addr ffff80002c680280 by task swapper/0/1
      
          CPU: 2 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc1-00016-gc480a5e6a077 #3
          Hardware name: OrangePi Lite2 (DT)
          Call trace:
           dump_backtrace+0x0/0x220
           show_stack+0x14/0x20
           dump_stack+0xac/0xd4
           print_address_description+0x60/0x25c
           kasan_report+0x14c/0x1ac
           __asan_store4+0x80/0xa0
           sunxi_pinctrl_init_with_variant+0x49c/0x12b8
           h6_pinctrl_probe+0x18/0x20
           platform_drv_probe+0x6c/0xc8
           really_probe+0x244/0x4b0
           driver_probe_device.part.4+0x11c/0x164
           __driver_attach+0x120/0x190
           bus_for_each_dev+0xe8/0x158
           driver_attach+0x30/0x40
           bus_add_driver+0x308/0x318
           driver_register+0xbc/0x1d0
           __platform_driver_register+0x7c/0x88
           h6_pinctrl_driver_init+0x18/0x20
           do_one_initcall+0xd4/0x208
           kernel_init_freeable+0x230/0x2c8
           kernel_init+0x10/0x108
           ret_from_fork+0x10/0x1c
      
          Allocated by task 1:
           kasan_kmalloc.part.0+0x4c/0x100
           kasan_kmalloc+0xc4/0xe8
           kasan_slab_alloc+0x14/0x20
           __kmalloc_track_caller+0x130/0x238
           devm_kmalloc+0x34/0xd0
           sunxi_pinctrl_init_with_variant+0x1d8/0x12b8
           h6_pinctrl_probe+0x18/0x20
           platform_drv_probe+0x6c/0xc8
           really_probe+0x244/0x4b0
           driver_probe_device.part.4+0x11c/0x164
           __driver_attach+0x120/0x190
           bus_for_each_dev+0xe8/0x158
           driver_attach+0x30/0x40
           bus_add_driver+0x308/0x318
           driver_register+0xbc/0x1d0
           __platform_driver_register+0x7c/0x88
           h6_pinctrl_driver_init+0x18/0x20
           do_one_initcall+0xd4/0x208
           kernel_init_freeable+0x230/0x2c8
           kernel_init+0x10/0x108
           ret_from_fork+0x10/0x1c
      
          Freed by task 0:
          (stack is not available)
      
          The buggy address belongs to the object at ffff80002c680080
           which belongs to the cache kmalloc-512 of size 512
          The buggy address is located 0 bytes to the right of
           512-byte region [ffff80002c680080, ffff80002c680280)
          The buggy address belongs to the page:
          page:ffff7e0000b1a000 count:1 mapcount:0 mapping:ffff80002e00c780 index:0xffff80002c683c80 compound_mapcount: 0
          flags: 0x10200(slab|head)
          raw: 0000000000010200 ffff80002e003a10 ffff80002e003a10 ffff80002e00c780
          raw: ffff80002c683c80 0000000000100001 00000001ffffffff 0000000000000000
          page dumped because: kasan: bad access detected
      
          Memory state around the buggy address:
           ffff80002c680180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
           ffff80002c680200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
          >ffff80002c680280: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      		       ^
           ffff80002c680300: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
           ffff80002c680380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
      
      Correct the number of IRQ banks so there are no more mismatches.
      
      Fixes: c8a83090 ("pinctrl: sunxi: add support for the Allwinner H6 main pin controller")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NChen-Yu Tsai <wens@csie.org>
      Tested-by: NNeil Armstrong <narmstrong@baylibre.com>
      Acked-by: NMaxime Ripard <maxime.ripard@bootlin.com>
      Signed-off-by: NLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      93f6fb60
    • T
      mei: me: add ice lake point device id. · edd8fb55
      Tomas Winkler 提交于
      commit efe814e90b98aed6d655b5a4092b9114b8b26e42 upstream.
      
      Add icelake mei device id.
      
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NTomas Winkler <tomas.winkler@intel.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      edd8fb55
    • D
      misc: vexpress: Off by one in vexpress_syscfg_exec() · db5f65bf
      Dan Carpenter 提交于
      commit f8a70d8b889f180e6860cb1f85fed43d37844c5a upstream.
      
      The > comparison should be >= to prevent reading beyond the end of the
      func->template[] array.
      
      (The func->template array is allocated in vexpress_syscfg_regmap_init()
      and it has func->num_templates elements.)
      
      Fixes: 974cc7b9 ("mfd: vexpress: Define the device as MFD cells")
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Acked-by: NSudeep Holla <sudeep.holla@arm.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      db5f65bf
    • D
      iio: ti-ads8688: Update buffer allocation for timestamps · 3e17af25
      Dan Murphy 提交于
      commit f214ff521fb1f861c8d7f7d0af98b06bf61b3369 upstream.
      
      Per Jonathan Cameron, the buffer needs to allocate room for a
      64 bit timestamp as well as the channels.  Change the buffer
      to allocate this additional space.
      
      Fixes: 2a864877 ("iio: adc: ti-ads8688: add trigger and buffer support")
      Signed-off-by: NDan Murphy <dmurphy@ti.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3e17af25
    • M
      iio: chemical: atlas-ph-sensor: correct IIO_TEMP values to millicelsius · af770a15
      Matt Ranostay 提交于
      commit 0808831dc62e90023ad14ff8da4804c7846e904b upstream.
      
      IIO_TEMP scale value for temperature was incorrect and not in millicelsius
      as required by the ABI documentation.
      Signed-off-by: NMatt Ranostay <matt.ranostay@konsulko.com>
      Fixes: 27dec00e (iio: chemical: add Atlas pH-SM sensor support)
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      af770a15
    • H
      iio: adc: axp288: Fix TS-pin handling · 38d28640
      Hans de Goede 提交于
      commit 9bcf15f75cac3c6a00d8f8083a635de9c8537799 upstream.
      
      Prior to this commit there were 3 issues with our handling of the TS-pin:
      
      1) There are 2 ways how the firmware can disable monitoring of the TS-pin
      for designs which do not have a temperature-sensor for the battery:
      a) Clearing bit 0 of the AXP20X_ADC_EN1 register
      b) Setting bit 2 of the AXP288_ADC_TS_PIN_CTRL monitoring
      
      Prior to this commit we were unconditionally setting both bits to the
      value used on devices with a TS. This causes the temperature protection to
      kick in on devices without a TS, such as the Jumper ezbook v2, causing
      them to not charge under Linux.
      
      This commit fixes this by using regmap_update_bits when updating these 2
      registers, leaving the 2 mentioned bits alone.
      
      The next 2 problems are related to our handling of the current-source
      for the TS-pin. The current-source used for the battery temp-sensor (TS)
      is shared with the GPADC. For proper fuel-gauge and charger operation the
      TS current-source needs to be permanently on. But to read the GPADC we
      need to temporary switch the TS current-source to ondemand, so that the
      GPADC can use it, otherwise we will always read an all 0 value.
      
      2) Problem 2 is we were writing hardcoded values to the ADC TS pin-ctrl
      register, overwriting various other unrelated bits. Specifically we were
      overwriting the current-source setting for the TS and GPIO0 pins, forcing
      it to 80ųA independent of its original setting. On a Chuwi Vi10 tablet
      this was causing us to get a too high adc value (due to a too high
      current-source) resulting in the following errors being logged:
      
      ACPI Error: AE_ERROR, Returned by Handler for [UserDefinedRegion]
      ACPI Error: Method parse/execution failed \_SB.SXP1._TMP, AE_ERROR
      
      This commit fixes this by using regmap_update_bits to change only the
      relevant bits.
      
      3) After reading the GPADC channel we were unconditionally enabling the
      TS current-source even on devices where the TS-pin is not used and the
      current-source thus was off before axp288_adc_read_raw call.
      
      This commit fixes this by making axp288_adc_set_ts a nop on devices where
      the ADC is not enabled for the TS-pin.
      
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1610545
      Fixes: 3091141d ("iio: adc: axp288: Fix the GPADC pin ...")
      Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Cc: <Stable@vger.kernel.org>
      Signed-off-by: NJonathan Cameron <Jonathan.Cameron@huawei.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      38d28640
    • H
      libata: Add NOLPM quirk for SAMSUNG MZ7TE512HMHP-000L1 SSD · 88ff6a0b
      Hans de Goede 提交于
      commit dd957493baa586f1431490f97f9c7c45eaf8ab10 upstream.
      
      We've received a bugreport that using LPM with a SAMSUNG
      MZ7TE512HMHP-000L1 SSD leads to system instability, we already have
      a quirk for the MZ7TD256HAFV-000L9, which is also a Samsun EVO 840 /
      PM851 OEM model, so it seems some of these models have a LPM issue.
      
      This commits adds a NOLPM quirk for the model string from the new
      bugeport, to avoid the reported stability issues.
      
      Cc: stable@vger.kernel.org
      BugLink: https://bugzilla.redhat.com/show_bug.cgi?id=1571330Signed-off-by: NHans de Goede <hdegoede@redhat.com>
      Signed-off-by: NJens Axboe <axboe@kernel.dk>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      88ff6a0b
    • M
      mtd: rawnand: gpmi: fix MX28 bus master lockup problem · 7c5d650a
      Martin Kepplinger 提交于
      commit d5d27fd9826b59979b184ec288e4812abac0e988 upstream.
      
      Disable BCH soft reset according to MX23 erratum #2847 ("BCH soft
      reset may cause bus master lock up") for MX28 too. It has the same
      problem.
      
      Observed problem: once per 100,000+ MX28 reboots NAND read failed on
      DMA timeout errors:
      [    1.770823] UBI: attaching mtd3 to ubi0
      [    2.768088] gpmi_nand: DMA timeout, last DMA :1
      [    3.958087] gpmi_nand: BCH timeout, last DMA :1
      [    4.156033] gpmi_nand: Error in ECC-based read: -110
      [    4.161136] UBI warning: ubi_io_read: error -110 while reading 64
      bytes from PEB 0:0, read only 0 bytes, retry
      [    4.171283] step 1 error
      [    4.173846] gpmi_nand: Chip: 0, Error -1
      
      Without BCH soft reset we successfully executed 1,000,000 MX28 reboots.
      
      I have a quote from NXP regarding this problem, from July 18th 2016:
      
      "As the i.MX23 and i.MX28 are of the same generation, they share many
      characteristics. Unfortunately, also the erratas may be shared.
      In case of the documented erratas and the workarounds, you can also
      apply the workaround solution of one device on the other one. This have
      been reported, but I’m afraid that there are not an estimated date for
      updating the Errata documents.
      Please accept our apologies for any inconveniences this may cause."
      
      Fixes: 6f2a6a52 ("mtd: nand: gpmi: reset BCH earlier, too, to avoid NAND startup problems")
      Cc: stable@vger.kernel.org
      Signed-off-by: NManfred Schlaegl <manfred.schlaegl@ginzinger.com>
      Signed-off-by: NMartin Kepplinger <martin.kepplinger@ginzinger.com>
      Reviewed-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Reviewed-by: NFabio Estevam <festevam@gmail.com>
      Acked-by: NHan Xu <han.xu@nxp.com>
      Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7c5d650a
    • B
      mtd: spinand: Fix the error/cleanup path in spinand_init() · a72040a9
      Boris Brezillon 提交于
      commit c3c7dbf4887ab3ed9d611cd1f6e16937f8700743 upstream.
      
      The manufacturer specific initialization has already been done when
      block unlocking takes place, and if anything goes wrong during this
      procedure we should call spinand_manufacturer_cleanup().
      
      Fixes: 7529df46 ("mtd: nand: Add core infrastructure to support SPI NANDs")
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
      Acked-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a72040a9
    • B
      mtd: spinand: Handle the case where PROGRAM LOAD does not reset the cache · b3ce7757
      Boris Brezillon 提交于
      commit 13c15e07eedf26092054c8c71f2f47edb8388310 upstream.
      
      Looks like PROGRAM LOAD (AKA write cache) does not necessarily reset
      the cache content to 0xFF (depends on vendor implementation), so we
      must fill the page cache entirely even if we only want to program the
      data portion of the page, otherwise we might corrupt the BBM or user
      data previously programmed in OOB area.
      
      Fixes: 7529df46 ("mtd: nand: Add core infrastructure to support SPI NANDs")
      Reported-by: NStefan Roese <sr@denx.de>
      Cc: <stable@vger.kernel.org>
      Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
      Tested-by: NStefan Roese <sr@denx.de>
      Reviewed-by: NStefan Roese <sr@denx.de>
      Acked-by: NMiquel Raynal <miquel.raynal@bootlin.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b3ce7757
    • B
      mtd: Make sure mtd->erasesize is valid even if the partition is of size 0 · 3ca59bf1
      Boris Brezillon 提交于
      commit ad4635153034c20c6f6e211e2ed3fd38b658649a upstream.
      
      Commit 33f45c44 ("mtd: Do not allow MTD devices with inconsistent
      erase properties") introduced a check to make sure ->erasesize and
      ->_erase values are consistent with the MTD_NO_ERASE flag.
      This patch did not take the 0 bytes partition case into account which
      can happen when the defined partition is outside the flash device memory
      range. Fix that by setting the partition erasesize to the parent
      erasesize.
      
      Fixes: 33f45c44 ("mtd: Do not allow MTD devices with inconsistent erase properties")
      Reported-by: NGeert Uytterhoeven <geert@linux-m68k.org>
      Cc: <stable@vger.kernel.org>
      Cc: Geert Uytterhoeven <geert@linux-m68k.org>
      Signed-off-by: NBoris Brezillon <bbrezillon@kernel.org>
      Tested-by: NGeert Uytterhoeven <geert+renesas@glider.be>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3ca59bf1