1. 10 Jul, 2019 40 commits
    • swkhack's avatar
      mm/mlock.c: change count_mm_mlocked_page_nr return type · 12006942
      swkhack authored
      [ Upstream commit 0874bb49 ]
      
      On a 64-bit machine the value of "vma->vm_end - vma->vm_start" may be
      negative when using 32 bit ints and the "count >> PAGE_SHIFT"'s result
      will be wrong.  So change the local variable and return value to
      unsigned long to fix the problem.
      
      Link: http://lkml.kernel.org/r/20190513023701.83056-1-swkhack@gmail.com
      Fixes: 0cf2f6f6 ("mm: mlock: check against vma for actual mlock() size")
      Signed-off-by: default avatarswkhack <swkhack@gmail.com>
      Acked-by: default avatarMichal Hocko <mhocko@suse.com>
      Reviewed-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      12006942
    • Manuel Traut's avatar
      scripts/decode_stacktrace.sh: prefix addr2line with $CROSS_COMPILE · 80d567f7
      Manuel Traut authored
      [ Upstream commit c04e32e9 ]
      
      At least for ARM64 kernels compiled with the crosstoolchain from
      Debian/stretch or with the toolchain from kernel.org the line number is
      not decoded correctly by 'decode_stacktrace.sh':
      
        $ echo "[  136.513051]  f1+0x0/0xc [kcrash]" | \
          CROSS_COMPILE=/opt/gcc-8.1.0-nolibc/aarch64-linux/bin/aarch64-linux- \
         ./scripts/decode_stacktrace.sh /scratch/linux-arm64/vmlinux \
                                        /scratch/linux-arm64 \
                                        /nfs/debian/lib/modules/4.20.0-devel
        [  136.513051] f1 (/linux/drivers/staging/kcrash/kcrash.c:68) kcrash
      
      If addr2line from the toolchain is used the decoded line number is correct:
      
        [  136.513051] f1 (/linux/drivers/staging/kcrash/kcrash.c:57) kcrash
      
      Link: http://lkml.kernel.org/r/20190527083425.3763-1-manut@linutronix.deSigned-off-by: default avatarManuel Traut <manut@linutronix.de>
      Acked-by: default avatarKonstantin Khlebnikov <khlebnikov@yandex-team.ru>
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarLinus Torvalds <torvalds@linux-foundation.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      80d567f7
    • Joel Savitz's avatar
      cpuset: restore sanity to cpuset_cpus_allowed_fallback() · 8f4b554b
      Joel Savitz authored
      [ Upstream commit d477f8c2 ]
      
      In the case that a process is constrained by taskset(1) (i.e.
      sched_setaffinity(2)) to a subset of available cpus, and all of those are
      subsequently offlined, the scheduler will set tsk->cpus_allowed to
      the current value of task_cs(tsk)->effective_cpus.
      
      This is done via a call to do_set_cpus_allowed() in the context of
      cpuset_cpus_allowed_fallback() made by the scheduler when this case is
      detected. This is the only call made to cpuset_cpus_allowed_fallback()
      in the latest mainline kernel.
      
      However, this is not sane behavior.
      
      I will demonstrate this on a system running the latest upstream kernel
      with the following initial configuration:
      
      	# grep -i cpu /proc/$$/status
      	Cpus_allowed:	ffffffff,fffffff
      	Cpus_allowed_list:	0-63
      
      (Where cpus 32-63 are provided via smt.)
      
      If we limit our current shell process to cpu2 only and then offline it
      and reonline it:
      
      	# taskset -p 4 $$
      	pid 2272's current affinity mask: ffffffffffffffff
      	pid 2272's new affinity mask: 4
      
      	# echo off > /sys/devices/system/cpu/cpu2/online
      	# dmesg | tail -3
      	[ 2195.866089] process 2272 (bash) no longer affine to cpu2
      	[ 2195.872700] IRQ 114: no longer affine to CPU2
      	[ 2195.879128] smpboot: CPU 2 is now offline
      
      	# echo on > /sys/devices/system/cpu/cpu2/online
      	# dmesg | tail -1
      	[ 2617.043572] smpboot: Booting Node 0 Processor 2 APIC 0x4
      
      We see that our current process now has an affinity mask containing
      every cpu available on the system _except_ the one we originally
      constrained it to:
      
      	# grep -i cpu /proc/$$/status
      	Cpus_allowed:   ffffffff,fffffffb
      	Cpus_allowed_list:      0-1,3-63
      
      This is not sane behavior, as the scheduler can now not only place the
      process on previously forbidden cpus, it can't even schedule it on
      the cpu it was originally constrained to!
      
      Other cases result in even more exotic affinity masks. Take for instance
      a process with an affinity mask containing only cpus provided by smt at
      the moment that smt is toggled, in a configuration such as the following:
      
      	# taskset -p f000000000 $$
      	# grep -i cpu /proc/$$/status
      	Cpus_allowed:	000000f0,00000000
      	Cpus_allowed_list:	36-39
      
      A double toggle of smt results in the following behavior:
      
      	# echo off > /sys/devices/system/cpu/smt/control
      	# echo on > /sys/devices/system/cpu/smt/control
      	# grep -i cpus /proc/$$/status
      	Cpus_allowed:	ffffff00,ffffffff
      	Cpus_allowed_list:	0-31,40-63
      
      This is even less sane than the previous case, as the new affinity mask
      excludes all smt-provided cpus with ids less than those that were
      previously in the affinity mask, as well as those that were actually in
      the mask.
      
      With this patch applied, both of these cases end in the following state:
      
      	# grep -i cpu /proc/$$/status
      	Cpus_allowed:	ffffffff,ffffffff
      	Cpus_allowed_list:	0-63
      
      The original policy is discarded. Though not ideal, it is the simplest way
      to restore sanity to this fallback case without reinventing the cpuset
      wheel that rolls down the kernel just fine in cgroup v2. A user who wishes
      for the previous affinity mask to be restored in this fallback case can use
      that mechanism instead.
      
      This patch modifies scheduler behavior by instead resetting the mask to
      task_cs(tsk)->cpus_allowed by default, and cpu_possible mask in legacy
      mode. I tested the cases above on both modes.
      
      Note that the scheduler uses this fallback mechanism if and only if
      _every_ other valid avenue has been traveled, and it is the last resort
      before calling BUG().
      Suggested-by: default avatarWaiman Long <longman@redhat.com>
      Suggested-by: default avatarPhil Auld <pauld@redhat.com>
      Signed-off-by: default avatarJoel Savitz <jsavitz@redhat.com>
      Acked-by: default avatarPhil Auld <pauld@redhat.com>
      Acked-by: default avatarWaiman Long <longman@redhat.com>
      Acked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Signed-off-by: default avatarTejun Heo <tj@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      8f4b554b
    • Will Deacon's avatar
      arm64: tlbflush: Ensure start/end of address range are aligned to stride · e2beb74a
      Will Deacon authored
      [ Upstream commit 01d57485 ]
      
      Since commit 3d65b6bb ("arm64: tlbi: Set MAX_TLBI_OPS to
      PTRS_PER_PTE"), we resort to per-ASID invalidation when attempting to
      perform more than PTRS_PER_PTE invalidation instructions in a single
      call to __flush_tlb_range(). Whilst this is beneficial, the mmu_gather
      code does not ensure that the end address of the range is rounded-up
      to the stride when freeing intermediate page tables in pXX_free_tlb(),
      which defeats our range checking.
      
      Align the bounds passed into __flush_tlb_range().
      
      Cc: Catalin Marinas <catalin.marinas@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Reported-by: default avatarHanjun Guo <guohanjun@huawei.com>
      Tested-by: default avatarHanjun Guo <guohanjun@huawei.com>
      Reviewed-by: default avatarHanjun Guo <guohanjun@huawei.com>
      Signed-off-by: default avatarWill Deacon <will.deacon@arm.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e2beb74a
    • Linus Walleij's avatar
      i2c: pca-platform: Fix GPIO lookup code · 60bc55de
      Linus Walleij authored
      [ Upstream commit a0cac264 ]
      
      The devm_gpiod_request_gpiod() call will add "-gpios" to
      any passed connection ID before looking it up.
      
      I do not think the reset GPIO on this platform is named
      "reset-gpios-gpios" but rather "reset-gpios" in the device
      tree, so fix this up so that we get a proper reset GPIO
      handle.
      
      Also drop the inclusion of the legacy GPIO header.
      
      Fixes: 0e8ce93b ("i2c: pca-platform: add devicetree awareness")
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Reviewed-by: default avatarChris Packham <chris.packham@alliedtelesis.co.nz>
      Signed-off-by: default avatarWolfram Sang <wsa@the-dreams.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      60bc55de
    • Vadim Pasternak's avatar
      platform/mellanox: mlxreg-hotplug: Add devm_free_irq call to remove flow · 3d76f277
      Vadim Pasternak authored
      [ Upstream commit 8c2eb7b6 ]
      
      Add devm_free_irq() call to mlxreg-hotplug remove() for clean release
      of devices irq resource. Fix debugobjects warning triggered by rmmod
      It prevents of use-after-free memory, related to
      mlxreg_hotplug_work_handler.
      
      Issue has been reported as debugobjects warning triggered by
      'rmmod mlxtreg-hotplug' flow, while running kernel with
      CONFIG_DEBUG_OBJECTS* options.
      
      [ 2489.623551] ODEBUG: free active (active state 0) object type: work_struct hint: mlxreg_hotplug_work_handler+0x0/0x7f0 [mlxreg_hotplug]
      [ 2489.637097] WARNING: CPU: 5 PID: 3924 at lib/debugobjects.c:328 debug_print_object+0xfe/0x180
      [ 2489.637165] RIP: 0010:debug_print_object+0xfe/0x180
      ?
      [ 2489.637214] Call Trace:
      [ 2489.637225]  __debug_check_no_obj_freed+0x25e/0x320
      [ 2489.637231]  kfree+0x82/0x110
      [ 2489.637238]  release_nodes+0x33c/0x4e0
      [ 2489.637242]  ? devres_remove_group+0x1b0/0x1b0
      [ 2489.637247]  device_release_driver_internal+0x146/0x270
      [ 2489.637251]  driver_detach+0x73/0xe0
      [ 2489.637254]  bus_remove_driver+0xa1/0x170
      [ 2489.637261]  __x64_sys_delete_module+0x29e/0x320
      [ 2489.637265]  ? __ia32_sys_delete_module+0x320/0x320
      [ 2489.637268]  ? blkcg_exit_queue+0x20/0x20
      [ 2489.637273]  ? task_work_run+0x7d/0x100
      [ 2489.637278]  ? exit_to_usermode_loop+0x5b/0xf0
      [ 2489.637281]  do_syscall_64+0x73/0x160
      [ 2489.637287]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
      [ 2489.637290] RIP: 0033:0x7f95c3596fd7
      
      The difference in release flow with and with no devm_free_irq is listed
      below:
      
      bus: 'platform': remove driver mlxreg-hotplug
       mlxreg_hotplug_remove(start)
      					-> devm_free_irq (with new code)
       mlxreg_hotplug_remove (end)
       release_nodes (start)
        mlxreg-hotplug: DEVRES REL devm_hwmon_release (8 bytes)
        device: 'hwmon3': device_unregister
        PM: Removing info for No Bus:hwmon3
        mlxreg-hotplug: DEVRES REL devm_kzalloc_release (88 bytes)
        mlxreg-hotplug: DEVRES REL devm_kzalloc_release (6 bytes)
        mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
        mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
        mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
        mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
        mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
        mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
        mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
        mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
        mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
        mlxreg-hotplug: DEVRES REL devm_kzalloc_release (5 bytes)
        mlxreg-hotplug: DEVRES REL devm_irq_release (16 bytes) (no new code)
        mlxreg-hotplug: DEVRES REL devm_kzalloc_release (1376 bytes)
         ------------[ cut here ]------------ (no new code):
         ODEBUG: free active (active state 0) object type: work_struct hint: mlxreg_hotplug_work_handler
      
       release_nodes(end)
      driver: 'mlxreg-hotplug': driver_release
      
      Fixes: 1f976f69 ("platform/x86: Move Mellanox platform hotplug driver to platform/mellanox")
      Signed-off-by: default avatarVadim Pasternak <vadimp@mellanox.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3d76f277
    • Vadim Pasternak's avatar
      platform/x86: mlx-platform: Fix parent device in i2c-mux-reg device registration · f3f865f5
      Vadim Pasternak authored
      [ Upstream commit 160da20b ]
      
      Fix the issue found while running kernel with the option
      CONFIG_DEBUG_TEST_DRIVER_REMOVE.
      Driver 'mlx-platform' registers 'i2c_mlxcpld' device and then registers
      few underlying 'i2c-mux-reg' devices:
      	priv->pdev_i2c = platform_device_register_simple("i2c_mlxcpld", nr,
      							 NULL, 0);
      	...
      	for (i = 0; i < ARRAY_SIZE(mlxplat_mux_data); i++) {
      		priv->pdev_mux[i] = platform_device_register_resndata(
      						&mlxplat_dev->dev,
      						"i2c-mux-reg", i, NULL,
      						0, &mlxplat_mux_data[i],
      						sizeof(mlxplat_mux_data[i]));
      
      But actual parent of "i2c-mux-reg" device is priv->pdev_i2c->dev and
      not mlxplat_dev->dev.
      Patch fixes parent device parameter in a call to
      platform_device_register_resndata() for "i2c-mux-reg".
      
      It solves the race during initialization flow while 'i2c_mlxcpld.1' is
      removing after probe, while 'i2c-mux-reg.0' is still in probing flow:
      'i2c_mlxcpld.1'	flow:	probe -> remove -> probe.
      'i2c-mux-reg.0'	flow:		  probe -> ...
      
      [   12:621096] Registering platform device 'i2c_mlxcpld.1'. Parent at platform
      [   12:621117] device: 'i2c_mlxcpld.1': device_add
      [   12:621155] bus: 'platform': add device i2c_mlxcpld.1
      [   12:621384] Registering platform device 'i2c-mux-reg.0'. Parent at mlxplat
      [   12:621395] device: 'i2c-mux-reg.0': device_add
      [   12:621425] bus: 'platform': add device i2c-mux-reg.0
      [   12:621806] Registering platform device 'i2c-mux-reg.1'. Parent at mlxplat
      [   12:621828] device: 'i2c-mux-reg.1': device_add
      [   12:621892] bus: 'platform': add device i2c-mux-reg.1
      [   12:621906] bus: 'platform': add driver i2c_mlxcpld
      [   12:621996] bus: 'platform': driver_probe_device: matched device i2c_mlxcpld.1 with driver i2c_mlxcpld
      [   12:622003] bus: 'platform': really_probe: probing driver i2c_mlxcpld with device i2c_mlxcpld.1
      [   12:622100] i2c_mlxcpld i2c_mlxcpld.1: no default pinctrl state
      [   12:622293] device: 'i2c-1': device_add
      [   12:627280] bus: 'i2c': add device i2c-1
      [   12:627692] device: 'i2c-1': device_add
      [   12.629639] bus: 'platform': add driver i2c-mux-reg
      [   12.629718] bus: 'platform': driver_probe_device: matched device i2c-mux-reg.0 with driver i2c-mux-reg
      [   12.629723] bus: 'platform': really_probe: probing driver i2c-mux-reg with device i2c-mux-reg.0
      [   12.629818] i2c-mux-reg i2c-mux-reg.0: no default pinctrl state
      [   12.629981] platform i2c-mux-reg.0: Driver i2c-mux-reg requests probe deferral
      [   12.629986] platform i2c-mux-reg.0: Added to deferred list
      [   12.629992] bus: 'platform': driver_probe_device: matched device i2c-mux-reg.1 with driver i2c-mux-reg
      [   12.629997] bus: 'platform': really_probe: probing driver i2c-mux-reg with device i2c-mux-reg.1
      [   12.630091] i2c-mux-reg i2c-mux-reg.1: no default pinctrl state
      [   12.630247] platform i2c-mux-reg.1: Driver i2c-mux-reg requests probe deferral
      [   12.630252] platform i2c-mux-reg.1: Added to deferred list
      [   12.640892] devices_kset: Moving i2c-mux-reg.0 to end of list
      [   12.640900] platform i2c-mux-reg.0: Retrying from deferred list
      [   12.640911] bus: 'platform': driver_probe_device: matched device i2c-mux-reg.0 with driver i2c-mux-reg
      [   12.640919] bus: 'platform': really_probe: probing driver i2c-mux-reg with device i2c-mux-reg.0
      [   12.640999] i2c-mux-reg i2c-mux-reg.0: no default pinctrl state
      [   12.641177] platform i2c-mux-reg.0: Driver i2c-mux-reg requests probe deferral
      [   12.641187] platform i2c-mux-reg.0: Added to deferred list
      [   12.641198] devices_kset: Moving i2c-mux-reg.1 to end of list
      [   12.641219] platform i2c-mux-reg.1: Retrying from deferred list
      [   12.641237] bus: 'platform': driver_probe_device: matched device i2c-mux-reg.1 with driver i2c-mux-reg
      [   12.641247] bus: 'platform': really_probe: probing driver i2c-mux-reg with device i2c-mux-reg.1
      [   12.641331] i2c-mux-reg i2c-mux-reg.1: no default pinctrl state
      [   12.641465] platform i2c-mux-reg.1: Driver i2c-mux-reg requests probe deferral
      [   12.641469] platform i2c-mux-reg.1: Added to deferred list
      [   12.646427] device: 'i2c-1': device_add
      [   12.646647] bus: 'i2c': add device i2c-1
      [   12.647104] device: 'i2c-1': device_add
      [   12.669231] devices_kset: Moving i2c-mux-reg.0 to end of list
      [   12.669240] platform i2c-mux-reg.0: Retrying from deferred list
      [   12.669258] bus: 'platform': driver_probe_device: matched device i2c-mux-reg.0 with driver i2c-mux-reg
      [   12.669263] bus: 'platform': really_probe: probing driver i2c-mux-reg with device i2c-mux-reg.0
      [   12.669343] i2c-mux-reg i2c-mux-reg.0: no default pinctrl state
      [   12.669585] device: 'i2c-2': device_add
      [   12.669795] bus: 'i2c': add device i2c-2
      [   12.670201] device: 'i2c-2': device_add
      [   12.671427] i2c i2c-1: Added multiplexed i2c bus 2
      [   12.671514] device: 'i2c-3': device_add
      [   12.671724] bus: 'i2c': add device i2c-3
      [   12.672136] device: 'i2c-3': device_add
      [   12.673378] i2c i2c-1: Added multiplexed i2c bus 3
      [   12.673472] device: 'i2c-4': device_add
      [   12.673676] bus: 'i2c': add device i2c-4
      [   12.674060] device: 'i2c-4': device_add
      [   12.675861] i2c i2c-1: Added multiplexed i2c bus 4
      [   12.675941] device: 'i2c-5': device_add
      [   12.676150] bus: 'i2c': add device i2c-5
      [   12.676550] device: 'i2c-5': device_add
      [   12.678103] i2c i2c-1: Added multiplexed i2c bus 5
      [   12.678193] device: 'i2c-6': device_add
      [   12.678395] bus: 'i2c': add device i2c-6
      [   12.678774] device: 'i2c-6': device_add
      [   12.679969] i2c i2c-1: Added multiplexed i2c bus 6
      [   12.680065] device: 'i2c-7': device_add
      [   12.680275] bus: 'i2c': add device i2c-7
      [   12.680913] device: 'i2c-7': device_add
      [   12.682506] i2c i2c-1: Added multiplexed i2c bus 7
      [   12.682600] device: 'i2c-8': device_add
      [   12.682808] bus: 'i2c': add device i2c-8
      [   12.683189] device: 'i2c-8': device_add
      [   12.683907] device: 'i2c-1': device_unregister
      [   12.683945] device: 'i2c-1': device_unregister
      [   12.684387] device: 'i2c-1': device_create_release
      [   12.684536] bus: 'i2c': remove device i2c-1
      [   12.686019] i2c i2c-8: Failed to create compatibility class link
      [   12.686086] ------------[ cut here ]------------
      [   12.686087] can't create symlink to mux device
      [   12.686224] Workqueue: events deferred_probe_work_func
      [   12.686135] WARNING: CPU: 7 PID: 436 at drivers/i2c/i2c-mux.c:416 i2c_mux_add_adapter+0x729/0x7d0 [i2c_mux]
      [   12.686232] RIP: 0010:i2c_mux_add_adapter+0x729/0x7d0 [i2c_mux]
      [   0x190/0x190 [i2c_mux]
      [   12.686300]  ? i2c_mux_alloc+0xac/0x110 [i2c_mux]
      [   12.686306]  ? i2c_mux_reg_set+0x200/0x200 [i2c_mux_reg]
      [   12.686313]  i2c_mux_reg_probe+0x22c/0x731 [i2c_mux_reg]
      [   12.686322]  ? i2c_mux_reg_deselect+0x60/0x60 [i2c_mux_reg]
      [   12.686346]  platform_drv_probe+0xa8/0x110
      [   12.686351]  really_probe+0x185/0x720
      [   12.686358]  driver_probe_device+0xdf/0x1f0
      ...
      [   12.686522] i2c i2c-1: Added multiplexed i2c bus 8
      [   12.686621] device: 'i2c-9': device_add
      [   12.686626] kobject_add_internal failed for i2c-9 (error: -2 parent: i2c-1)
      [   12.694729] i2c-core: adapter 'i2c-1-mux (chan_id 8)': can't register device (-2)
      [   12.705726] i2c i2c-1: failed to add mux-adapter 8 as bus 9 (error=-2)
      [   12.714494] device: 'i2c-8': device_unregister
      [   12.714537] device: 'i2c-8': device_unregister
      
      Fixes: 6613d18e ("platform/x86: mlx-platform: Move module from arch/x86")
      Signed-off-by: default avatarVadim Pasternak <vadimp@mellanox.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f3f865f5
    • Mathew King's avatar
      platform/x86: intel-vbtn: Report switch events when event wakes device · b551985b
      Mathew King authored
      [ Upstream commit cb1921b1 ]
      
      When a switch event, such as tablet mode/laptop mode or docked/undocked,
      wakes a device make sure that the value of the swich is reported.
      Without when a device is put in tablet mode from laptop mode when it is
      suspended or vice versa the device will wake up but mode will be
      incorrect.
      
      Tested by suspending a device in laptop mode and putting it in tablet
      mode, the device resumes and is in tablet mode. When suspending the
      device in tablet mode and putting it in laptop mode the device resumes
      and is in laptop mode.
      Signed-off-by: default avatarMathew King <mathewk@chromium.org>
      Reviewed-by: default avatarJett Rink <jettrink@chromium.org>
      Reviewed-by: default avatarMario Limonciello <mario.limonciello@dell.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b551985b
    • Hans de Goede's avatar
      platform/x86: asus-wmi: Only Tell EC the OS will handle display hotkeys from asus_nb_wmi · f1585eba
      Hans de Goede authored
      [ Upstream commit 401fee81 ]
      
      Commit 78f3ac76 ("platform/x86: asus-wmi: Tell the EC the OS will
      handle the display off hotkey") causes the backlight to be permanently off
      on various EeePC laptop models using the eeepc-wmi driver (Asus EeePC
      1015BX, Asus EeePC 1025C).
      
      The asus_wmi_set_devstate(ASUS_WMI_DEVID_BACKLIGHT, 2, NULL) call added
      by that commit is made conditional in this commit and only enabled in
      the quirk_entry structs in the asus-nb-wmi driver fixing the broken
      display / backlight on various EeePC laptop models.
      
      Cc: João Paulo Rechi Vita <jprvita@endlessm.com>
      Fixes: 78f3ac76 ("platform/x86: asus-wmi: Tell the EC the OS will handle the display off hotkey")
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarAndy Shevchenko <andriy.shevchenko@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f1585eba
    • Alex Levin's avatar
      ASoC: Intel: sst: fix kmalloc call with wrong flags · c2784e57
      Alex Levin authored
      [ Upstream commit 3da428ff ]
      
      When calling kmalloc with GFP_KERNEL in case CONFIG_SLOB is unset,
      kmem_cache_alloc_trace is called.
      
      In case CONFIG_TRACING is set, kmem_cache_alloc_trace will ball
      slab_alloc, which will call slab_pre_alloc_hook which might_sleep_if.
      
      The context in which it is called in this case, the
      intel_sst_interrupt_mrfld, calling a sleeping kmalloc generates a BUG():
      
      Fixes: 972b0d45 ("ASoC: Intel: remove GFP_ATOMIC, use GFP_KERNEL")
      
      [   20.250671] BUG: sleeping function called from invalid context at mm/slab.h:422
      [   20.250683] in_atomic(): 1, irqs_disabled(): 1, pid: 1791, name: Chrome_IOThread
      [   20.250690] CPU: 0 PID: 1791 Comm: Chrome_IOThread Tainted: G        W         4.19.43 #61
      [   20.250693] Hardware name: GOOGLE Kefka, BIOS Google_Kefka.7287.337.0 03/02/2017
      [   20.250697] Call Trace:
      [   20.250704]  <IRQ>
      [   20.250716]  dump_stack+0x7e/0xc3
      [   20.250725]  ___might_sleep+0x12a/0x140
      [   20.250731]  kmem_cache_alloc_trace+0x53/0x1c5
      [   20.250736]  ? update_cfs_rq_load_avg+0x17e/0x1aa
      [   20.250740]  ? cpu_load_update+0x6c/0xc2
      [   20.250746]  sst_create_ipc_msg+0x2d/0x88
      [   20.250752]  intel_sst_interrupt_mrfld+0x12a/0x22c
      [   20.250758]  __handle_irq_event_percpu+0x133/0x228
      [   20.250764]  handle_irq_event_percpu+0x35/0x7a
      [   20.250768]  handle_irq_event+0x36/0x55
      [   20.250773]  handle_fasteoi_irq+0xab/0x16c
      [   20.250779]  handle_irq+0xd9/0x11e
      [   20.250785]  do_IRQ+0x54/0xe0
      [   20.250791]  common_interrupt+0xf/0xf
      [   20.250795]  </IRQ>
      [   20.250800] RIP: 0010:__lru_cache_add+0x4e/0xad
      [   20.250806] Code: 00 01 48 c7 c7 b8 df 01 00 65 48 03 3c 25 28 f1 00 00 48 8b 48 08 48 89 ca 48 ff ca f6 c1 01 48 0f 44 d0 f0 ff 42 34 0f b6 0f <89> ca fe c2 88 17 48 89 44 cf 08 80 fa 0f 74 0e 48 8b 08 66 85 c9
      [   20.250809] RSP: 0000:ffffa568810bfd98 EFLAGS: 00000202 ORIG_RAX: ffffffffffffffd6
      [   20.250814] RAX: ffffd3b904eb1940 RBX: ffffd3b904eb1940 RCX: 0000000000000004
      [   20.250817] RDX: ffffd3b904eb1940 RSI: ffffa10ee5c47450 RDI: ffffa10efba1dfb8
      [   20.250821] RBP: ffffa568810bfda8 R08: ffffa10ef9c741c1 R09: dead000000000100
      [   20.250824] R10: 0000000000000000 R11: 0000000000000000 R12: ffffa10ee8d52a40
      [   20.250827] R13: ffffa10ee8d52000 R14: ffffa10ee5c47450 R15: 800000013ac65067
      [   20.250835]  lru_cache_add_active_or_unevictable+0x4e/0xb8
      [   20.250841]  handle_mm_fault+0xd98/0x10c4
      [   20.250848]  __do_page_fault+0x235/0x42d
      [   20.250853]  ? page_fault+0x8/0x30
      [   20.250858]  do_page_fault+0x3d/0x17a
      [   20.250862]  ? page_fault+0x8/0x30
      [   20.250866]  page_fault+0x1e/0x30
      [   20.250872] RIP: 0033:0x7962fdea9304
      [   20.250875] Code: 0f 11 4c 17 f0 c3 48 3b 15 f1 26 31 00 0f 83 e2 00 00 00 48 39 f7 72 0f 74 12 4c 8d 0c 16 4c 39 cf 0f 82 63 01 00 00 48 89 d1 <f3> a4 c3 80 fa 08 73 12 80 fa 04 73 1e 80 fa 01 77 26 72 05 0f b6
      [   20.250879] RSP: 002b:00007962f4db5468 EFLAGS: 00010206
      [   20.250883] RAX: 00003c8cc9d47008 RBX: 0000000000000000 RCX: 0000000000001b48
      [   20.250886] RDX: 0000000000002b40 RSI: 00003c8cc9551000 RDI: 00003c8cc9d48000
      [   20.250890] RBP: 00007962f4db5820 R08: 0000000000000000 R09: 00003c8cc9552b48
      [   20.250893] R10: 0000562dd1064d30 R11: 00003c8cc825b908 R12: 00003c8cc966d3c0
      [   20.250896] R13: 00003c8cc9e280c0 R14: 0000000000000000 R15: 0000000000000000
      Signed-off-by: default avatarAlex Levin <levinale@chromium.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c2784e57
    • Ranjani Sridharan's avatar
      ASoC: core: Fix deadlock in snd_soc_instantiate_card() · c7e65a33
      Ranjani Sridharan authored
      [ Upstream commit 495f926c ]
      
      Move the client_mutex lock to snd_soc_unbind_card() before
      removing link components. This prevents the deadlock
      in the error path in snd_soc_instantiate_card().
      
      Fixes: 34ac3c3e (ASoC: core: lock client_mutex while removing
      link components)
      Reported-by: default avatarkernelci.org bot <bot@kernelci.org>
      Signed-off-by: default avatarRanjani Sridharan <ranjani.sridharan@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c7e65a33
    • Hans de Goede's avatar
      drm: panel-orientation-quirks: Add quirk for GPD MicroPC · 0a1c42cf
      Hans de Goede authored
      [ Upstream commit 652b8b08 ]
      
      GPD has done it again, make a nice device (good), use way too generic
      DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).
      
      Because of the too generic DMI strings this entry is also doing bios-date
      matching, so the gpd_micropc data struct may very well need to be updated
      with some extra bios-dates in the future.
      Acked-by: default avatarMaxime Ripard <maxime.ripard@bootlin.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190524125759.14131-2-hdegoede@redhat.com
      (cherry picked from commit f2f2bb60)
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      0a1c42cf
    • Hans de Goede's avatar
      drm: panel-orientation-quirks: Add quirk for GPD pocket2 · eabfa988
      Hans de Goede authored
      [ Upstream commit 15abc711 ]
      
      GPD has done it again, make a nice device (good), use way too generic
      DMI strings (bad) and use a portrait screen rotated 90 degrees (ugly).
      
      Because of the too generic DMI strings this entry is also doing bios-date
      matching, so the gpd_pocket2 data struct may very well need to be updated
      with some extra bios-dates in the future.
      
      Changes in v2:
      -Add one more known BIOS date to the list of BIOS dates
      
      Cc: Jurgen Kramer <gtmkramer@xs4all.nl>
      Reported-by: default avatarJurgen Kramer <gtmkramer@xs4all.nl>
      Acked-by: default avatarMaxime Ripard <maxime.ripard@bootlin.com>
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Link: https://patchwork.freedesktop.org/patch/msgid/20190524125759.14131-1-hdegoede@redhat.com
      (cherry picked from commit 6dab9102)
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      eabfa988
    • H. Nikolaus Schaller's avatar
      gpio: pca953x: hack to fix 24 bit gpio expanders · ebae5c66
      H. Nikolaus Schaller authored
      [ Upstream commit 3b00691c ]
      
      24 bit expanders use REG_ADDR_AI in combination with register addressing. This
      conflicts with regmap which takes this bit as part of the register number,
      i.e. a second cache entry is defined for accessed with REG_ADDR_AI being
      set although on the chip it is the same register as with REG_ADDR_AI being
      cleared.
      
      The problem was introduced by
      
      	commit b32cecb4 ("gpio: pca953x: Extract the register address mangling to single function")
      
      but only became visible by
      
      	commit 8b9f9d4d ("regmap: verify if register is writeable before writing operations")
      
      because before, the regmap size was effectively ignored and
      pca953x_writeable_register() did know to ignore REG_ADDR_AI. Still, there
      were two separate cache entries created.
      
      Since the use of REG_ADDR_AI seems to be static we can work around this
      issue by simply increasing the size of the regmap to cover the "virtual"
      registers with REG_ADDR_AI being set. This only means that half of the
      regmap buffer will be unused.
      Reported-by: default avatarH. Nikolaus Schaller <hns@goldelico.com>
      Suggested-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarH. Nikolaus Schaller <hns@goldelico.com>
      Signed-off-by: default avatarLinus Walleij <linus.walleij@linaro.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ebae5c66
    • Don Brace's avatar
      scsi: hpsa: correct ioaccel2 chaining · f55e3e08
      Don Brace authored
      [ Upstream commit 625d7d35 ]
      
      - set ioaccel2_sg_element member 'chain_indicator' to IOACCEL2_LAST_SG for
        the last s/g element.
      
      - set ioaccel2_sg_element member 'chain_indicator' to IOACCEL2_CHAIN when
        chaining.
      Reviewed-by: default avatarBader Ali - Saleh <bader.alisaleh@microsemi.com>
      Reviewed-by: default avatarScott Teel <scott.teel@microsemi.com>
      Reviewed-by: default avatarMatt Perricone <matt.perricone@microsemi.com>
      Signed-off-by: default avatarDon Brace <don.brace@microsemi.com>
      Signed-off-by: default avatarMartin K. Petersen <martin.petersen@oracle.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f55e3e08
    • Amadeusz Sławiński's avatar
      SoC: rt274: Fix internal jack assignment in set_jack callback · b6cb887f
      Amadeusz Sławiński authored
      [ Upstream commit 04268bf2 ]
      
      When we call snd_soc_component_set_jack(component, NULL, NULL) we should
      set rt274->jack to passed jack, so when interrupt is triggered it calls
      snd_soc_jack_report(rt274->jack, ...) with proper value.
      
      This fixes problem in machine where in register, we call
      snd_soc_register(component, &headset, NULL), which just calls
      rt274_mic_detect via callback.
      Now when machine driver is removed "headset" will be gone, so we
      need to tell codec driver that it's gone with:
      snd_soc_register(component, NULL, NULL), but we also need to be able
      to handle NULL jack argument here gracefully.
      If we don't set it to NULL, next time the rt274_irq runs it will call
      snd_soc_jack_report with first argument being invalid pointer and there
      will be Oops.
      Signed-off-by: default avatarAmadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      b6cb887f
    • Amadeusz Sławiński's avatar
      ALSA: hdac: fix memory release for SST and SOF drivers · 69b418b0
      Amadeusz Sławiński authored
      [ Upstream commit 6d647b73 ]
      
      During the integration of HDaudio support, we changed the way in which
      we get hdev in snd_hdac_ext_bus_device_init() to use one preallocated
      with devm_kzalloc(), however it still left kfree(hdev) in
      snd_hdac_ext_bus_device_exit(). It leads to oopses when trying to
      rmmod and modprobe. Fix it, by just removing kfree call.
      
      SOF also uses some of the snd_hdac_ functions for HDAudio support but
      allocated the memory with kzalloc. A matching fix is provided
      separately to align all users of the snd_hdac_ library.
      
      Fixes: 6298542f ("ALSA: hdac: remove memory allocation from snd_hdac_ext_bus_device_init")
      Reviewed-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarAmadeusz Sławiński <amadeuszx.slawinski@linux.intel.com>
      Signed-off-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      69b418b0
    • Tzung-Bi Shih's avatar
      ASoC: core: move DAI pre-links initiation to snd_soc_instantiate_card · 1f0b3bba
      Tzung-Bi Shih authored
      [ Upstream commit 70fc5373 ]
      
      Kernel crashes when an ASoC component rebinding.
      
      The dai_link->platforms has been reset to NULL by soc_cleanup_platform()
      in soc_cleanup_card_resources() when un-registering component.  However,
      it has no chance to re-allocate the dai_link->platforms when registering
      the component again.
      
      Move the DAI pre-links initiation from snd_soc_register_card() to
      snd_soc_instantiate_card() to make sure all DAI pre-links get initiated
      when component rebinding.
      
      As an example, by using the following commands:
      - echo -n max98357a > /sys/bus/platform/drivers/max98357a/unbind
      - echo -n max98357a > /sys/bus/platform/drivers/max98357a/bind
      
      Got the error message:
      "Unable to handle kernel NULL pointer dereference at virtual address".
      
      The call trace:
      snd_soc_is_matching_component+0x30/0x6c
      soc_bind_dai_link+0x16c/0x240
      snd_soc_bind_card+0x1e4/0xb10
      snd_soc_add_component+0x270/0x300
      snd_soc_register_component+0x54/0x6c
      Signed-off-by: default avatarTzung-Bi Shih <tzungbi@google.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1f0b3bba
    • Pierre-Louis Bossart's avatar
      ASoC: Intel: cht_bsw_rt5672: fix kernel oops with platform_name override · 54f49e22
      Pierre-Louis Bossart authored
      [ Upstream commit 9bbc7993 ]
      
      The platform override code uses devm_ functions to allocate memory for
      the new name but the card device is not initialized. Fix by moving the
      init earlier.
      
      Fixes: f403906d ("ASoC: Intel: cht_bsw_rt5672: platform name fixup support")
      Signed-off-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      54f49e22
    • Pierre-Louis Bossart's avatar
      ASoC: Intel: cht_bsw_nau8824: fix kernel oops with platform_name override · 1cdfe188
      Pierre-Louis Bossart authored
      [ Upstream commit 096701e8 ]
      
      The platform override code uses devm_ functions to allocate memory for
      the new name but the card device is not initialized. Fix by moving the
      init earlier.
      
      Fixes: 4506db80 ("ASoC: Intel: cht_bsw_nau8824: platform name fixup support")
      Signed-off-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      1cdfe188
    • Pierre-Louis Bossart's avatar
      ASoC: Intel: bytcht_es8316: fix kernel oops with platform_name override · 6eee5b34
      Pierre-Louis Bossart authored
      [ Upstream commit 79136a01 ]
      
      The platform override code uses devm_ functions to allocate memory for
      the new name but the card device is not initialized. Fix by moving the
      init earlier.
      
      Fixes: e4bc6b11 ("ASoC: Intel: bytcht_es8316: platform name fixup support")
      Signed-off-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      6eee5b34
    • Pierre-Louis Bossart's avatar
      ASoC: Intel: cht_bsw_max98090: fix kernel oops with platform_name override · 11c8ff97
      Pierre-Louis Bossart authored
      [ Upstream commit fb545551 ]
      
      The platform override code uses devm_ functions to allocate memory for
      the new name but the card device is not initialized. Fix by moving the
      init earlier.
      
      Fixes: 7e7e24d7 ("ASoC: Intel: cht_bsw_max98090_ti: platform name fixup support")
      Signed-off-by: default avatarPierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      11c8ff97
    • Andrzej Pietrasiewicz's avatar
      usb: gadget: dwc2: fix zlp handling · f5c842ff
      Andrzej Pietrasiewicz authored
      [ Upstream commit 066cfd07 ]
      
      The patch 10209abe
      usb: dwc2: gadget: Add scatter-gather mode
      
      avoided a NULL pointer dereference (hs_ep->req == NULL) by
      calling dwc2_gadget_fill_nonisoc_xfer_dma_one() directly instead of through
      the dwc2_gadget_config_nonisoc_xfer_ddma() wrapper, which unconditionally
      dereferenced the said pointer.
      
      However, this was based on an incorrect assumption that in the context of
      dwc2_hsotg_program_zlp() the pointer is always NULL, which is not the case.
      The result were SB CV MSC tests failing starting from Test Case 6.
      
      Instead, this patch reverts to calling the wrapper and adds a check for
      the pointer being NULL inside the wrapper.
      
      Fixes: 10209abe (usb: dwc2: gadget: Add scatter-gather mode)
      Acked-by: default avatarMinas Harutyunyan <hminas@synopsys.com>
      Signed-off-by: default avatarAndrzej Pietrasiewicz <andrzej.p@collabora.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      f5c842ff
    • Alexandre Belloni's avatar
      usb: gadget: udc: lpc32xx: allocate descriptor with GFP_ATOMIC · 3b302f77
      Alexandre Belloni authored
      [ Upstream commit fbc318af ]
      
      Gadget drivers may queue request in interrupt context. This would lead to
      a descriptor allocation in that context. In that case we would hit
      BUG_ON(in_interrupt()) in __get_vm_area_node.
      
      Also remove the unnecessary cast.
      Acked-by: default avatarSylvain Lemieux <slemieux.tyco@gmail.com>
      Tested-by: default avatarJames Grant <jamesg@zaltys.org>
      Signed-off-by: default avatarAlexandre Belloni <alexandre.belloni@bootlin.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      3b302f77
    • Young Xiao's avatar
      usb: gadget: fusb300_udc: Fix memory leak of fusb300->ep[i] · ea1fb51b
      Young Xiao authored
      [ Upstream commit 62fd0e0a ]
      
      There is no deallocation of fusb300->ep[i] elements, allocated at
      fusb300_probe.
      
      The patch adds deallocation of fusb300->ep array elements.
      Signed-off-by: default avatarYoung Xiao <92siuyang@gmail.com>
      Signed-off-by: default avatarFelipe Balbi <felipe.balbi@linux.intel.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      ea1fb51b
    • Kan Liang's avatar
      x86/CPU: Add more Icelake model numbers · a795fdcd
      Kan Liang authored
      [ Upstream commit e35faeb6 ]
      
      Add the CPUID model numbers of Icelake (ICL) desktop and server
      processors to the Intel family list.
      
       [ Qiuxu: Sort the macros by model number. ]
      Signed-off-by: default avatarKan Liang <kan.liang@linux.intel.com>
      Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      Cc: "H. Peter Anvin" <hpa@zytor.com>
      Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Qiuxu Zhuo <qiuxu.zhuo@intel.com>
      Cc: Rajneesh Bhardwaj <rajneesh.bhardwaj@linux.intel.com>
      Cc: rui.zhang@intel.com
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: Tony Luck <tony.luck@intel.com>
      Cc: x86-ml <x86@kernel.org>
      Link: https://lkml.kernel.org/r/20190603134122.13853-1-kan.liang@linux.intel.comSigned-off-by: default avatarSasha Levin <sashal@kernel.org>
      a795fdcd
    • Marcus Cooper's avatar
      ASoC: sun4i-i2s: Add offset to RX channel select · c9e39461
      Marcus Cooper authored
      [ Upstream commit f9927000 ]
      
      Whilst testing the capture functionality of the i2s on the newer
      SoCs it was noticed that the recording was somewhat distorted.
      This was due to the offset not being set correctly on the receiver
      side.
      Signed-off-by: default avatarMarcus Cooper <codekipper@gmail.com>
      Acked-by: default avatarMaxime Ripard <maxime.ripard@bootlin.com>
      Acked-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      c9e39461
    • Marcus Cooper's avatar
      ASoC: sun4i-i2s: Fix sun8i tx channel offset mask · bba440b1
      Marcus Cooper authored
      [ Upstream commit 7e46169a ]
      
      Although not causing any noticeable issues, the mask for the
      channel offset is covering too many bits.
      Signed-off-by: default avatarMarcus Cooper <codekipper@gmail.com>
      Acked-by: default avatarMaxime Ripard <maxime.ripard@bootlin.com>
      Acked-by: default avatarChen-Yu Tsai <wens@csie.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      bba440b1
    • Yu-Hsuan Hsu's avatar
      ASoC: max98090: remove 24-bit format support if RJ is 0 · 5db5be87
      Yu-Hsuan Hsu authored
      [ Upstream commit 5628c897 ]
      
      The supported formats are S16_LE and S24_LE now. However, by datasheet
      of max98090, S24_LE is only supported when it is in the right justified
      mode. We should remove 24-bit format if it is not in that mode to avoid
      triggering error.
      Signed-off-by: default avatarYu-Hsuan Hsu <yuhsuan@chromium.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      5db5be87
    • Hsin-Yi Wang's avatar
      drm/mediatek: call mtk_dsi_stop() after mtk_drm_crtc_atomic_disable() · 52d006fa
      Hsin-Yi Wang authored
      [ Upstream commit 2458d9d6 ]
      
      mtk_dsi_stop() should be called after mtk_drm_crtc_atomic_disable(), which
      needs ovl irq for drm_crtc_wait_one_vblank(), since after mtk_dsi_stop() is
      called, ovl irq will be disabled. If drm_crtc_wait_one_vblank() is called
      after last irq, it will timeout with this message: "vblank wait timed out
      on crtc 0". This happens sometimes when turning off the screen.
      
      In drm_atomic_helper.c#disable_outputs(),
      the calling sequence when turning off the screen is:
      
      1. mtk_dsi_encoder_disable()
           --> mtk_output_dsi_disable()
             --> mtk_dsi_stop();  /* sometimes make vblank timeout in
                                     atomic_disable */
             --> mtk_dsi_poweroff();
      2. mtk_drm_crtc_atomic_disable()
           --> drm_crtc_wait_one_vblank();
           ...
             --> mtk_dsi_ddp_stop()
               --> mtk_dsi_poweroff();
      
      mtk_dsi_poweroff() has reference count design, change to make
      mtk_dsi_stop() called in mtk_dsi_poweroff() when refcount is 0.
      
      Fixes: 0707632b ("drm/mediatek: update DSI sub driver flow for sending commands to panel")
      Signed-off-by: default avatarHsin-Yi Wang <hsinyi@chromium.org>
      Signed-off-by: default avatarCK Hu <ck.hu@mediatek.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      52d006fa
    • Hsin-Yi Wang's avatar
      drm/mediatek: clear num_pipes when unbind driver · 7dd1a64b
      Hsin-Yi Wang authored
      [ Upstream commit a4cd1d2b ]
      
      num_pipes is used for mutex created in mtk_drm_crtc_create(). If we
      don't clear num_pipes count, when rebinding driver, the count will
      be accumulated. From mtk_disp_mutex_get(), there can only be at most
      10 mutex id. Clear this number so it starts from 0 in every rebind.
      
      Fixes: 119f5173 ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
      Signed-off-by: default avatarHsin-Yi Wang <hsinyi@chromium.org>
      Signed-off-by: default avatarCK Hu <ck.hu@mediatek.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7dd1a64b
    • Hsin-Yi Wang's avatar
      drm/mediatek: call drm_atomic_helper_shutdown() when unbinding driver · 815c6c19
      Hsin-Yi Wang authored
      [ Upstream commit cf49b24f ]
      
      shutdown all CRTC when unbinding drm driver.
      
      Fixes: 119f5173 ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
      Signed-off-by: default avatarHsin-Yi Wang <hsinyi@chromium.org>
      Signed-off-by: default avatarCK Hu <ck.hu@mediatek.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      815c6c19
    • Hsin-Yi Wang's avatar
      drm/mediatek: unbind components in mtk_drm_unbind() · e0594307
      Hsin-Yi Wang authored
      [ Upstream commit f0fd8483 ]
      
      Unbinding components (i.e. mtk_dsi and mtk_disp_ovl/rdma/color) will
      trigger master(mtk_drm)'s .unbind(), and currently mtk_drm's unbind
      won't actually unbind components. During the next bind,
      mtk_drm_kms_init() is called, and the components are added back.
      
      .unbind() should call mtk_drm_kms_deinit() to unbind components.
      
      And since component_master_del() in .remove() will trigger .unbind(),
      which will also unregister device, it's fine to remove original functions
      called here.
      
      Fixes: 119f5173 ("drm/mediatek: Add DRM Driver for Mediatek SoC MT8173.")
      Signed-off-by: default avatarHsin-Yi Wang <hsinyi@chromium.org>
      Signed-off-by: default avatarCK Hu <ck.hu@mediatek.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      e0594307
    • Hsin-Yi Wang's avatar
      drm/mediatek: fix unbind functions · 57d30478
      Hsin-Yi Wang authored
      [ Upstream commit 8fd7a37b ]
      
      detatch panel in mtk_dsi_destroy_conn_enc(), since .bind will try to
      attach it again.
      
      Fixes: 2e54c14e ("drm/mediatek: Add DSI sub driver")
      Signed-off-by: default avatarHsin-Yi Wang <hsinyi@chromium.org>
      Signed-off-by: default avatarCK Hu <ck.hu@mediatek.com>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      57d30478
    • Ranjani Sridharan's avatar
      ASoC: hda: fix unbalanced codec dev refcount for HDA_DEV_ASOC · 48f2ed69
      Ranjani Sridharan authored
      [ Upstream commit d6947bb2 ]
      
      HDA_DEV_ASOC type codec device refcounts are managed differently
      from HDA_DEV_LEGACY devices. The refcount is released explicitly
      in snd_hdac_ext_bus_device_remove() for ASOC type devices.
      So, remove the put_device() call in snd_hda_codec_dev_free()
      for such devices to make the refcount balanced. This will prevent
      the NULL pointer exception when the codec driver is released
      after the card is freed.
      Signed-off-by: default avatarRanjani Sridharan <ranjani.sridharan@linux.intel.com>
      Reviewed-by: default avatarTakashi Iwai <tiwai@suse.de>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      48f2ed69
    • Kovács Tamás's avatar
      ASoC: Intel: Baytrail: add quirk for Aegex 10 (RU2) tablet · 052fd24a
      Kovács Tamás authored
      [ Upstream commit 3e951e79 ]
      
      This tablet has an incorrect acpi identifier just like
      Thinkpad10 tablet, which is why it is trying to load the RT5640 driver
      instead of the RT5762 driver. The RT5640 driver, on the other hand, checks
      the hardware ID, so no driver are loaded during boot. This fix resolves to
      load the RT5672 driver on this tablet during boot. It also provides the
      correct IO configuration, like the jack detect mode 3, for 1.8V pullup. I
      would like to thank Pierre-Louis Bossart for helping with this patch.
      Signed-off-by: default avatarKovács Tamás <kepszlok@zohomail.eu>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      052fd24a
    • Błażej Szczygieł's avatar
      HID: a4tech: fix horizontal scrolling · 260381ed
      Błażej Szczygieł authored
      [ Upstream commit abf82e8f ]
      
      Since recent high resolution scrolling changes the A4Tech driver must
      check for the "REL_WHEEL_HI_RES" usage code.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=203369
      Fixes: 2dc702c9 ("HID: input: use the Resolution Multiplier for high-resolution scrolling")
      Signed-off-by: default avatarBłażej Szczygieł <spaz16@wp.pl>
      Signed-off-by: default avatarJiri Kosina <jkosina@suse.cz>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      260381ed
    • Lu Baolu's avatar
      iommu/vt-d: Set the right field for Page Walk Snoop · 7ae68002
      Lu Baolu authored
      [ Upstream commit 66d78ad3 ]
      
      Set the page walk snoop to the right bit, otherwise the domain
      id field will be overlapped.
      Reported-by: default avatarDave Jiang <dave.jiang@intel.com>
      Fixes: 6f7db75e ("iommu/vt-d: Add second level page table interface")
      Signed-off-by: default avatarLu Baolu <baolu.lu@linux.intel.com>
      Signed-off-by: default avatarJoerg Roedel <jroedel@suse.de>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      7ae68002
    • Ranjani Sridharan's avatar
      ASoC: core: lock client_mutex while removing link components · cd3d34cf
      Ranjani Sridharan authored
      [ Upstream commit 34ac3c3e ]
      
      Removing link components results in topology unloading. So,
      acquire the client_mutex before removing components in
      soc_remove_link_components. This will prevent the lockdep warning
      seen when dai links are removed during topology removal.
      Signed-off-by: default avatarRanjani Sridharan <ranjani.sridharan@linux.intel.com>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      cd3d34cf
    • YueHaibing's avatar
      spi: bitbang: Fix NULL pointer dereference in spi_unregister_master · 451fd3b3
      YueHaibing authored
      [ Upstream commit 5caaf29a ]
      
      If spi_register_master fails in spi_bitbang_start
      because device_add failure, We should return the
      error code other than 0, otherwise calling
      spi_bitbang_stop may trigger NULL pointer dereference
      like this:
      
      BUG: KASAN: null-ptr-deref in __list_del_entry_valid+0x45/0xd0
      Read of size 8 at addr 0000000000000000 by task syz-executor.0/3661
      
      CPU: 0 PID: 3661 Comm: syz-executor.0 Not tainted 5.1.0+ #28
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
      Call Trace:
       dump_stack+0xa9/0x10e
       ? __list_del_entry_valid+0x45/0xd0
       ? __list_del_entry_valid+0x45/0xd0
       __kasan_report+0x171/0x18d
       ? __list_del_entry_valid+0x45/0xd0
       kasan_report+0xe/0x20
       __list_del_entry_valid+0x45/0xd0
       spi_unregister_controller+0x99/0x1b0
       spi_lm70llp_attach+0x3ae/0x4b0 [spi_lm70llp]
       ? 0xffffffffc1128000
       ? klist_next+0x131/0x1e0
       ? driver_detach+0x40/0x40 [parport]
       port_check+0x3b/0x50 [parport]
       bus_for_each_dev+0x115/0x180
       ? subsys_dev_iter_exit+0x20/0x20
       __parport_register_driver+0x1f0/0x210 [parport]
       ? 0xffffffffc1150000
       do_one_initcall+0xb9/0x3b5
       ? perf_trace_initcall_level+0x270/0x270
       ? kasan_unpoison_shadow+0x30/0x40
       ? kasan_unpoison_shadow+0x30/0x40
       do_init_module+0xe0/0x330
       load_module+0x38eb/0x4270
       ? module_frob_arch_sections+0x20/0x20
       ? kernel_read_file+0x188/0x3f0
       ? find_held_lock+0x6d/0xd0
       ? fput_many+0x1a/0xe0
       ? __do_sys_finit_module+0x162/0x190
       __do_sys_finit_module+0x162/0x190
       ? __ia32_sys_init_module+0x40/0x40
       ? __mutex_unlock_slowpath+0xb4/0x3f0
       ? wait_for_completion+0x240/0x240
       ? vfs_write+0x160/0x2a0
       ? lockdep_hardirqs_off+0xb5/0x100
       ? mark_held_locks+0x1a/0x90
       ? do_syscall_64+0x14/0x2a0
       do_syscall_64+0x72/0x2a0
       entry_SYSCALL_64_after_hwframe+0x49/0xbe
      Reported-by: default avatarHulk Robot <hulkci@huawei.com>
      Fixes: 702a4879 ("spi: bitbang: Let spi_bitbang_start() take a reference to master")
      Signed-off-by: default avatarYueHaibing <yuehaibing@huawei.com>
      Reviewed-by: default avatarGeert Uytterhoeven <geert+renesas@glider.be>
      Reviewed-by: default avatarAxel Lin <axel.lin@ingics.com>
      Reviewed-by: default avatarMukesh Ojha <mojha@codeaurora.org>
      Signed-off-by: default avatarMark Brown <broonie@kernel.org>
      Signed-off-by: default avatarSasha Levin <sashal@kernel.org>
      451fd3b3