1. 03 Mar, 2016 40 commits
    • Felix Kuehling's avatar
      drm/amdgpu: Fix off-by-one errors in amdgpu_vm_bo_map · 8397905d
      Felix Kuehling authored
      commit 005ae95e upstream.
      
      eaddr is sometimes treated as the last address inside the address
      range, and sometimes as the first address outside the range. This
      was resulting in errors when a test filled up the entire address
      space. Make it consistent to always be the last address within the
      range.
      Signed-off-by: default avatarFelix.Kuehling <Felix.Kuehling@amd.com>
      Reviewed-by: default avatarChristian König <christian.koenig@amd.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8397905d
    • Rob Clark's avatar
      drm/vmwgfx: respect 'nomodeset' · 02b0518c
      Rob Clark authored
      commit 96c5d076 upstream.
      Signed-off-by: default avatarRob Clark <robdclark@gmail.com>
      Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>.
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      02b0518c
    • Thomas Hellstrom's avatar
      drm/vmwgfx: Fix a width / pitch mismatch on framebuffer updates · 15ec2c4c
      Thomas Hellstrom authored
      commit a50e2bf5 upstream.
      
      When the framebuffer is a vmwgfx dma buffer and a proxy surface is
      created, the vmw_kms_update_proxy() function requires that the proxy
      surface width and the framebuffer pitch are compatible, otherwise
      display corruption occurs as seen in gnome-shell/native with software
      3D. Since the framebuffer pitch is determined by user-space, allocate
      a proxy surface the width of which is based on the framebuffer pitch
      rather than on the framebuffer width.
      Reported-by: default avatarRaphael Hertzog <buxy@kali.org>
      Tested-by: default avatarMati Aharoni <muts@kali.org>
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: default avatarBrian Paul <brianp@vmware.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      15ec2c4c
    • Thomas Hellstrom's avatar
      drm/vmwgfx: Fix an incorrect lock check · a4de54fb
      Thomas Hellstrom authored
      commit fb89ac51 upstream.
      
      With CONFIG_SMP=n and CONFIG_DEBUG_SPINLOCK=y the vmwgfx kernel module
      would unconditionally throw a bug when checking for a held spinlock
      in the command buffer code. Fix this by using a lockdep check.
      Reported-and-tested-by: default avatarTetsuo Handa <penguin-kernel@i-love-sakura.ne.jp>
      Signed-off-by: default avatarThomas Hellstrom <thellstrom@vmware.com>
      Reviewed-by: default avatarSinclair Yeh <syeh@vmware.com>
      Signed-off-by: default avatarDave Airlie <airlied@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a4de54fb
    • Michael S. Tsirkin's avatar
      virtio_pci: fix use after free on release · d56842d8
      Michael S. Tsirkin authored
      commit 2989be09 upstream.
      
      KASan detected a use-after-free error in virtio-pci remove code. In
      virtio_pci_remove(), vp_dev is still used after being freed in
      unregister_virtio_device() (in virtio_pci_release_dev() more
      precisely).
      
      To fix, keep a reference until cleanup is done.
      
      Fixes: 63bd62a0 ("virtio_pci: defer kfree until release callback")
      Reported-by: default avatarJerome Marchand <jmarchan@redhat.com>
      Cc: Sasha Levin <sasha.levin@oracle.com>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Tested-by: default avatarJerome Marchand <jmarchan@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      d56842d8
    • Minchan Kim's avatar
      virtio_balloon: fix race between migration and ballooning · afb02993
      Minchan Kim authored
      commit 21ea9fb6 upstream.
      
      In balloon_page_dequeue, pages_lock should cover the loop
      (ie, list_for_each_entry_safe). Otherwise, the cursor page could
      be isolated by compaction and then list_del by isolation could
      poison the page->lru.{prev,next} so the loop finally could
      access wrong address like this. This patch fixes the bug.
      
      general protection fault: 0000 [#1] SMP
      Dumping ftrace buffer:
         (ftrace buffer empty)
      Modules linked in:
      CPU: 2 PID: 82 Comm: vballoon Not tainted 4.4.0-rc5-mm1-access_bit+ #1906
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
      task: ffff8800a7ff0000 ti: ffff8800a7fec000 task.ti: ffff8800a7fec000
      RIP: 0010:[<ffffffff8115e754>]  [<ffffffff8115e754>] balloon_page_dequeue+0x54/0x130
      RSP: 0018:ffff8800a7fefdc0  EFLAGS: 00010246
      RAX: ffff88013fff9a70 RBX: ffffea000056fe00 RCX: 0000000000002b7d
      RDX: ffff88013fff9a70 RSI: ffffea000056fe00 RDI: ffff88013fff9a68
      RBP: ffff8800a7fefde8 R08: ffffea000056fda0 R09: 0000000000000000
      R10: ffff8800a7fefd90 R11: 0000000000000001 R12: dead0000000000e0
      R13: ffffea000056fe20 R14: ffff880138809070 R15: ffff880138809060
      FS:  0000000000000000(0000) GS:ffff88013fc40000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
      CR2: 00007f229c10e000 CR3: 00000000b8b53000 CR4: 00000000000006a0
      Stack:
       0000000000000100 ffff880138809088 ffff880138809000 ffff880138809060
       0000000000000046 ffff8800a7fefe28 ffffffff812c86d3 ffff880138809020
       ffff880138809000 fffffffffff91900 0000000000000100 ffff880138809060
      Call Trace:
       [<ffffffff812c86d3>] leak_balloon+0x93/0x1a0
       [<ffffffff812c8bc7>] balloon+0x217/0x2a0
       [<ffffffff8143739e>] ? __schedule+0x31e/0x8b0
       [<ffffffff81078160>] ? abort_exclusive_wait+0xb0/0xb0
       [<ffffffff812c89b0>] ? update_balloon_stats+0xf0/0xf0
       [<ffffffff8105b6e9>] kthread+0xc9/0xe0
       [<ffffffff8105b620>] ? kthread_park+0x60/0x60
       [<ffffffff8143b4af>] ret_from_fork+0x3f/0x70
       [<ffffffff8105b620>] ? kthread_park+0x60/0x60
      Code: 8d 60 e0 0f 84 af 00 00 00 48 8b 43 20 a8 01 75 3b 48 89 d8 f0 0f ba 28 00 72 10 48 8b 03 f6 c4 08 75 2f 48 89 df e8 8c 83 f9 ff <49> 8b 44 24 20 4d 8d 6c 24 20 48 83 e8 20 4d 39 f5 74 7a 4c 89
      RIP  [<ffffffff8115e754>] balloon_page_dequeue+0x54/0x130
       RSP <ffff8800a7fefdc0>
      ---[ end trace 43cf28060d708d5f ]---
      Kernel panic - not syncing: Fatal exception
      Dumping ftrace buffer:
         (ftrace buffer empty)
      Kernel Offset: disabled
      Signed-off-by: default avatarMinchan Kim <minchan@kernel.org>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Acked-by: default avatarRafael Aquini <aquini@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      afb02993
    • Minchan Kim's avatar
      virtio_balloon: fix race by fill and leak · ac3981b1
      Minchan Kim authored
      commit f68b992b upstream.
      
      During my compaction-related stuff, I encountered a bug
      with ballooning.
      
      With repeated inflating and deflating cycle, guest memory(
      ie, cat /proc/meminfo | grep MemTotal) is decreased and
      couldn't be recovered.
      
      The reason is balloon_lock doesn't cover release_pages_balloon
      so struct virtio_balloon fields could be overwritten by race
      of fill_balloon(e,g, vb->*pfns could be critical).
      
      This patch fixes it in my test.
      Signed-off-by: default avatarMinchan Kim <minchan@kernel.org>
      Signed-off-by: default avatarMichael S. Tsirkin <mst@redhat.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      ac3981b1
    • Henry Chen's avatar
      regulator: mt6311: MT6311_REGULATOR needs to select REGMAP_I2C · 7d661c46
      Henry Chen authored
      commit aab3c3f3 upstream.
      
      This patch fix the below build error:
      drivers/regulator/mt6311-regulator.c:111: undefined reference to `__devm_regmap_init_i2c'
      Signed-off-by: default avatarHenry Chen <henryc.chen@mediatek.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7d661c46
    • Chen-Yu Tsai's avatar
      regulator: axp20x: Fix GPIO LDO enable value for AXP22x · 40ab2d7d
      Chen-Yu Tsai authored
      commit 3cb99e2e upstream.
      
      The enable/disable values for GPIO LDOs are reversed. It seems no one
      noticed as AXP22x support was introduced recently, and no one was using
      the GPIO LDOs, either because no designs actually use them or board
      support hasn't caught up.
      
      Fixes: 1b82b4e4 ("regulator: axp20x: Add support for AXP22X regulators")
      Signed-off-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      40ab2d7d
    • Marek Szyprowski's avatar
      clk: exynos: use irqsave version of spin_lock to avoid deadlock with irqs · 7ca59689
      Marek Szyprowski authored
      commit 6b4feaea upstream.
      
      It is allowed to enable/disable clocks from interrupts, so common Exynos
      ARM clock management code for CPUfreq should use 'irqsave' version of
      spin_lock calls to avoid potential deadlock caused by spin_lock recursion.
      The same spin_lock is used by gate/mux clocks during enable/disable calls.
      
      This deadlock, can be reproduced by enabling CPUfreq (ondemand or
      userspace) and decoding video with s5p-mfc driver.
      
      Relevant stack trace:
      [ 5928.061534] BUG: spinlock recursion on CPU#0, bash/1252
      [ 5928.061609]  lock: 0xee80454c, .magic: dead4ead, .owner: bash/1252, .owner_cpu: 0
      [ 5928.068586] CPU: 0 PID: 1252 Comm: bash Tainted: G        W       4.4.0-rc4-00001-g447a7fd #678
      [ 5928.077260] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
      [ 5928.083359] [<c00153dc>] (unwind_backtrace) from [<c00121b4>] (show_stack+0x10/0x14)
      [ 5928.091072] [<c00121b4>] (show_stack) from [<c0213e28>] (dump_stack+0x68/0xb8)
      [ 5928.098275] [<c0213e28>] (dump_stack) from [<c005c1ec>] (do_raw_spin_lock+0x184/0x1ac)
      [ 5928.106177] [<c005c1ec>] (do_raw_spin_lock) from [<c05cfa98>] (_raw_spin_lock_irqsave+0x20/0x28)
      [ 5928.114943] [<c05cfa98>] (_raw_spin_lock_irqsave) from [<c0468698>] (clk_gate_endisable+0x24/0x98)
      [ 5928.123882] [<c0468698>] (clk_gate_endisable) from [<c0464d40>] (clk_core_disable+0x60/0x84)
      [ 5928.132299] [<c0464d40>] (clk_core_disable) from [<c0465e00>] (clk_disable+0x24/0x30)
      [ 5928.140117] [<c0465e00>] (clk_disable) from [<c03f3b80>] (s5p_mfc_handle_frame+0x254/0x860)
      [ 5928.148445] [<c03f3b80>] (s5p_mfc_handle_frame) from [<c03f4b34>] (s5p_mfc_irq+0x890/0xa24)
      [ 5928.156778] [<c03f4b34>] (s5p_mfc_irq) from [<c00627bc>] (handle_irq_event_percpu+0x50/0x14c)
      [ 5928.165283] [<c00627bc>] (handle_irq_event_percpu) from [<c00628f0>] (handle_irq_event+0x38/0x5c)
      [ 5928.174143] [<c00628f0>] (handle_irq_event) from [<c0065864>] (handle_fasteoi_irq+0xdc/0x1a4)
      [ 5928.182645] [<c0065864>] (handle_fasteoi_irq) from [<c0062090>] (generic_handle_irq+0x18/0x28)
      [ 5928.191236] [<c0062090>] (generic_handle_irq) from [<c00621a4>] (__handle_domain_irq+0x6c/0xdc)
      [ 5928.199917] [<c00621a4>] (__handle_domain_irq) from [<c0009470>] (gic_handle_irq+0x4c/0x98)
      [ 5928.208249] [<c0009470>] (gic_handle_irq) from [<c0012c54>] (__irq_svc+0x54/0x90)
      [ 5928.215709] Exception stack(0xeddb5cb8 to 0xeddb5d00)
      [ 5928.220745] 5ca0:                                                       ee80454c faddfadc
      [ 5928.228906] 5cc0: 00000000 01000001 ee831ce0 f8114200 ee807c00 01130520 00000403 eddb5d84
      [ 5928.237063] 5ce0: ee807c48 2faf0800 ee807c0c eddb5d08 c046b618 c046b634 20000053 ffffffff
      [ 5928.245225] [<c0012c54>] (__irq_svc) from [<c046b634>] (exynos_cpuclk_notifier_cb+0x170/0x270)
      [ 5928.253823] [<c046b634>] (exynos_cpuclk_notifier_cb) from [<c003cb58>] (notifier_call_chain+0x44/0x84)
      [ 5928.263106] [<c003cb58>] (notifier_call_chain) from [<c003ccd4>] (__srcu_notifier_call_chain+0x6c/0x9c)
      [ 5928.272480] [<c003ccd4>] (__srcu_notifier_call_chain) from [<c003cd1c>] (srcu_notifier_call_chain+0x18/0x20)
      [ 5928.282288] [<c003cd1c>] (srcu_notifier_call_chain) from [<c0464ed0>] (__clk_notify+0x6c/0x74)
      [ 5928.290881] [<c0464ed0>] (__clk_notify) from [<c0465388>] (clk_propagate_rate_change+0xa0/0xac)
      [ 5928.299561] [<c0465388>] (clk_propagate_rate_change) from [<c0465378>] (clk_propagate_rate_change+0x90/0xac)
      [ 5928.309370] [<c0465378>] (clk_propagate_rate_change) from [<c04666fc>] (clk_core_set_rate_nolock+0x64/0xa8)
      [ 5928.319091] [<c04666fc>] (clk_core_set_rate_nolock) from [<c0466760>] (clk_set_rate+0x20/0x30)
      [ 5928.327686] [<c0466760>] (clk_set_rate) from [<c0428c70>] (set_target+0xe8/0x23c)
      [ 5928.335152] [<c0428c70>] (set_target) from [<c04244d0>] (__cpufreq_driver_target+0x184/0x29c)
      [ 5928.343655] [<c04244d0>] (__cpufreq_driver_target) from [<c0427128>] (cpufreq_set+0x44/0x64)
      [ 5928.352074] [<c0427128>] (cpufreq_set) from [<c0423948>] (store_scaling_setspeed+0x5c/0x74)
      [ 5928.360407] [<c0423948>] (store_scaling_setspeed) from [<c04238d0>] (store+0x7c/0x98)
      [ 5928.368221] [<c04238d0>] (store) from [<c0132540>] (sysfs_kf_write+0x44/0x48)
      [ 5928.375338] [<c0132540>] (sysfs_kf_write) from [<c0131b9c>] (kernfs_fop_write+0xb8/0x1bc)
      [ 5928.383496] [<c0131b9c>] (kernfs_fop_write) from [<c00d71f8>] (__vfs_write+0x2c/0xd4)
      [ 5928.391308] [<c00d71f8>] (__vfs_write) from [<c00d7de8>] (vfs_write+0xa0/0x144)
      [ 5928.398598] [<c00d7de8>] (vfs_write) from [<c00d8048>] (SyS_write+0x44/0x84)
      [ 5928.405631] [<c00d8048>] (SyS_write) from [<c000f540>] (ret_fast_syscall+0x0/0x3c)
      Signed-off-by: default avatarMarek Szyprowski <m.szyprowski@samsung.com>
      Signed-off-by: default avatarSylwester Nawrocki <s.nawrocki@samsung.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7ca59689
    • Andrew Donnellan's avatar
      cxl: use correct operator when writing pcie config space values · e3d4bcc3
      Andrew Donnellan authored
      commit 48f0f6b7 upstream.
      
      When writing a value to config space, cxl_pcie_write_config() calls
      cxl_pcie_config_info() to obtain a mask and shift value, shifts the new
      value accordingly, then uses the mask to combine the shifted value with the
      existing value at the address as part of a read-modify-write pattern.
      
      Currently, we use a logical OR operator rather than a bitwise OR operator,
      which means any use of this function results in an incorrect value being
      written. Replace the logical OR operator with a bitwise OR operator so the
      value is written correctly.
      Reported-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Fixes: 6f7f0b3d ("cxl: Add AFU virtual PHB and kernel API")
      Signed-off-by: default avatarAndrew Donnellan <andrew.donnellan@au1.ibm.com>
      Acked-by: default avatarIan Munsie <imunsie@au1.ibm.com>
      Signed-off-by: default avatarMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e3d4bcc3
    • Dmitry V. Levin's avatar
      sparc64: fix incorrect sign extension in sys_sparc64_personality · a0b1c2d0
      Dmitry V. Levin authored
      commit 525fd5a9 upstream.
      
      The value returned by sys_personality has type "long int".
      It is saved to a variable of type "int", which is not a problem
      yet because the type of task_struct->pesonality is "unsigned int".
      The problem is the sign extension from "int" to "long int"
      that happens on return from sys_sparc64_personality.
      
      For example, a userspace call personality((unsigned) -EINVAL) will
      result to any subsequent personality call, including absolutely
      harmless read-only personality(0xffffffff) call, failing with
      errno set to EINVAL.
      Signed-off-by: default avatarDmitry V. Levin <ldv@altlinux.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a0b1c2d0
    • Borislav Petkov's avatar
      EDAC, mc_sysfs: Fix freeing bus' name · b49777c6
      Borislav Petkov authored
      commit 12e26969 upstream.
      
      I get the splat below when modprobing/rmmoding EDAC drivers. It happens
      because bus->name is invalid after bus_unregister() has run. The Code: section
      below corresponds to:
      
        .loc 1 1108 0
        movq    672(%rbx), %rax # mci_1(D)->bus, mci_1(D)->bus
        .loc 1 1109 0
        popq    %rbx    #
      
        .loc 1 1108 0
        movq    (%rax), %rdi    # _7->name,
        jmp     kfree   #
      
      and %rax has some funky stuff 2030203020312030 which looks a lot like
      something walked over it.
      
      Fix that by saving the name ptr before doing stuff to string it points to.
      
        general protection fault: 0000 [#1] SMP
        Modules linked in: ...
        CPU: 4 PID: 10318 Comm: modprobe Tainted: G          I EN  3.12.51-11-default+ #48
        Hardware name: HP ProLiant DL380 G7, BIOS P67 05/05/2011
        task: ffff880311320280 ti: ffff88030da3e000 task.ti: ffff88030da3e000
        RIP: 0010:[<ffffffffa019da92>]  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
        RSP: 0018:ffff88030da3fe28  EFLAGS: 00010292
        RAX: 2030203020312030 RBX: ffff880311b4e000 RCX: 000000000000095c
        RDX: 0000000000000001 RSI: ffff880327bb9600 RDI: 0000000000000286
        RBP: ffff880311b4e750 R08: 0000000000000000 R09: ffffffff81296110
        R10: 0000000000000400 R11: 0000000000000000 R12: ffff88030ba1ac68
        R13: 0000000000000001 R14: 00000000011b02f0 R15: 0000000000000000
        FS:  00007fc9bf8f5700(0000) GS:ffff8801a7c40000(0000) knlGS:0000000000000000
        CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
        CR2: 0000000000403c90 CR3: 000000019ebdf000 CR4: 00000000000007e0
        Stack:
        Call Trace:
          i7core_unregister_mci.isra.9
          i7core_remove
          pci_device_remove
          __device_release_driver
          driver_detach
          bus_remove_driver
          pci_unregister_driver
          i7core_exit
          SyS_delete_module
          system_call_fastpath
          0x7fc9bf426536
        Code: 2e 0f 1f 84 00 00 00 00 00 66 66 66 66 90 53 48 89 fb e8 52 2a 1f e1 48 8b bb a0 02 00 00 e8 46 59 1f e1 48 8b 83 a0 02 00 00 5b <48> 8b 38 e9 26 9a fe e0 66 0f 1f 44 00 00 66 66 66 66 90 48 8b
        RIP  [<ffffffffa019da92>] edac_unregister_sysfs+0x22/0x30 [edac_core]
         RSP <ffff88030da3fe28>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
      Fixes: 7a623c03 ("edac: rewrite the sysfs code to use struct device")
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b49777c6
    • Borislav Petkov's avatar
      EDAC: Robustify workqueues destruction · de46e654
      Borislav Petkov authored
      commit fcd5c4dd upstream.
      
      EDAC workqueue destruction is really fragile. We cancel delayed work
      but if it is still running and requeues itself, we still go ahead and
      destroy the workqueue and the queued work explodes when workqueue core
      attempts to run it.
      
      Make the destruction more robust by switching op_state to offline so
      that requeuing stops. Cancel any pending work *synchronously* too.
      
        EDAC i7core: Driver loaded.
        general protection fault: 0000 [#1] SMP
        CPU 12
        Modules linked in:
        Supported: Yes
        Pid: 0, comm: kworker/0:1 Tainted: G          IE   3.0.101-0-default #1 HP ProLiant DL380 G7
        RIP: 0010:[<ffffffff8107dcd7>]  [<ffffffff8107dcd7>] __queue_work+0x17/0x3f0
        < ... regs ...>
        Process kworker/0:1 (pid: 0, threadinfo ffff88019def6000, task ffff88019def4600)
        Stack:
         ...
        Call Trace:
         call_timer_fn
         run_timer_softirq
         __do_softirq
         call_softirq
         do_softirq
         irq_exit
         smp_apic_timer_interrupt
         apic_timer_interrupt
         intel_idle
         cpuidle_idle_call
         cpu_idle
        Code: ...
        RIP  __queue_work
         RSP <...>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      de46e654
    • James Hogan's avatar
      MIPS: Fix buffer overflow in syscall_get_arguments() · a869e6b0
      James Hogan authored
      commit f4dce1ff upstream.
      
      Since commit 4c21b8fd ("MIPS: seccomp: Handle indirect system calls
      (o32)"), syscall_get_arguments() attempts to handle o32 indirect syscall
      arguments by incrementing both the start argument number and the number
      of arguments to fetch. However only the start argument number needs to
      be incremented. The number of arguments does not change, they're just
      shifted up by one, and in fact the output array is provided by the
      caller and is likely only n entries long, so reading more arguments
      overflows the output buffer.
      
      In the case of seccomp, this results in it fetching 7 arguments starting
      at the 2nd one, which overflows the unsigned long args[6] in
      populate_seccomp_data(). This clobbers the $s0 register from
      syscall_trace_enter() which __seccomp_phase1_filter() saved onto the
      stack, into which syscall_trace_enter() had placed its syscall number
      argument. This caused Chromium to crash.
      
      Credit goes to Milko for tracking it down as far as $s0 being clobbered.
      
      Fixes: 4c21b8fd ("MIPS: seccomp: Handle indirect system calls (o32)")
      Reported-by: default avatarMilko Leporis <milko.leporis@imgtec.com>
      Signed-off-by: default avatarJames Hogan <james.hogan@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/12213/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      a869e6b0
    • Huacai Chen's avatar
      MIPS: Fix some missing CONFIG_CPU_MIPSR6 #ifdefs · dbdb0333
      Huacai Chen authored
      commit 4f33f6c5 upstream.
      
      Commit be0c37c9 (MIPS: Rearrange PTE bits into fixed positions.)
      defines fixed PTE bits for MIPS R2. Then, commit d7b63141
      (MIPS: pgtable-bits: Fix XPA damage to R6 definitions.) adds the MIPS
      R6 definitions in the same way as MIPS R2. But some R6 #ifdefs in the
      later commit are missing, so in this patch I fix that.
      Signed-off-by: default avatarHuacai Chen <chenhc@lemote.com>
      Cc: Aurelien Jarno <aurelien@aurel32.net>
      Cc: Steven J. Hill <Steven.Hill@imgtec.com>
      Cc: Fuxin Zhang <zhangfx@lemote.com>
      Cc: Zhangjin Wu <wuzhangjin@gmail.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/12164/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dbdb0333
    • Huacai Chen's avatar
      MIPS: hpet: Choose a safe value for the ETIME check · e76f1004
      Huacai Chen authored
      commit 5610b125 upstream.
      
      This patch is borrowed from x86 hpet driver and explaind below:
      
      Due to the overly intelligent design of HPETs, we need to workaround
      the problem that the compare value which we write is already behind
      the actual counter value at the point where the value hits the real
      compare register. This happens for two reasons:
      
      1) We read out the counter, add the delta and write the result to the
         compare register. When a NMI hits between the read out and the write
         then the counter can be ahead of the event already.
      
      2) The write to the compare register is delayed by up to two HPET
         cycles in AMD chipsets.
      
      We can work around this by reading back the compare register to make
      sure that the written value has hit the hardware. But that is bad
      performance wise for the normal case where the event is far enough in
      the future.
      
      As we already know that the write can be delayed by up to two cycles
      we can avoid the read back of the compare register completely if we
      make the decision whether the delta has elapsed already or not based
      on the following calculation:
      
        cmp = event - actual_count;
      
      If cmp is less than 64 HPET clock cycles, then we decide that the event
      has happened already and return -ETIME. That covers the above #1 and #2
      problems which would cause a wait for HPET wraparound (~306 seconds).
      Signed-off-by: default avatarHuacai Chen <chenhc@lemote.com>
      Cc: Aurelien Jarno <aurelien@aurel32.net>
      Cc: Steven J. Hill <Steven.Hill@imgtec.com>
      Cc: Fuxin Zhang <zhangfx@lemote.com>
      Cc: Zhangjin Wu <wuzhangjin@gmail.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/12162/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      e76f1004
    • Huacai Chen's avatar
      MIPS: Loongson-3: Fix SMP_ASK_C0COUNT IPI handler · 332e40db
      Huacai Chen authored
      commit 57548432 upstream.
      
      When Core-0 handle SMP_ASK_C0COUNT IPI, we should make other cores to
      see the result as soon as possible (especially when Store-Fill-Buffer
      is enabled). Otherwise, C0_Count syncronization makes no sense.
      
      BTW, array is more suitable than per-cpu variable for syncronization,
      and there is a corner case should be avoid: C0_Count of Core-0 can be
      really 0.
      Signed-off-by: default avatarHuacai Chen <chenhc@lemote.com>
      Cc: Aurelien Jarno <aurelien@aurel32.net>
      Cc: Steven J. Hill <Steven.Hill@imgtec.com>
      Cc: Fuxin Zhang <zhangfx@lemote.com>
      Cc: Zhangjin Wu <wuzhangjin@gmail.com>
      Cc: Huacai Chen <chenhc@lemote.com>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/12160/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      332e40db
    • Dan Williams's avatar
      Revert "MIPS: Fix PAGE_MASK definition" · 97ff5367
      Dan Williams authored
      commit 800dc4f4 upstream.
      
      This reverts commit 22b14523.
      
      It was originally sent in an earlier revision of the pfn_t patchset.
      Besides being broken, the warning is also fixed by PFN_FLAGS_MASK
      casting the PAGE_MASK to an unsigned long.
      Reported-by: default avatarManuel Lauss <manuel.lauss@gmail.com>
      Signed-off-by: default avatarDan Williams <dan.j.williams@intel.com>
      Cc: linux-kernel@vger.kernel.org
      Cc: Linux-MIPS <linux-mips@linux-mips.org>
      Patchwork: https://patchwork.linux-mips.org/patch/12182/Signed-off-by: default avatarRalf Baechle <ralf@linux-mips.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      97ff5367
    • zengtao's avatar
      cputime: Prevent 32bit overflow in time[val|spec]_to_cputime() · 242e16cd
      zengtao authored
      commit 0f26922f upstream.
      
      The datatype __kernel_time_t is u32 on 32bit platform, so its subject to
      overflows in the timeval/timespec to cputime conversion.
      
      Currently the following functions are affected:
      1. setitimer()
      2. timer_create/timer_settime()
      3. sys_clock_nanosleep
      
      This can happen on MIPS32 and ARM32 with "Full dynticks CPU time accounting"
      enabled, which is required for CONFIG_NO_HZ_FULL.
      
      Enforce u64 conversion to prevent the overflow.
      
      Fixes: 31c1fc81 ("ARM: Kconfig: allow full nohz CPU accounting")
      Signed-off-by: default avatarzengtao <prime.zeng@huawei.com>
      Reviewed-by: default avatarArnd Bergmann <arnd@arndb.de>
      Cc: <fweisbec@gmail.com>
      Link: http://lkml.kernel.org/r/1454384314-154784-1-git-send-email-prime.zeng@huawei.comSigned-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      242e16cd
    • David Gibson's avatar
      time: Avoid signed overflow in timekeeping_get_ns() · 972e9e3c
      David Gibson authored
      commit 35a4933a upstream.
      
      1e75fa8b "time: Condense timekeeper.xtime into xtime_sec" replaced a call to
      clocksource_cyc2ns() from timekeeping_get_ns() with an open-coded version
      of the same logic to avoid keeping a semi-redundant struct timespec
      in struct timekeeper.
      
      However, the commit also introduced a subtle semantic change - where
      clocksource_cyc2ns() uses purely unsigned math, the new version introduces
      a signed temporary, meaning that if (delta * tk->mult) has a 63-bit
      overflow the following shift will still give a negative result.  The
      choice of 'maxsec' in __clocksource_updatefreq_scale() means this will
      generally happen if there's a ~10 minute pause in examining the
      clocksource.
      
      This can be triggered on a powerpc KVM guest by stopping it from qemu for
      a bit over 10 minutes.  After resuming time has jumped backwards several
      minutes causing numerous problems (jiffies does not advance, msleep()s can
      be extended by minutes..).  It doesn't happen on x86 KVM guests, because
      the guest TSC is effectively frozen while the guest is stopped, which is
      not the case for the powerpc timebase.
      
      Obviously an unsigned (64 bit) overflow will only take twice as long as a
      signed, 63-bit overflow.  I don't know the time code well enough to know
      if that will still cause incorrect calculations, or if a 64-bit overflow
      is avoided elsewhere.
      
      Still, an incorrect forwards clock adjustment will cause less trouble than
      time going backwards.  So, this patch removes the potential for
      intermediate signed overflow.
      Suggested-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Tested-by: default avatarLaurent Vivier <lvivier@redhat.com>
      Signed-off-by: default avatarDavid Gibson <david@gibson.dropbear.id.au>
      Signed-off-by: default avatarJohn Stultz <john.stultz@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      972e9e3c
    • Lukasz Duda's avatar
      Bluetooth: 6lowpan: Fix handling of uncompressed IPv6 packets · 8cf0f282
      Lukasz Duda authored
      commit 87f5fedb upstream.
      
      This patch fixes incorrect handling of the 6lowpan packets that contain
      uncompressed IPv6 header.
      
      RFC4944 specifies a special dispatch for 6lowpan to carry uncompressed
      IPv6 header. This dispatch (1 byte long) has to be removed during
      reception and skb data pointer has to be moved. To correctly point in
      the beginning of the IPv6 header the dispatch byte has to be pulled off
      before packet can be processed by netif_rx_in().
      
      Test scenario: IPv6 packets are not correctly interpreted by the network
      layer when IPv6 header is not compressed (e.g. ICMPv6 Echo Reply is not
      propagated correctly to the ICMPv6 layer because the extra byte will make
      the header look corrupted).
      
      Similar approach is done for IEEE 802.15.4.
      Signed-off-by: default avatarLukasz Duda <lukasz.duda@nordicsemi.no>
      Signed-off-by: default avatarGlenn Ruben Bakke <glenn.ruben.bakke@nordicsemi.no>
      Acked-by: default avatarJukka Rissanen <jukka.rissanen@linux.intel.com>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8cf0f282
    • Glenn Ruben Bakke's avatar
      Bluetooth: 6lowpan: Fix kernel NULL pointer dereferences · cf5d2ff4
      Glenn Ruben Bakke authored
      commit 4c58f328 upstream.
      
      The fixes provided in this patch assigns a valid net_device structure to
      skb before dispatching it for further processing.
      
      Scenario #1:
      ============
      
      Bluetooth 6lowpan receives an uncompressed IPv6 header, and dispatches it
      to netif. The following error occurs:
      
      Null pointer dereference error #1 crash log:
      
      [  845.854013] BUG: unable to handle kernel NULL pointer dereference at
                     0000000000000048
      [  845.855785] IP: [<ffffffff816e3d36>] enqueue_to_backlog+0x56/0x240
      ...
      [  845.909459] Call Trace:
      [  845.911678]  [<ffffffff816e3f64>] netif_rx_internal+0x44/0xf0
      
      The first modification fixes the NULL pointer dereference error by
      assigning dev to the local_skb in order to set a valid net_device before
      processing the skb by netif_rx_ni().
      
      Scenario #2:
      ============
      
      Bluetooth 6lowpan receives an UDP compressed message which needs further
      decompression by nhc_udp. The following error occurs:
      
      Null pointer dereference error #2 crash log:
      
      [   63.295149] BUG: unable to handle kernel NULL pointer dereference at
                     0000000000000840
      [   63.295931] IP: [<ffffffffc0559540>] udp_uncompress+0x320/0x626
                     [nhc_udp]
      
      The second modification fixes the NULL pointer dereference error by
      assigning dev to the local_skb in the case of a udp compressed packet.
      The 6lowpan udp_uncompress function expects that the net_device is set in
      the skb when checking lltype.
      Signed-off-by: default avatarGlenn Ruben Bakke <glenn.ruben.bakke@nordicsemi.no>
      Signed-off-by: default avatarLukasz Duda <lukasz.duda@nordicsemi.no>
      Acked-by: default avatarJukka Rissanen <jukka.rissanen@linux.intel.com>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      cf5d2ff4
    • Johan Hedberg's avatar
      Bluetooth: Fix incorrect removing of IRKs · 701495c1
      Johan Hedberg authored
      commit cff10ce7 upstream.
      
      The commit cad20c27 was supposed to
      fix handling of devices first using public addresses and then
      switching to RPAs after pairing. Unfortunately it missed a couple of
      key places in the code.
      
      1. When evaluating which devices should be removed from the existing
      white list we also need to consider whether we have an IRK for them or
      not, i.e. a call to hci_find_irk_by_addr() is needed.
      
      2. In smp_notify_keys() we should not be requiring the knowledge of
      the RPA, but should simply keep the IRK around if the other conditions
      require it.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      701495c1
    • Dmitry Tunin's avatar
      Bluetooth: Add support of Toshiba Broadcom based devices · 2b2b55a0
      Dmitry Tunin authored
      commit 1623d0bf upstream.
      
      BugLink: https://bugs.launchpad.net/bugs/1522949
      
          T: Bus=03 Lev=02 Prnt=02 Port=05 Cnt=02 Dev#= 4 Spd=12 MxCh= 0
          D: Ver= 2.00 Cls=ff(vend.) Sub=01 Prot=01 MxPS=64 #Cfgs= 1
          P: Vendor=0930 ProdID=0225 Rev=01.12
          S: Manufacturer=Broadcom Corp
          S: Product=BCM43142A0
          S: SerialNumber=4CBB58034671
          C: #Ifs= 4 Cfg#= 1 Atr=e0 MxPwr=0mA
          I: If#= 0 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
          I: If#= 1 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=01 Prot=01 Driver=(none)
          I: If#= 2 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
          I: If#= 3 Alt= 0 #EPs= 0 Cls=fe(app. ) Sub=01 Prot=01 Driver=(none)
      Signed-off-by: default avatarDmitry Tunin <hanipouspilot@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2b2b55a0
    • Johan Hedberg's avatar
      Bluetooth: Use continuous scanning when creating LE connections · c76633bf
      Johan Hedberg authored
      commit 2f99536a upstream.
      
      All LE connections are now triggered through a preceding passive scan
      and waiting for a connectable advertising report. This means we've got
      the best possible guarantee that the device is within range and should
      be able to request the controller to perform continuous scanning. This
      way we minimize the risk that we miss out on any advertising packets.
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      c76633bf
    • K. Y. Srinivasan's avatar
      Drivers: hv: vmbus: Fix a Host signaling bug · 2a383bcc
      K. Y. Srinivasan authored
      commit 8599846d upstream.
      
      Currently we have two policies for deciding when to signal the host:
      One based on the ring buffer state and the other based on what the
      VMBUS client driver wants to do. Consider the case when the client
      wants to explicitly control when to signal the host. In this case,
      if the client were to defer signaling, we will not be able to signal
      the host subsequently when the client does want to signal since the
      ring buffer state will prevent the signaling. Implement logic to
      have only one signaling policy in force for a given channel.
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Reviewed-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Tested-by: default avatarHaiyang Zhang <haiyangz@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2a383bcc
    • Dexuan Cui's avatar
      tools: hv: vss: fix the write()'s argument: error -> vss_msg · 7db755f5
      Dexuan Cui authored
      commit a689d251 upstream.
      
      Fix the write()'s argument in the daemon code.
      
      Cc: Vitaly Kuznetsov <vkuznets@redhat.com>
      Cc: "K. Y. Srinivasan" <kys@microsoft.com>
      Signed-off-by: default avatarDexuan Cui <decui@microsoft.com>
      Signed-off-by: default avatarK. Y. Srinivasan <kys@microsoft.com>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      7db755f5
    • Adrian Hunter's avatar
      mmc: sdhci: Allow override of get_cd() called from sdhci_request() · 61b9408b
      Adrian Hunter authored
      commit 8d28b7a7 upstream.
      
      Drivers may need to provide their own get_cd() mmc host op, but
      currently the internals of the current op (sdhci_get_cd()) are
      provided by sdhci_do_get_cd() which is also called from
      sdhci_request().
      
      To allow override of the get_cd functionality, change sdhci_request()
      to call ->get_cd() instead of sdhci_do_get_cd().
      
      Note, in the future the call to ->get_cd() will likely be removed
      from sdhci_request() since most drivers don't need actually it.
      However this change is being done now to facilitate a subsequent
      bug fix.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      61b9408b
    • Adrian Hunter's avatar
      mmc: sdhci: Allow override of mmc host operations · bafb7142
      Adrian Hunter authored
      commit bf60e592 upstream.
      
      In the past, fixes for specific hardware devices were implemented
      in sdhci using quirks.  That approach is no longer accepted because
      the growing number of quirks was starting to make the code difficult
      to understand and maintain.
      
      One alternative to quirks, is to allow drivers to override the default
      mmc host operations.  This patch makes it easy to do that, and it is
      needed for a subsequent bug fix, for which separate patches are
      provided.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      bafb7142
    • Adrian Hunter's avatar
      mmc: sdhci-pci: Fix card detect race for Intel BXT/APL · dfca1918
      Adrian Hunter authored
      commit 163cbe31 upstream.
      
      Intel BXT/APL use a card detect GPIO however the host controller
      will not enable bus power unless it's card detect also reflects
      the presence of a card.  Unfortunately those 2 things race which
      can result in commands not starting, after which the controller
      does nothing and there is a 10 second wait for the driver's
      10-second timer to timeout.
      
      That is fixed by having the driver look also at the present state
      register to determine if the card is present.  Consequently, provide
      a 'get_cd' mmc host operation for BXT/APL that does that.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      dfca1918
    • Robert Jarzmik's avatar
      mmc: pxamci: fix again read-only gpio detection polarity · b7f7a5e2
      Robert Jarzmik authored
      commit 41c89159 upstream.
      
      The commit fixing the conversion of pxamci to slot-gpio API fixed the
      inverted the logic of the read-only gpio. Unfortunately, the commit was
      tested on a non-inverted gpio, and not on the inverted one. And the fix
      did work partially, by luck.
      
      This is the remaining missing part of the fix, trivial but still necessary.
      
      Fixes: Fixes: 26d49fe7 ("mmc: pxamci: fix read-only gpio detection polarity")
      Reported-by: default avatarAndrea Adami <andrea.adami@gmail.com>
      Tested-by: default avatarAndrea Adami <andrea.adami@gmail.com>
      Signed-off-by: default avatarRobert Jarzmik <robert.jarzmik@free.fr>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      b7f7a5e2
    • Adrian Hunter's avatar
      mmc: sdhci-acpi: Fix card detect race for Intel BXT/APL · 43919d0c
      Adrian Hunter authored
      commit 6a645dd8 upstream.
      
      Intel BXT/APL use a card detect GPIO however the host controller
      will not enable bus power unless it's card detect also reflects
      the presence of a card.  Unfortunately those 2 things race which
      can result in commands not starting, after which the controller
      does nothing and there is a 10 second wait for the driver's
      10-second timer to timeout.
      
      That is fixed by having the driver look also at the present state
      register to determine if the card is present.  Consequently, provide
      a 'get_cd' mmc host operation for BXT/APL that does that.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      43919d0c
    • Linus Walleij's avatar
      mmc: mmci: fix an ages old detection error · 2bfda888
      Linus Walleij authored
      commit 0bcb7efd upstream.
      
      commit 4956e109 ("ARM: 6244/1: mmci: add variant data and default
      MCICLOCK support") added variant data for ARM, U300 and Ux500 variants.
      The Nomadik NHK8815/8820 variant was erroneously labeled as a U300
      variant, and when the proper Nomadik variant was later introduced in
      commit 34fd4213 ("ARM: 7378/1: mmci: add support for the Nomadik MMCI
      variant") this was not fixes. Let's say this fixes the latter commit as
      there was no proper Nomadik support until then.
      
      Fixes: 34fd4213 ("ARM: 7378/1: mmci: add support for the Nomadik...")
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      2bfda888
    • Carlo Caione's avatar
      mmc: core: Enable tuning according to the actual timing · 3cafb70c
      Carlo Caione authored
      commit e10c3219 upstream.
      
      While in sdhci_execute_tuning() the choice whether or not to enable the
      tuning is done on the actual timing, in the mmc_sdio_init_uhs_card() the
      check is done on the capability of the card.
      
      This difference is causing some issues with some SDIO cards in DDR50
      mode where the CDM19 is wrongly issued.
      
      With this patch we modify the check in both
      mmc_(sd|sdio)_init_uhs_card() functions to take the proper decision
      only according to the actual timing specification.
      Signed-off-by: default avatarCarlo Caione <carlo@endlessm.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      3cafb70c
    • Adrian Hunter's avatar
      mmc: sdhci: Fix sdhci_runtime_pm_bus_on/off() · fca2d31d
      Adrian Hunter authored
      commit 5c671c41 upstream.
      
      sdhci has a legacy facility to prevent runtime suspend if the
      bus power is on.  This is needed in cases where the power to
      the card is dependent on the bus power.  It is controlled by
      a pair of functions: sdhci_runtime_pm_bus_on() and
      sdhci_runtime_pm_bus_off().  These functions use a boolean
      variable 'bus_on' to ensure changes are always paired.
      There is an additional check for 'runtime_suspended' which is
      the problem.  In fact, its use is ill-conceived as the only
      requirement for the logic is that 'on' and 'off' are paired,
      which is actually broken by the check, for example if the bus
      power is turned on during runtime resume.  So remove  the check.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      fca2d31d
    • Wenkai Du's avatar
      mmc: mmc: Fix incorrect use of driver strength switching HS200 and HS400 · 6eec26b7
      Wenkai Du authored
      commit adb24d42 upstream.
      
      Commit cc4f414c ("mmc: mmc: Add driver strength selection")
      added driver strength selection for eMMC HS200 and HS400 modes.
      That patch also set the driver stength when transitioning through
      High Speed mode to HS200/HS400, but driver strength is not defined
      for High Speed mode.  While the JEDEC specification is not clear
      on this point it has been observed to cause problems for some eMMC,
      and removing the driver strength setting in this case makes it
      consistent with the normal use of High Speed mode.
      Signed-off-by: default avatarWenkai Du <wenkai.du@intel.com>
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      6eec26b7
    • Adrian Hunter's avatar
      mmc: sdio: Fix invalid vdd in voltage switch power cycle · 8ae7192d
      Adrian Hunter authored
      commit d9bfbb95 upstream.
      
      The 'ocr' parameter passed to mmc_set_signal_voltage()
      defines the power-on voltage used when power cycling
      after a failure to set the voltage.  However, in the
      case of mmc_sdio_init_card(), the value passed has the
      R4_18V_PRESENT flag set which is not valid for power-on
      and results in an invalid vdd.  Fix by passing the card's
      ocr value which does not have the flag.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      8ae7192d
    • Adrian Hunter's avatar
      mmc: sdhci: Fix DMA descriptor with zero data length · 14772905
      Adrian Hunter authored
      commit 347ea32d upstream.
      
      SDHCI has built-in DMA called ADMA2.  ADMA2 uses a descriptor
      table to define DMA scatter-gather.  Each desciptor can specify
      a data length up to 65536 bytes, however the length field is
      only 16-bits so zero means 65536.  Consequently, putting zero
      when the size is zero must not be allowed.  This patch fixes
      one case where zero data length could be set inadvertently.
      
      The problem happens because unaligned data gets split and the
      code did not consider that the remaining aligned portion might
      be zero length.  That case really only happens for SDIO because
      SD and eMMC cards transfer blocks that are invariably sector-
      aligned.  For SDIO, access to function registers is done by
      data transfer (CMD53) when the register is bigger than 1 byte.
      Generally registers are 4 bytes but 2-byte registers are possible.
      So DMA of 4 bytes or less can happen.  When 32-bit DMA is used,
      the data alignment must be 4, so 4-byte transfers won't casue a
      problem, but a 2-byte transfer could.  However with the introduction
      of 64-bit DMA, the data alignment for 64-bit DMA was made 8 bytes,
      so all 4-byte transfers not on 8-byte boundaries get "split" into
      a 4-byte chunk and a 0-byte chunk, thereby hitting the bug.
      
      In fact, a closer look at the SDHCI specs indicates that only the
      descriptor table requires 8-byte alignment for 64-bit DMA.  That
      will be dealt with in a separate patch, but the potential for a
      2-byte access remains, so this fix is needed anyway.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      14772905
    • Adrian Hunter's avatar
      mmc: sdhci-pci: Do not default to 33 Ohm driver strength for Intel SPT · 4a3d7e16
      Adrian Hunter authored
      commit 1ca89685 upstream.
      
      In some cases, the stronger 33 Ohm driver strength must not be used
      so it is not a suitable default.  Change it to the standard default
      50 Ohm value.
      
      The patch applies to v4.2+ except the file name changed.  It is
      drivers/mmc/host/sdhci-pci.c prior to v.4.4.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Signed-off-by: default avatarUlf Hansson <ulf.hansson@linaro.org>
      Signed-off-by: default avatarGreg Kroah-Hartman <gregkh@linuxfoundation.org>
      4a3d7e16