commit a06eb423367eea436351ef2a92f61a4e625cf558 Author: Greg Kroah-Hartman Date: Wed Jun 24 17:49:26 2020 +0200 Linux 5.7.6 commit 94621ff43f69c71876bc0a4bade550ea996d6cb2 Author: Jon Derrick Date: Wed May 27 10:56:17 2020 -0600 iommu/vt-d: Remove real DMA lookup in find_domain commit bba9cc2cf82840bd3c9b3f4f7edac2dc8329c241 upstream. By removing the real DMA indirection in find_domain(), we can allow sub-devices of a real DMA device to have their own valid device_domain_info. The dmar lookup and context entry removal paths have been fixed to account for sub-devices. Fixes: 2b0140c69637 ("iommu/vt-d: Use pci_real_dma_dev() for mapping") Signed-off-by: Jon Derrick Acked-by: Lu Baolu Link: https://lore.kernel.org/r/20200527165617.297470-4-jonathan.derrick@intel.com Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207575 Signed-off-by: Joerg Roedel Signed-off-by: Sushma Kalakota Signed-off-by: Greg Kroah-Hartman commit ebd56ab72b531b696061c057f4d63b9ddd8375da Author: Ahmed S. Darwish Date: Wed Jun 3 16:49:44 2020 +0200 net: core: device_rename: Use rwsem instead of a seqcount commit 11d6011c2cf29f7c8181ebde6c8bc0c4d83adcd7 upstream. Sequence counters write paths are critical sections that must never be preempted, and blocking, even for CONFIG_PREEMPTION=n, is not allowed. Commit 5dbe7c178d3f ("net: fix kernel deadlock with interface rename and netdev name retrieval.") handled a deadlock, observed with CONFIG_PREEMPTION=n, where the devnet_rename seqcount read side was infinitely spinning: it got scheduled after the seqcount write side blocked inside its own critical section. To fix that deadlock, among other issues, the commit added a cond_resched() inside the read side section. While this will get the non-preemptible kernel eventually unstuck, the seqcount reader is fully exhausting its slice just spinning -- until TIF_NEED_RESCHED is set. The fix is also still broken: if the seqcount reader belongs to a real-time scheduling policy, it can spin forever and the kernel will livelock. Disabling preemption over the seqcount write side critical section will not work: inside it are a number of GFP_KERNEL allocations and mutex locking through the drivers/base/ :: device_rename() call chain. >From all the above, replace the seqcount with a rwsem. Fixes: 5dbe7c178d3f (net: fix kernel deadlock with interface rename and netdev name retrieval.) Fixes: 30e6c9fa93cf (net: devnet_rename_seq should be a seqcount) Fixes: c91f6df2db49 (sockopt: Change getsockopt() of SO_BINDTODEVICE to return an interface name) Cc: Reported-by: kbuild test robot [ v1 missing up_read() on error exit ] Reported-by: Dan Carpenter [ v1 missing up_read() on error exit ] Signed-off-by: Ahmed S. Darwish Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit fd9757bb7044b1d01009240d0807a026b9c64038 Author: Alexander Sverdlin Date: Fri May 29 14:17:10 2020 +0200 net: octeon: mgmt: Repair filling of RX ring commit 0c34bb598c510e070160029f34efeeb217000f8d upstream. The removal of mips_swiotlb_ops exposed a problem in octeon_mgmt Ethernet driver. mips_swiotlb_ops had an mb() after most of the operations and the removal of the ops had broken the receive functionality of the driver. My code inspection has shown no other places except octeon_mgmt_rx_fill_ring() where an explicit barrier would be obviously missing. The latter function however has to make sure that "ringing the bell" doesn't happen before RX ring entry is really written. The patch has been successfully tested on Octeon II. Fixes: a999933db9ed ("MIPS: remove mips_swiotlb_ops") Cc: stable@vger.kernel.org Signed-off-by: Alexander Sverdlin Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ecd872aa3197d189f35fb122a501810924fd80e8 Author: Chen Yu Date: Fri May 22 01:59:00 2020 +0800 e1000e: Do not wake up the system via WOL if device wakeup is disabled commit 6bf6be1127f7e6d4bf39f84d56854e944d045d74 upstream. Currently the system will be woken up via WOL(Wake On LAN) even if the device wakeup ability has been disabled via sysfs: cat /sys/devices/pci0000:00/0000:00:1f.6/power/wakeup disabled The system should not be woken up if the user has explicitly disabled the wake up ability for this device. This patch clears the WOL ability of this network device if the user has disabled the wake up ability in sysfs. Fixes: bc7f75fa9788 ("[E1000E]: New pci-express e1000 driver") Reported-by: "Rafael J. Wysocki" Reviewed-by: Andy Shevchenko Cc: Signed-off-by: Chen Yu Tested-by: Aaron Brown Signed-off-by: Jeff Kirsher Signed-off-by: Greg Kroah-Hartman commit 9644d65c07e1a80221ec5156fba296f36ed886ad Author: Nicholas Piggin Date: Mon Jun 15 16:12:47 2020 +1000 powerpc/64s: Fix KVM interrupt using wrong save area commit 0bdcfa182506526fbe4e088ff9ca86a31b81828d upstream. The CTR register reload in the KVM interrupt path used the wrong save area for SLB (and NMI) interrupts. Fixes: 9600f261acaa ("powerpc/64s/exception: Move KVM test to common code") Cc: stable@vger.kernel.org # v5.7+ Reported-by: Christian Zigotzky Signed-off-by: Nicholas Piggin Tested-by: Christian Zigotzky Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200615061247.1310763-1-npiggin@gmail.com Signed-off-by: Greg Kroah-Hartman commit 579d96b83c9eb4418cb29dfa810556fea98e89c3 Author: Jiri Olsa Date: Tue May 12 17:03:18 2020 +0900 kretprobe: Prevent triggering kretprobe from within kprobe_flush_task commit 9b38cc704e844e41d9cf74e647bff1d249512cb3 upstream. Ziqian reported lockup when adding retprobe on _raw_spin_lock_irqsave. My test was also able to trigger lockdep output: ============================================ WARNING: possible recursive locking detected 5.6.0-rc6+ #6 Not tainted -------------------------------------------- sched-messaging/2767 is trying to acquire lock: ffffffff9a492798 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_hash_lock+0x52/0xa0 but task is already holding lock: ffffffff9a491a18 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_trampoline+0x0/0x50 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&(kretprobe_table_locks[i].lock)); lock(&(kretprobe_table_locks[i].lock)); *** DEADLOCK *** May be due to missing lock nesting notation 1 lock held by sched-messaging/2767: #0: ffffffff9a491a18 (&(kretprobe_table_locks[i].lock)){-.-.}, at: kretprobe_trampoline+0x0/0x50 stack backtrace: CPU: 3 PID: 2767 Comm: sched-messaging Not tainted 5.6.0-rc6+ #6 Call Trace: dump_stack+0x96/0xe0 __lock_acquire.cold.57+0x173/0x2b7 ? native_queued_spin_lock_slowpath+0x42b/0x9e0 ? lockdep_hardirqs_on+0x590/0x590 ? __lock_acquire+0xf63/0x4030 lock_acquire+0x15a/0x3d0 ? kretprobe_hash_lock+0x52/0xa0 _raw_spin_lock_irqsave+0x36/0x70 ? kretprobe_hash_lock+0x52/0xa0 kretprobe_hash_lock+0x52/0xa0 trampoline_handler+0xf8/0x940 ? kprobe_fault_handler+0x380/0x380 ? find_held_lock+0x3a/0x1c0 kretprobe_trampoline+0x25/0x50 ? lock_acquired+0x392/0xbc0 ? _raw_spin_lock_irqsave+0x50/0x70 ? __get_valid_kprobe+0x1f0/0x1f0 ? _raw_spin_unlock_irqrestore+0x3b/0x40 ? finish_task_switch+0x4b9/0x6d0 ? __switch_to_asm+0x34/0x70 ? __switch_to_asm+0x40/0x70 The code within the kretprobe handler checks for probe reentrancy, so we won't trigger any _raw_spin_lock_irqsave probe in there. The problem is in outside kprobe_flush_task, where we call: kprobe_flush_task kretprobe_table_lock raw_spin_lock_irqsave _raw_spin_lock_irqsave where _raw_spin_lock_irqsave triggers the kretprobe and installs kretprobe_trampoline handler on _raw_spin_lock_irqsave return. The kretprobe_trampoline handler is then executed with already locked kretprobe_table_locks, and first thing it does is to lock kretprobe_table_locks ;-) the whole lockup path like: kprobe_flush_task kretprobe_table_lock raw_spin_lock_irqsave _raw_spin_lock_irqsave ---> probe triggered, kretprobe_trampoline installed ---> kretprobe_table_locks locked kretprobe_trampoline trampoline_handler kretprobe_hash_lock(current, &head, &flags); <--- deadlock Adding kprobe_busy_begin/end helpers that mark code with fake probe installed to prevent triggering of another kprobe within this code. Using these helpers in kprobe_flush_task, so the probe recursion protection check is hit and the probe is never set to prevent above lockup. Link: http://lkml.kernel.org/r/158927059835.27680.7011202830041561604.stgit@devnote2 Fixes: ef53d9c5e4da ("kprobes: improve kretprobe scalability with hashed locking") Cc: Ingo Molnar Cc: "Gustavo A . R . Silva" Cc: Anders Roxell Cc: "Naveen N . Rao" Cc: Anil S Keshavamurthy Cc: David Miller Cc: Ingo Molnar Cc: Peter Zijlstra Cc: stable@vger.kernel.org Reported-by: "Ziqian SUN (Zamir)" Acked-by: Masami Hiramatsu Signed-off-by: Jiri Olsa Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 34f07405f9526e2ae8215fc5afcaf633ad5cf2ec Author: Masami Hiramatsu Date: Tue May 12 17:02:56 2020 +0900 kprobes: Fix to protect kick_kprobe_optimizer() by kprobe_mutex commit 1a0aa991a6274161c95a844c58cfb801d681eb59 upstream. In kprobe_optimizer() kick_kprobe_optimizer() is called without kprobe_mutex, but this can race with other caller which is protected by kprobe_mutex. To fix that, expand kprobe_mutex protected area to protect kick_kprobe_optimizer() call. Link: http://lkml.kernel.org/r/158927057586.27680.5036330063955940456.stgit@devnote2 Fixes: cd7ebe2298ff ("kprobes: Use text_poke_smp_batch for optimizing") Cc: Ingo Molnar Cc: "Gustavo A . R . Silva" Cc: Anders Roxell Cc: "Naveen N . Rao" Cc: Anil S Keshavamurthy Cc: David Miller Cc: Ingo Molnar Cc: Peter Zijlstra Cc: Ziqian SUN Cc: stable@vger.kernel.org Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 54d07919e881ef43225dd5fc2d4ddf5cb3a5a05d Author: Stefano Brivio Date: Mon Jun 8 10:50:29 2020 +0200 netfilter: nft_set_pipapo: Disable preemption before getting per-CPU pointer commit c3829285b2e6a0d5461078d7f6cbb2c2b4bf8c4e upstream. The lkp kernel test robot reports, with CONFIG_DEBUG_PREEMPT enabled: [ 165.316525] BUG: using smp_processor_id() in preemptible [00000000] code: nft/6247 [ 165.319547] caller is nft_pipapo_insert+0x464/0x610 [nf_tables] [ 165.321846] CPU: 1 PID: 6247 Comm: nft Not tainted 5.6.0-rc5-01595-ge32a4dc6512ce3 #1 [ 165.332128] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014 [ 165.334892] Call Trace: [ 165.336435] dump_stack+0x8f/0xcb [ 165.338128] debug_smp_processor_id+0xb2/0xc0 [ 165.340117] nft_pipapo_insert+0x464/0x610 [nf_tables] [ 165.342290] ? nft_trans_alloc_gfp+0x1c/0x60 [nf_tables] [ 165.344420] ? rcu_read_lock_sched_held+0x52/0x80 [ 165.346460] ? nft_trans_alloc_gfp+0x1c/0x60 [nf_tables] [ 165.348543] ? __mmu_interval_notifier_insert+0xa0/0xf0 [ 165.350629] nft_add_set_elem+0x5ff/0xa90 [nf_tables] [ 165.352699] ? __lock_acquire+0x241/0x1400 [ 165.354573] ? __lock_acquire+0x241/0x1400 [ 165.356399] ? reacquire_held_locks+0x12f/0x200 [ 165.358384] ? nf_tables_valid_genid+0x1f/0x40 [nf_tables] [ 165.360502] ? nla_strcmp+0x10/0x50 [ 165.362199] ? nft_table_lookup+0x4f/0xa0 [nf_tables] [ 165.364217] ? nla_strcmp+0x10/0x50 [ 165.365891] ? nf_tables_newsetelem+0xd5/0x150 [nf_tables] [ 165.367997] nf_tables_newsetelem+0xd5/0x150 [nf_tables] [ 165.370083] nfnetlink_rcv_batch+0x4fd/0x790 [nfnetlink] [ 165.372205] ? __lock_acquire+0x241/0x1400 [ 165.374058] ? __nla_validate_parse+0x57/0x8a0 [ 165.375989] ? cap_inode_getsecurity+0x230/0x230 [ 165.377954] ? security_capable+0x38/0x50 [ 165.379795] nfnetlink_rcv+0x11d/0x140 [nfnetlink] [ 165.381779] netlink_unicast+0x1b2/0x280 [ 165.383612] netlink_sendmsg+0x351/0x470 [ 165.385439] sock_sendmsg+0x5b/0x60 [ 165.387133] ____sys_sendmsg+0x200/0x280 [ 165.388871] ? copy_msghdr_from_user+0xd9/0x160 [ 165.390805] ___sys_sendmsg+0x88/0xd0 [ 165.392524] ? __might_fault+0x3e/0x90 [ 165.394273] ? sock_getsockopt+0x3d5/0xbb0 [ 165.396021] ? __handle_mm_fault+0x545/0x6a0 [ 165.397822] ? find_held_lock+0x2d/0x90 [ 165.399593] ? __sys_sendmsg+0x5e/0xa0 [ 165.401338] __sys_sendmsg+0x5e/0xa0 [ 165.402979] do_syscall_64+0x60/0x280 [ 165.404680] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 165.406621] RIP: 0033:0x7ff1fa46e783 [ 165.408299] Code: c7 c0 ff ff ff ff eb bb 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 64 8b 04 25 18 00 00 00 85 c0 75 14 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 55 c3 0f 1f 40 00 48 83 ec 28 89 54 24 1c 48 [ 165.414163] RSP: 002b:00007ffedf59ea78 EFLAGS: 00000246 ORIG_RAX: 000000000000002e [ 165.416804] RAX: ffffffffffffffda RBX: 00007ffedf59fc60 RCX: 00007ff1fa46e783 [ 165.419419] RDX: 0000000000000000 RSI: 00007ffedf59fb10 RDI: 0000000000000005 [ 165.421886] RBP: 00007ffedf59fc10 R08: 00007ffedf59ea54 R09: 0000000000000001 [ 165.424445] R10: 00007ff1fa630c6c R11: 0000000000000246 R12: 0000000000020000 [ 165.426954] R13: 0000000000000280 R14: 0000000000000005 R15: 00007ffedf59ea90 Disable preemption before accessing the lookup scratch area in nft_pipapo_insert(). Reported-by: kernel test robot Analysed-by: Florian Westphal Cc: # 5.6.x Fixes: 3c4287f62044 ("nf_tables: Add set type for arbitrary concatenation of ranges") Signed-off-by: Stefano Brivio Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit a317c1f43af53d261e05a98abc99f28474e5069b Author: Stefano Brivio Date: Wed Jun 3 01:50:11 2020 +0200 netfilter: nft_set_rbtree: Don't account for expired elements on insertion commit 33d077996a87175b155fe88030e8fec7ca76327e upstream. While checking the validity of insertion in __nft_rbtree_insert(), we currently ignore conflicting elements and intervals only if they are not active within the next generation. However, if we consider expired elements and intervals as potentially conflicting and overlapping, we'll return error for entries that should be added instead. This is particularly visible with garbage collection intervals that are comparable with the element timeout itself, as reported by Mike Dillinger. Other than the simple issue of denying insertion of valid entries, this might also result in insertion of a single element (opening or closing) out of a given interval. With single entries (that are inserted as intervals of size 1), this leads in turn to the creation of new intervals. For example: # nft add element t s { 192.0.2.1 } # nft list ruleset [...] elements = { 192.0.2.1-255.255.255.255 } Always ignore expired elements active in the next generation, while checking for conflicts. It might be more convenient to introduce a new macro that covers both inactive and expired items, as this type of check also appears quite frequently in other set back-ends. This is however beyond the scope of this fix and can be deferred to a separate patch. Other than the overlap detection cases introduced by commit 7c84d41416d8 ("netfilter: nft_set_rbtree: Detect partial overlaps on insertion"), we also have to cover the original conflict check dealing with conflicts between two intervals of size 1, which was introduced before support for timeout was introduced. This won't return an error to the user as -EEXIST is masked by nft if NLM_F_EXCL is not given, but would result in a silent failure adding the entry. Reported-by: Mike Dillinger Cc: # 5.6.x Fixes: 8d8540c4f5e0 ("netfilter: nft_set_rbtree: add timeout support") Fixes: 7c84d41416d8 ("netfilter: nft_set_rbtree: Detect partial overlaps on insertion") Signed-off-by: Stefano Brivio Acked-by: Phil Sutter Signed-off-by: Pablo Neira Ayuso Signed-off-by: Greg Kroah-Hartman commit 2ced99422116c6a05372f353734fbd2abf4f67d2 Author: Kefeng Wang Date: Wed Jun 10 01:12:44 2020 +0000 sample-trace-array: Fix sleeping function called from invalid context commit e9b7b1c0c103a623be1a65c39f98719803440871 upstream. BUG: sleeping function called from invalid context at kernel/locking/mutex.c:935 in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 0, name: swapper/5 1 lock held by swapper/5/0: #0: ffff80001002bd90 (samples/ftrace/sample-trace-array.c:38){+.-.}-{0:0}, at: call_timer_fn+0x8/0x3e0 CPU: 5 PID: 0 Comm: swapper/5 Not tainted 5.7.0+ #8 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015 Call trace: dump_backtrace+0x0/0x1a0 show_stack+0x20/0x30 dump_stack+0xe4/0x150 ___might_sleep+0x160/0x200 __might_sleep+0x58/0x90 __mutex_lock+0x64/0x948 mutex_lock_nested+0x3c/0x58 __ftrace_set_clr_event+0x44/0x88 trace_array_set_clr_event+0x24/0x38 mytimer_handler+0x34/0x40 [sample_trace_array] mutex_lock() will be called in interrupt context, using workqueue to fix it. Link: https://lkml.kernel.org/r/20200610011244.2209486-1-wangkefeng.wang@huawei.com Cc: stable@vger.kernel.org Fixes: 89ed42495ef4 ("tracing: Sample module to demonstrate kernel access to Ftrace instances.") Reviewed-by: Divya Indi Signed-off-by: Kefeng Wang Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 11afc0d281160e981feb0ebd8aaf62464ba2bf64 Author: Kefeng Wang Date: Tue Jun 9 13:52:00 2020 +0000 sample-trace-array: Remove trace_array 'sample-instance' commit 9fbc01cdba66e988122ccdc6094cfd85d9587769 upstream. Remove trace_array 'sample-instance' if kthread_run fails in sample_trace_array_init(). Link: https://lkml.kernel.org/r/20200609135200.2206726-1-wangkefeng.wang@huawei.com Cc: stable@vger.kernel.org Fixes: 89ed42495ef4a ("tracing: Sample module to demonstrate kernel access to Ftrace instances.") Reviewed-by: Divya Indi Signed-off-by: Kefeng Wang Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 94d3606b89759ddebba925976afae27671070f45 Author: Masami Hiramatsu Date: Tue Jun 16 19:14:25 2020 +0900 tools/bootconfig: Fix to return 0 if succeeded to show the bootconfig commit f91cb5b7476a603068eae31e5b2cc170dd2b9b1b upstream. Fix bootconfig to return 0 if succeeded to show the bootconfig in initrd. Without this fix, "bootconfig INITRD" command returns !0 even if the command succeeded to show the bootconfig. Link: http://lkml.kernel.org/r/159230246566.65555.11891772258543514487.stgit@devnote2 Cc: stable@vger.kernel.org Fixes: 950313ebf79c ("tools: bootconfig: Add bootconfig command") Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit ed7c2967d70b67ee546734970773641892aab947 Author: Masami Hiramatsu Date: Tue Jun 16 19:14:17 2020 +0900 tools/bootconfig: Fix to use correct quotes for value commit 272da3279df191f028fd63d1683e5ecd56fcb13b upstream. Fix bootconfig tool to select double or single quotes correctly according to the value. If a bootconfig value includes a double quote character, we must use single-quotes to quote that value. Link: http://lkml.kernel.org/r/159230245697.65555.12444299015852932304.stgit@devnote2 Cc: stable@vger.kernel.org Fixes: 950313ebf79c ("tools: bootconfig: Add bootconfig command") Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 4a9671a885769c8ec64afc5c6857ad8fa7ca5a2e Author: Masami Hiramatsu Date: Tue Jun 16 19:14:08 2020 +0900 proc/bootconfig: Fix to use correct quotes for value commit 4e264ffd953463cd14c0720eaa9315ac052f5973 upstream. Fix /proc/bootconfig to select double or single quotes corrctly according to the value. If a bootconfig value includes a double quote character, we must use single-quotes to quote that value. This modifies if() condition and blocks for avoiding double-quote in value check in 2 places. Anyway, since xbc_array_for_each_value() can handle the array which has a single node correctly. Thus, if (vnode && xbc_node_is_array(vnode)) { xbc_array_for_each_value(vnode) /* vnode->next != NULL */ ... } else { snprintf(val); /* val is an empty string if !vnode */ } is equivalent to if (vnode) { xbc_array_for_each_value(vnode) /* vnode->next can be NULL */ ... } else { snprintf(""); /* value is always empty */ } Link: http://lkml.kernel.org/r/159230244786.65555.3763894451251622488.stgit@devnote2 Cc: stable@vger.kernel.org Fixes: c1a3c36017d4 ("proc: bootconfig: Add /proc/bootconfig to show boot config list") Signed-off-by: Masami Hiramatsu Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit f7a9b2a88dce2424bda312c54e07ca6387b8b54d Author: Vamshi K Sthambamkadi Date: Mon Jun 15 20:00:38 2020 +0530 tracing/probe: Fix memleak in fetch_op_data operations commit 3aa8fdc37d16735e8891035becf25b3857d3efe0 upstream. kmemleak report: [<57dcc2ca>] __kmalloc_track_caller+0x139/0x2b0 [] kstrndup+0x37/0x80 [] parse_probe_arg.isra.7+0x3cc/0x630 [<055bf2ba>] traceprobe_parse_probe_arg+0x2f5/0x810 [<655a7766>] trace_kprobe_create+0x2ca/0x950 [<4fc6a02a>] create_or_delete_trace_kprobe+0xf/0x30 [<6d1c8a52>] trace_run_command+0x67/0x80 [] trace_parse_run_command+0xa7/0x140 [] probes_write+0x10/0x20 [<2027641c>] __vfs_write+0x30/0x1e0 [<6a4aeee1>] vfs_write+0x96/0x1b0 [<3517fb7d>] ksys_write+0x53/0xc0 [] __ia32_sys_write+0x15/0x20 [] do_syscall_32_irqs_on+0x3d/0x260 [] do_fast_syscall_32+0x39/0xb0 [] entry_SYSENTER_32+0xaf/0x102 Post parse_probe_arg(), the FETCH_OP_DATA operation type is overwritten to FETCH_OP_ST_STRING, as a result memory is never freed since traceprobe_free_probe_arg() iterates only over SYMBOL and DATA op types Setup fetch string operation correctly after fetch_op_data operation. Link: https://lkml.kernel.org/r/20200615143034.GA1734@cosmos Cc: stable@vger.kernel.org Fixes: a42e3c4de964 ("tracing/probe: Add immediate string parameter support") Acked-by: Masami Hiramatsu Signed-off-by: Vamshi K Sthambamkadi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit 932a848c73cb79bcfa435af1f2d7ba1588efdb4d Author: Steven Rostedt (VMware) Date: Tue Jun 9 22:00:41 2020 -0400 tracing: Make ftrace packed events have align of 1 commit 4649079b9de1ad86be9f4c989373adb8235a8485 upstream. When using trace-cmd on 5.6-rt for the function graph tracer, the output was corrupted. It gave output like this: funcgraph_entry: func=0xffffffff depth=38982 funcgraph_entry: func=0x1ffffffff depth=16044 funcgraph_exit: func=0xffffffff overrun=0x92539aaf00000000 calltime=0x92539c9900000072 rettime=0x100000072 depth=11084 funcgraph_exit: func=0xffffffff overrun=0x9253946e00000000 calltime=0x92539e2100000072 rettime=0x72 depth=26033702 funcgraph_entry: func=0xffffffff depth=85798 funcgraph_entry: func=0x1ffffffff depth=12044 The reason was because the tracefs/events/ftrace/funcgraph_entry/exit format file was incorrect. The -rt kernel adds more common fields to the trace events. Namely, common_migrate_disable and common_preempt_lazy_count. Each is one byte in size. This changes the alignment of the normal payload. Most events are aligned normally, but the function and function graph events are defined with a "PACKED" macro, that packs their payload. As the offsets displayed in the format files are now calculated by an aligned field, the aligned field for function and function graph events should be 1, not their normal alignment. With aligning of the funcgraph_entry event, the format file has: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:unsigned char common_migrate_disable; offset:8; size:1; signed:0; field:unsigned char common_preempt_lazy_count; offset:9; size:1; signed:0; field:unsigned long func; offset:16; size:8; signed:0; field:int depth; offset:24; size:4; signed:1; But the actual alignment is: field:unsigned short common_type; offset:0; size:2; signed:0; field:unsigned char common_flags; offset:2; size:1; signed:0; field:unsigned char common_preempt_count; offset:3; size:1; signed:0; field:int common_pid; offset:4; size:4; signed:1; field:unsigned char common_migrate_disable; offset:8; size:1; signed:0; field:unsigned char common_preempt_lazy_count; offset:9; size:1; signed:0; field:unsigned long func; offset:12; size:8; signed:0; field:int depth; offset:20; size:4; signed:1; Link: https://lkml.kernel.org/r/20200609220041.2a3b527f@oasis.local.home Cc: stable@vger.kernel.org Fixes: 04ae87a52074e ("ftrace: Rework event_create_dir()") Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Greg Kroah-Hartman commit f6f785bdf6043f9a37fad5ffeaf5bb53e5b8afe2 Author: Eric Biggers Date: Thu Jun 4 11:52:53 2020 -0700 crypto: algboss - don't wait during notifier callback commit 77251e41f89a813b4090f5199442f217bbf11297 upstream. When a crypto template needs to be instantiated, CRYPTO_MSG_ALG_REQUEST is sent to crypto_chain. cryptomgr_schedule_probe() handles this by starting a thread to instantiate the template, then waiting for this thread to complete via crypto_larval::completion. This can deadlock because instantiating the template may require loading modules, and this (apparently depending on userspace) may need to wait for the crc-t10dif module (lib/crc-t10dif.c) to be loaded. But crc-t10dif's module_init function uses crypto_register_notifier() and therefore takes crypto_chain.rwsem for write. That can't proceed until the notifier callback has finished, as it holds this semaphore for read. Fix this by removing the wait on crypto_larval::completion from within cryptomgr_schedule_probe(). It's actually unnecessary because crypto_alg_mod_lookup() calls crypto_larval_wait() itself after sending CRYPTO_MSG_ALG_REQUEST. This only actually became a problem in v4.20 due to commit b76377543b73 ("crc-t10dif: Pick better transform if one becomes available"), but the unnecessary wait was much older. BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207159 Reported-by: Mike Gerow Fixes: 398710379f51 ("crypto: algapi - Move larval completion into algboss") Cc: # v3.6+ Cc: Martin K. Petersen Signed-off-by: Eric Biggers Reported-by: Kai Lüke Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit bbb51ee56d52fd3204c66394813a17ba6e9cd27b Author: Herbert Xu Date: Fri May 29 14:54:43 2020 +1000 crypto: algif_skcipher - Cap recv SG list at ctx->used commit 7cf81954705b7e5b057f7dc39a7ded54422ab6e1 upstream. Somewhere along the line the cap on the SG list length for receive was lost. This patch restores it and removes the subsequent test which is now redundant. Fixes: 2d97591ef43d ("crypto: af_alg - consolidation of...") Cc: Signed-off-by: Herbert Xu Reviewed-by: Stephan Mueller Signed-off-by: Herbert Xu Signed-off-by: Greg Kroah-Hartman commit c0646870cb4b9b900356fbff191ae4f8640f4e7c Author: Swathi Dhanavanthri Date: Thu Mar 26 16:49:55 2020 -0700 drm/i915/tgl: Make Wa_14010229206 permanent commit 63d0f3ea8ebb67160eca281320d255c72b0cb51a upstream. This workaround now applies to all steppings, not just A0. Wa_1409085225 is a temporary A0-only W/A however it is identical to Wa_14010229206 and hence the combined workaround is made permanent. Bspec: 52890 Signed-off-by: Swathi Dhanavanthri Tested-by: Rafael Antognolli Reviewed-by: Matt Roper [mattrope: added missing blank line] Signed-off-by: Matt Roper Link: https://patchwork.freedesktop.org/patch/msgid/20200326234955.16155-1-swathi.dhanavanthri@intel.com Signed-off-by: Rodrigo Vivi Signed-off-by: Greg Kroah-Hartman commit 6674508ba1a2ea6caca5de2bcb25bc00a050fd0a Author: Harry Wentland Date: Thu May 28 09:44:44 2020 -0400 Revert "drm/amd/display: disable dcn20 abm feature for bring up" commit 14ed1c908a7a623cc0cbf0203f8201d1b7d31d16 upstream. This reverts commit 96cb7cf13d8530099c256c053648ad576588c387. This change was used for DCN2 bringup and is no longer desired. In fact it breaks backlight on DCN2 systems. Cc: Alexander Monakov Cc: Hersen Wu Cc: Anthony Koo Cc: Michael Chiu Signed-off-by: Harry Wentland Acked-by: Alex Deucher Reviewed-by: Nicholas Kazlauskas Reported-and-tested-by: Alexander Monakov Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit ab48267c35b46376010706cddf0b4ca6eb14e12e Author: Chris Wilson Date: Thu Jun 11 09:01:40 2020 +0100 drm/i915/gt: Move gen4 GT workarounds from init_clock_gating to workarounds commit 27582a9c917940bc71c0df0b8e022cbde8d735d2 upstream. Rescue the GT workarounds from being buried inside init_clock_gating so that we remember to apply them after a GT reset, and that they are included in our verification that the workarounds are applied. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200611080140.30228-6-chris@chris-wilson.co.uk (cherry picked from commit 2bcefd0d263ab4a72f0d61921ae6b0dc81606551) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 22b2d9aae9cd38e425ef8166e5b348e9be50b4b4 Author: Chris Wilson Date: Thu Jun 11 09:01:37 2020 +0100 drm/i915/gt: Move vlv GT workarounds from init_clock_gating to workarounds commit 695a2b11649e99bbf15d278042247042c42b8728 upstream. Rescue the GT workarounds from being buried inside init_clock_gating so that we remember to apply them after a GT reset, and that they are included in our verification that the workarounds are applied. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200611080140.30228-3-chris@chris-wilson.co.uk (cherry picked from commit 7331c356b6d2d8a01422cacab27478a1dba9fa2a) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit f04e0b5884098b7805ddf40fbcd641c249f2fa88 Author: Chris Wilson Date: Thu Jun 11 09:01:39 2020 +0100 drm/i915/gt: Move ilk GT workarounds from init_clock_gating to workarounds commit eacf21040aa97fd1b3c6bb201bfd43820e1c49be upstream. Rescue the GT workarounds from being buried inside init_clock_gating so that we remember to apply them after a GT reset, and that they are included in our verification that the workarounds are applied. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200611080140.30228-5-chris@chris-wilson.co.uk (cherry picked from commit 806a45c0838d253e306a6384057e851b65d11099) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 86b34963b7b3970b68428f191cef66fa10cbc51f Author: Chris Wilson Date: Thu Jun 11 09:01:38 2020 +0100 drm/i915/gt: Move snb GT workarounds from init_clock_gating to workarounds commit fd2599bda5a989c3332f4956fd7760ec32bd51ee upstream. Rescue the GT workarounds from being buried inside init_clock_gating so that we remember to apply them after a GT reset, and that they are included in our verification that the workarounds are applied. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200611080140.30228-4-chris@chris-wilson.co.uk (cherry picked from commit c3b93a943f2c9ee4a106db100a2fc3b2f126bfc5) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit f6c298aaf65ab6701654746a930362b147d042aa Author: Chris Wilson Date: Thu Jun 11 09:01:36 2020 +0100 drm/i915/gt: Move ivb GT workarounds from init_clock_gating to workarounds commit 7237b190add0794bd95979018a23eda698f2705d upstream. Rescue the GT workarounds from being buried inside init_clock_gating so that we remember to apply them after a GT reset, and that they are included in our verification that the workarounds are applied. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200611080140.30228-2-chris@chris-wilson.co.uk (cherry picked from commit 19f1f627b33385a2f0855cbc7d33d86d7f4a1e78) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 24fa6c758204c83904881e78658f5cff7980938c Author: Chris Wilson Date: Thu Jun 11 10:30:15 2020 +0100 drm/i915/gt: Move hsw GT workarounds from init_clock_gating to workarounds commit ef50fa9bd17d13d0611e39e13b37bbd3e1ea50bf upstream. Rescue the GT workarounds from being buried inside init_clock_gating so that we remember to apply them after a GT reset, and that they are included in our verification that the workarounds are applied. v2: Leave HSW_SCRATCH to set an explicit value, not or in our disable bit. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2011 Signed-off-by: Chris Wilson Cc: Mika Kuoppala Reviewed-by: Mika Kuoppala Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20200611093015.11370-1-chris@chris-wilson.co.uk (cherry picked from commit f93ec5fb563779bda4501890b1854526de58e0f1) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 79eb9f19dbd2418c25e67f70d3b2fdc98a60dbea Author: Chris Wilson Date: Tue Jun 9 16:17:23 2020 +0100 drm/i915/gt: Incrementally check for rewinding commit 8ab3a3812aa90e488813e719308ffd807b865624 upstream. In commit 5ba32c7be81e ("drm/i915/execlists: Always force a context reload when rewinding RING_TAIL"), we placed the check for rewinding a context on actually submitting the next request in that context. This was so that we only had to check once, and could do so with precision avoiding as many forced restores as possible. For example, to ensure that we can resubmit the same request a couple of times, we include a small wa_tail such that on the next submission, the ring->tail will appear to move forwards when resubmitting the same request. This is very common as it will happen for every lite-restore to fill the second port after a context switch. However, intel_ring_direction() is limited in precision to movements of upto half the ring size. The consequence being that if we tried to unwind many requests, we could exceed half the ring and flip the sense of the direction, so missing a force restore. As no request can be greater than half the ring (i.e. 2048 bytes in the smallest case), we can check for rollback incrementally. As we check against the tail that would be submitted, we do not lose any sensitivity and allow lite restores for the simple case. We still need to double check upon submitting the context, to allow for multiple preemptions and resubmissions. Fixes: 5ba32c7be81e ("drm/i915/execlists: Always force a context reload when rewinding RING_TAIL") Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: # v5.4+ Reviewed-by: Bruce Chang Reviewed-by: Mika Kuoppala Link: https://patchwork.freedesktop.org/patch/msgid/20200609151723.12971-1-chris@chris-wilson.co.uk (cherry picked from commit e36ba817fa966f81fb1c8d16f3721b5a644b2fa9) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 479c06981236d3fea7ac4cf6a4f61fe896acacc1 Author: Khaled Almahallawy Date: Mon Jun 8 13:45:37 2020 -0700 drm/i915/tc: fix the reset of ln0 commit a43555ac908c604f45ed98628805aec9355b9737 upstream. Setting ln0 similar to ln1 Fixes: 3b51be4e4061b ("drm/i915/tc: Update DP_MODE programming") Cc: # v5.5+ Signed-off-by: Khaled Almahallawy Reviewed-by: José Roberto de Souza Signed-off-by: Imre Deak Link: https://patchwork.freedesktop.org/patch/msgid/20200608204537.28468-1-khaled.almahallawy@intel.com (cherry picked from commit 4f72a8ee819d57d7329d88f487a2fc9b45153177) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 2e61678ba2383c0d10a7c862721150a37ffe4eee Author: Imre Deak Date: Fri Jun 12 15:17:31 2020 +0300 drm/i915/icl+: Fix hotplug interrupt disabling after storm detection commit a3005c2edf7e8c3478880db1ca84028a2b6819bb upstream. Atm, hotplug interrupts on TypeC ports are left enabled after detecting an interrupt storm, fix this. Reported-by: Kunal Joshi References: https://gitlab.freedesktop.org/drm/intel/-/issues/351 Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/1964 Cc: Kunal Joshi Cc: stable@vger.kernel.org Signed-off-by: Imre Deak Reviewed-by: Ville Syrjälä Link: https://patchwork.freedesktop.org/patch/msgid/20200612121731.19596-1-imre.deak@intel.com (cherry picked from commit 587a87b9d7e94927edcdea018565bc1939381eb1) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit b89722d873c7544fe74f50b7a26e3f2ae50e32ae Author: Denis Efremov Date: Fri Jun 5 20:37:43 2020 +0300 drm/amd/display: Use kvfree() to free coeff in build_regamma() commit 81921a828b94ce2816932c19a5ec74d302972833 upstream. Use kvfree() instead of kfree() to free coeff in build_regamma() because the memory is allocated with kvzalloc(). Fixes: e752058b8671 ("drm/amd/display: Optimize gamma calculations") Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov Signed-off-by: Alex Deucher Signed-off-by: Greg Kroah-Hartman commit 48d3b36959153cc427964c519b5430024fd61e10 Author: Lorenz Brun Date: Thu Jun 11 22:11:21 2020 +0200 drm/amdkfd: Use correct major in devcgroup check commit 99c7b309472787026ce52fd2bc5d00630567a872 upstream. The existing code used the major version number of the DRM driver instead of the device major number of the DRM subsystem for validating access for a devices cgroup. This meant that accesses allowed by the devices cgroup weren't permitted and certain accesses denied by the devices cgroup were permitted (if they matched the wrong major device number). Signed-off-by: Lorenz Brun Fixes: 6b855f7b83d2f ("drm/amdkfd: Check against device cgroup") Reviewed-off-by: Felix Kuehling Signed-off-by: Felix Kuehling Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit e1f81dfa5b88861a1cdda9cfd8f019ede3da7e8b Author: Jeykumar Sankaran Date: Tue Jun 2 20:37:31 2020 -0700 drm/connector: notify userspace on hotplug after register complete commit 968d81a64a883af2d16dd3f8a6ad6b67db2fde58 upstream. drm connector notifies userspace on hotplug event prematurely before late_register and mode_object register completes. This leads to a race between userspace and kernel on updating the IDR list. So, move the notification to end of connector register. Signed-off-by: Jeykumar Sankaran Signed-off-by: Steve Cohen Cc: stable@vger.kernel.org Signed-off-by: Daniel Vetter Link: https://patchwork.freedesktop.org/patch/msgid/1591155451-10393-1-git-send-email-jsanka@codeaurora.org Signed-off-by: Greg Kroah-Hartman commit f11a45d13e11a238868afa6dbe1790ae816ef8af Author: Chris Wilson Date: Mon Jun 1 17:19:42 2020 +0100 drm/i915: Whitelist context-local timestamp in the gen9 cmdparser commit 273500ae71711c040d258a7b3f4b6f44c368fff2 upstream. Allow batch buffers to read their own _local_ cumulative HW runtime of their logical context. Fixes: 0f2f39758341 ("drm/i915: Add gen9 BCS cmdparsing") Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: # v5.4+ Reviewed-by: Mika Kuoppala Link: https://patchwork.freedesktop.org/patch/msgid/20200601161942.30854-1-chris@chris-wilson.co.uk (cherry picked from commit f9496520df11de00fbafc3cbd693b9570d600ab3) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 42765cb3887c2eea8a65f665a58f42b4ee6333c1 Author: Chris Wilson Date: Fri May 22 14:27:06 2020 +0100 drm/i915/gem: Avoid iterating an empty list commit 757a9395f33c51c4e6eff2c7c0fbd50226a58224 upstream. Our __sgt_iter assumes that the scattergather list has at least one element. But during construction we may fail in allocating the first page, and so mark the first element as the terminator. This is unexpected! [22555.524752] RIP: 0010:shmem_get_pages+0x506/0x710 [i915] [22555.524759] Code: 49 8b 2c 24 31 c0 66 89 44 24 40 48 85 ed 0f 84 62 01 00 00 4c 8b 75 00 8b 5d 08 44 8b 7d 0c 48 8b 0d 7e 34 07 e2 49 83 e6 fc <49> 8b 16 41 01 df 48 89 cf 48 89 d0 48 c1 e8 2d 48 85 c9 0f 84 c8 [22555.524765] RSP: 0018:ffffc9000053f9d0 EFLAGS: 00010246 [22555.524770] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff8881ffffa000 [22555.524774] RDX: fffffffffffffff4 RSI: ffffffffffffffff RDI: ffffffff821efe00 [22555.524778] RBP: ffff8881b099ab00 R08: 0000000000000000 R09: 00000000fffffff4 [22555.524782] R10: 0000000000000002 R11: 00000000ffec0a02 R12: ffff8881cd3c8d60 [22555.524786] R13: 00000000fffffff4 R14: 0000000000000000 R15: 0000000000000000 [22555.524790] FS: 00007f4fbeb9b9c0(0000) GS:ffff8881f8580000(0000) knlGS:0000000000000000 [22555.524795] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [22555.524799] CR2: 0000000000000000 CR3: 00000001ec7f0004 CR4: 00000000001606e0 [22555.524803] Call Trace: [22555.524919] __i915_gem_object_get_pages+0x4f/0x60 [i915] Fixes: 85d1225ec066 ("drm/i915: Introduce & use new lightweight SGL iterators") Signed-off-by: Chris Wilson Cc: Matthew Auld Cc: Tvrtko Ursulin Cc: # v4.8+ Reviewed-by: Matthew Auld Reviewed-by: Maciej Patelczyk Link: https://patchwork.freedesktop.org/patch/msgid/20200522132706.5133-1-chris@chris-wilson.co.uk (cherry picked from commit 957ad9a02be6faa87594c58ac09460cd3d190d0e) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit 2a3a15090502983bfc799eeb8058afe429ef43e8 Author: Jordan Crouse Date: Fri May 1 13:43:26 2020 -0600 drm/msm: Check for powered down HW in the devfreq callbacks commit eadf79286a4badebc95af7061530bdb50a7e6f38 upstream. Writing to the devfreq sysfs nodes while the GPU is powered down can result in a system crash (on a5xx) or a nasty GMU error (on a6xx): $ /sys/class/devfreq/5000000.gpu# echo 500000000 > min_freq [ 104.841625] platform 506a000.gmu: [drm:a6xx_gmu_set_oob] *ERROR* Timeout waiting for GMU OOB set GPU_DCVS: 0x0 Despite the fact that we carefully try to suspend the devfreq device when the hardware is powered down there are lots of holes in the governors that don't check for the suspend state and blindly call into the devfreq callbacks that end up triggering hardware reads in the GPU driver. Call pm_runtime_get_if_in_use() in the gpu_busy() and gpu_set_freq() callbacks to skip the hardware access if it isn't active. v3: Only check pm_runtime_get_if_in_use() for == 0 per Eric Anholt v2: Use pm_runtime_get_if_in_use() per Eric Anholt Cc: stable@vger.kernel.org Reviewed-by: Eric Anholt Signed-off-by: Jordan Crouse Signed-off-by: Rob Clark Signed-off-by: Greg Kroah-Hartman commit fa48b63218d09c080dfcdbc04efd282ba5849d98 Author: Imre Deak Date: Thu May 14 23:45:53 2020 +0300 drm/i915: Fix AUX power domain toggling across TypeC mode resets commit d96536f0fe699729a0974eb5b65eb0d87cc747e1 upstream. Make sure to select the port's AUX power domain while holding the TC port lock. The domain depends on the port's current TC mode, which may get changed under us if we're not holding the lock. This was left out from commit 8c10e2262663 ("drm/i915: Keep the TypeC port mode fixed for detect/AUX transfers") Cc: # v5.4+ Signed-off-by: Imre Deak Reviewed-by: José Roberto de Souza Link: https://patchwork.freedesktop.org/patch/msgid/20200514204553.27193-1-imre.deak@intel.com (cherry picked from commit ae9b6cfe1352da25931bce3ea4acfd4dc1ac8a85) Signed-off-by: Joonas Lahtinen Signed-off-by: Greg Kroah-Hartman commit c1490e8258979ee03f98e0b8028b5448710188e0 Author: Dmitry V. Levin Date: Tue Jun 2 21:00:51 2020 +0300 s390: fix syscall_get_error for compat processes commit b3583fca5fb654af2cfc1c08259abb9728272538 upstream. If both the tracer and the tracee are compat processes, and gprs[2] is assigned a value by __poke_user_compat, then the higher 32 bits of gprs[2] are cleared, IS_ERR_VALUE() always returns false, and syscall_get_error() always returns 0. Fix the implementation by sign-extending the value for compat processes the same way as x86 implementation does. The bug was exposed to user space by commit 201766a20e30f ("ptrace: add PTRACE_GET_SYSCALL_INFO request") and detected by strace test suite. This change fixes strace syscall tampering on s390. Link: https://lkml.kernel.org/r/20200602180051.GA2427@altlinux.org Fixes: 753c4dd6a2fa2 ("[S390] ptrace changes") Cc: Elvira Khabirova Cc: stable@vger.kernel.org # v2.6.28+ Signed-off-by: Dmitry V. Levin Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Greg Kroah-Hartman commit 293aab21a060d9db8f6f493ed3afdf930c15653a Author: Eric Biggers Date: Mon Jun 1 13:08:05 2020 -0700 f2fs: avoid utf8_strncasecmp() with unstable name [ Upstream commit fc3bb095ab02b9e7d89a069ade2cead15c64c504 ] If the dentry name passed to ->d_compare() fits in dentry::d_iname, then it may be concurrently modified by a rename. This can cause undefined behavior (possibly out-of-bounds memory accesses or crashes) in utf8_strncasecmp(), since fs/unicode/ isn't written to handle strings that may be concurrently modified. Fix this by first copying the filename to a stack buffer if needed. This way we get a stable snapshot of the filename. Fixes: 2c2eb7a300cd ("f2fs: Support case-insensitive file name lookups") Cc: # v5.4+ Cc: Al Viro Cc: Daniel Rosenberg Cc: Gabriel Krisman Bertazi Signed-off-by: Eric Biggers Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit f526af054c18bb5bc5944b8551d25394bd02bc68 Author: Eric Biggers Date: Thu May 7 00:59:03 2020 -0700 f2fs: split f2fs_d_compare() from f2fs_match_name() [ Upstream commit f874fa1c7c7905c1744a2037a11516558ed00a81 ] Sharing f2fs_ci_compare() between comparing cached dentries (f2fs_d_compare()) and comparing on-disk dentries (f2fs_match_name()) doesn't work as well as intended, as these actions fundamentally differ in several ways (e.g. whether the task may sleep, whether the directory is stable, whether the casefolded name was precomputed, whether the dentry will need to be decrypted once we allow casefold+encrypt, etc.) Just make f2fs_d_compare() implement what it needs directly, and rework f2fs_ci_compare() to be specialized for f2fs_match_name(). Signed-off-by: Eric Biggers Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 738f369bf012f557ed165efd2dbfc976fec278b6 Author: Denis Efremov Date: Mon Jun 1 19:45:26 2020 +0300 net/mlx5: DR, Fix freeing in dr_create_rc_qp() [ Upstream commit 47a357de2b6b706af3c9471d5042f9ba8907031e ] Variable "in" in dr_create_rc_qp() is allocated with kvzalloc() and should be freed with kvfree(). Fixes: 297cccebdc5a ("net/mlx5: DR, Expose an internal API to issue RDMA operations") Cc: stable@vger.kernel.org Signed-off-by: Denis Efremov Signed-off-by: Saeed Mahameed Signed-off-by: Sasha Levin commit 6326202d7a9b39203d6e5f3873750d91fb2b0aaf Author: Lyude Paul Date: Fri Apr 3 15:47:15 2020 -0400 drm/dp_mst: Increase ACT retry timeout to 3s [ Upstream commit 873a95e0d59ac06901ae261dda0b7165ffd002b8 ] Currently we only poll for an ACT up to 30 times, with a busy-wait delay of 100µs between each attempt - giving us a timeout of 2900µs. While this might seem sensible, it would appear that in certain scenarios it can take dramatically longer then that for us to receive an ACT. On one of the EVGA MST hubs that I have available, I observed said hub sometimes taking longer then a second before signalling the ACT. These delays mostly seem to occur when previous sideband messages we've sent are NAKd by the hub, however it wouldn't be particularly surprising if it's possible to reproduce times like this simply by introducing branch devices with large LCTs since payload allocations have to take effect on every downstream device up to the payload's target. So, instead of just retrying 30 times we poll for the ACT for up to 3ms, and additionally use usleep_range() to avoid a very long and rude busy-wait. Note that the previous retry count of 30 appears to have been arbitrarily chosen, as I can't find any mention of a recommended timeout or retry count for ACTs in the DisplayPort 2.0 specification. This also goes for the range we were previously using for udelay(), although I suspect that was just copied from the recommended delay for link training on SST devices. Changes since v1: * Use readx_poll_timeout() instead of open-coding timeout loop - Sean Paul Changes since v2: * Increase poll interval to 200us - Sean Paul * Print status in hex when we timeout waiting for ACT - Sean Paul Signed-off-by: Lyude Paul Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Sean Paul Cc: # v3.17+ Reviewed-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20200406221253.1307209-4-lyude@redhat.com Signed-off-by: Sasha Levin commit 051998f097859113d9d1a13b9638a2717cbc1f31 Author: Theodore Ts'o Date: Wed Jun 10 11:16:37 2020 -0400 ext4: avoid race conditions when remounting with options that change dax [ Upstream commit 829b37b8cddb1db75c1b7905505b90e593b15db1 ] Trying to change dax mount options when remounting could allow mount options to be enabled for a small amount of time, and then the mount option change would be reverted. In the case of "mount -o remount,dax", this can cause a race where files would temporarily treated as DAX --- and then not. Cc: stable@kernel.org Reported-by: syzbot+bca9799bf129256190da@syzkaller.appspotmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 3ad517ec2b00ee3b71232787a4495011acf6cf48 Author: Xiaoguang Wang Date: Thu Jun 18 15:01:56 2020 +0800 io_uring: fix possible race condition against REQ_F_NEED_CLEANUP [ Upstream commit 6f2cc1664db20676069cff27a461ccc97dbfd114 ] In io_read() or io_write(), when io request is submitted successfully, it'll go through the below sequence: kfree(iovec); req->flags &= ~REQ_F_NEED_CLEANUP; return ret; But clearing REQ_F_NEED_CLEANUP might be unsafe. The io request may already have been completed, and then io_complete_rw_iopoll() and io_complete_rw() will be called, both of which will also modify req->flags if needed. This causes a race condition, with concurrent non-atomic modification of req->flags. To eliminate this race, in io_read() or io_write(), if io request is submitted successfully, we don't remove REQ_F_NEED_CLEANUP flag. If REQ_F_NEED_CLEANUP is set, we'll leave __io_req_aux_free() to the iovec cleanup work correspondingly. Cc: stable@vger.kernel.org Signed-off-by: Xiaoguang Wang Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit ed065aeb981a44e6325ce3a3ee96606dcf7f95ed Author: Jens Axboe Date: Wed Jun 17 15:00:04 2020 -0600 io_uring: reap poll completions while waiting for refs to drop on exit [ Upstream commit 56952e91acc93ed624fe9da840900defb75f1323 ] If we're doing polled IO and end up having requests being submitted async, then completions can come in while we're waiting for refs to drop. We need to reap these manually, as nobody else will be looking for them. Break the wait into 1/20th of a second time waits, and check for done poll completions if we time out. Otherwise we can have done poll completions sitting in ctx->poll_list, which needs us to reap them but we're just waiting for them. Cc: stable@vger.kernel.org Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 775bc2f5802ffef7abff7df92894e6328fe0bdb5 Author: Jens Axboe Date: Tue Jun 16 18:42:49 2020 -0600 io_uring: acquire 'mm' for task_work for SQPOLL [ Upstream commit 9d8426a09195e2dcf2aa249de2aaadd792d491c7 ] If we're unlucky with timing, we could be running task_work after having dropped the memory context in the sq thread. Since dropping the context requires a runnable task state, we cannot reliably drop it as part of our check-for-work loop in io_sq_thread(). Instead, abstract out the mm acquire for the sq thread into a helper, and call it from the async task work handler. Cc: stable@vger.kernel.org # v5.7 Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 0ef3e6e70a1a1bd0fd9816f2ff1d21f1f80bf462 Author: Xiaoguang Wang Date: Tue Jun 16 02:06:38 2020 +0800 io_uring: add memory barrier to synchronize io_kiocb's result and iopoll_completed [ Upstream commit bbde017a32b32d2fa8d5fddca25fade20132abf8 ] In io_complete_rw_iopoll(), stores to io_kiocb's result and iopoll completed are two independent store operations, to ensure that once iopoll_completed is ture and then req->result must been perceived by the cpu executing io_do_iopoll(), proper memory barrier should be used. And in io_do_iopoll(), we check whether req->result is EAGAIN, if it is, we'll need to issue this io request using io-wq again. In order to just issue a single smp_rmb() on the completion side, move the re-submit work to io_iopoll_complete(). Cc: stable@vger.kernel.org Signed-off-by: Xiaoguang Wang [axboe: don't set ->iopoll_completed for -EAGAIN retry] Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 3431c40a3e8df7659635601df10631f44b792f41 Author: Xiaoguang Wang Date: Tue Jun 16 02:06:37 2020 +0800 io_uring: don't fail links for EAGAIN error in IOPOLL mode [ Upstream commit 2d7d67920e5c8e0854df23ca77da2dd5880ce5dd ] In IOPOLL mode, for EAGAIN error, we'll try to submit io request again using io-wq, so don't fail rest of links if this io request has links. Cc: stable@vger.kernel.org Signed-off-by: Xiaoguang Wang Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit 25e85a0a49305fdf1775c01743baf8ace798e981 Author: Xiaoguang Wang Date: Thu Jun 11 23:39:36 2020 +0800 io_uring: fix io_kiocb.flags modification race in IOPOLL mode [ Upstream commit 65a6543da386838f935d2f03f452c5c0acff2a68 ] While testing io_uring in arm, we found sometimes io_sq_thread() keeps polling io requests even though there are not inflight io requests in block layer. After some investigations, found a possible race about io_kiocb.flags, see below race codes: 1) in the end of io_write() or io_read() req->flags &= ~REQ_F_NEED_CLEANUP; kfree(iovec); return ret; 2) in io_complete_rw_iopoll() if (res != -EAGAIN) req->flags |= REQ_F_IOPOLL_COMPLETED; In IOPOLL mode, io requests still maybe completed by interrupt, then above codes are not safe, concurrent modifications to req->flags, which is not protected by lock or is not atomic modifications. I also had disassemble io_complete_rw_iopoll() in arm: req->flags |= REQ_F_IOPOLL_COMPLETED; 0xffff000008387b18 <+76>: ldr w0, [x19,#104] 0xffff000008387b1c <+80>: orr w0, w0, #0x1000 0xffff000008387b20 <+84>: str w0, [x19,#104] Seems that the "req->flags |= REQ_F_IOPOLL_COMPLETED;" is load and modification, two instructions, which obviously is not atomic. To fix this issue, add a new iopoll_completed in io_kiocb to indicate whether io request is completed. Signed-off-by: Xiaoguang Wang Signed-off-by: Jens Axboe Signed-off-by: Greg Kroah-Hartman commit a03e50c5fdec8004759458c797c976ac1ea75321 Author: Thomas Zimmermann Date: Thu May 7 11:06:40 2020 +0200 drm/ast: Don't check new mode if CRTC is being disabled commit d6ddbd5c97d1b9156646ac5c42b8851edd664ee2 upstream. Suspending failed because there's no mode if the CRTC is being disabled. Early-out in this case. This fixes runtime PM for ast. v3: * fixed commit message v2: * added Tested-by/Reported-by tags * added Fixes tags and CC (Sam) * improved comment Signed-off-by: Thomas Zimmermann Reported-by: Cary Garrett Tested-by: Cary Garrett Reviewed-by: Daniel Vetter Fixes: b48e1b6ffd28 ("drm/ast: Add CRTC helpers for atomic modesetting") Cc: Thomas Zimmermann Cc: Gerd Hoffmann Cc: Dave Airlie Cc: Daniel Vetter Cc: Sam Ravnborg Cc: # v5.6+ Link: https://patchwork.freedesktop.org/patch/msgid/20200507090640.21561-1-tzimmermann@suse.de Signed-off-by: Greg Kroah-Hartman commit 145fa7a97a5013f10a10e702d63a9ba5bfd75813 Author: Tom Rix Date: Wed Jun 17 05:40:28 2020 -0700 selinux: fix undefined return of cond_evaluate_expr commit 8231b0b9c322c894594fb42eb0eb9f93544a6acc upstream. clang static analysis reports an undefined return security/selinux/ss/conditional.c:79:2: warning: Undefined or garbage value returned to caller [core.uninitialized.UndefReturn] return s[0]; ^~~~~~~~~~~ static int cond_evaluate_expr( ... { u32 i; int s[COND_EXPR_MAXDEPTH]; for (i = 0; i < expr->len; i++) ... return s[0]; When expr->len is 0, the loop which sets s[0] never runs. So return -1 if the loop never runs. Cc: stable@vger.kernel.org Signed-off-by: Tom Rix Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit 5b566a7959adc7e07e11df57c3f776e5c177280c Author: Tom Rix Date: Mon Jun 15 13:45:48 2020 -0700 selinux: fix a double free in cond_read_node()/cond_read_list() commit aa449a7965a6172a89d48844c313708962216f1f upstream. Clang static analysis reports this double free error security/selinux/ss/conditional.c:139:2: warning: Attempt to free released memory [unix.Malloc] kfree(node->expr.nodes); ^~~~~~~~~~~~~~~~~~~~~~~ When cond_read_node fails, it calls cond_node_destroy which frees the node but does not poison the entry in the node list. So when it returns to its caller cond_read_list, cond_read_list deletes the partial list. The latest entry in the list will be deleted twice. So instead of freeing the node in cond_read_node, let list freeing in code_read_list handle the freeing the problem node along with all of the earlier nodes. Because cond_read_node no longer does any error handling, the goto's the error case are redundant. Instead just return the error code. Cc: stable@vger.kernel.org Fixes: 60abd3181db2 ("selinux: convert cond_list to array") Signed-off-by: Tom Rix Reviewed-by: Ondrej Mosnacek [PM: subject line tweaks] Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit b3f58f50d955d5600e56e665d60f455f027c3041 Author: Tom Rix Date: Wed Jun 10 14:57:13 2020 -0700 selinux: fix double free commit 65de50969a77509452ae590e9449b70a22b923bb upstream. Clang's static analysis tool reports these double free memory errors. security/selinux/ss/services.c:2987:4: warning: Attempt to free released memory [unix.Malloc] kfree(bnames[i]); ^~~~~~~~~~~~~~~~ security/selinux/ss/services.c:2990:2: warning: Attempt to free released memory [unix.Malloc] kfree(bvalues); ^~~~~~~~~~~~~~ So improve the security_get_bools error handling by freeing these variables and setting their return pointers to NULL and the return len to 0 Cc: stable@vger.kernel.org Signed-off-by: Tom Rix Acked-by: Stephen Smalley Signed-off-by: Paul Moore Signed-off-by: Greg Kroah-Hartman commit a3d6d880d6e5af2c89d4ad7023272410e7d43755 Author: Sandeep Raghuraman Date: Thu Jun 11 01:36:26 2020 +0530 drm/amdgpu: Replace invalid device ID with a valid device ID commit 790243d3bf78f9830a3b2ffbca1ed0f528295d48 upstream. Initializes Powertune data for a specific Hawaii card by fixing what looks like a typo in the code. The device ID 66B1 is not a supported device ID for this driver, and is not mentioned elsewhere. 67B1 is a valid device ID, and is a Hawaii Pro GPU. I have tested on my R9 390 which has device ID 67B1, and it works fine without problems. Signed-off-by: Sandeep Raghuraman Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit fba8f9ef7e1405ee6f422beb874791e8a5eb489c Author: Alex Deucher Date: Tue Jun 2 17:22:48 2020 -0400 drm/amdgpu/display: use blanked rather than plane state for sync groups commit b7f839d292948142eaab77cedd031aad0bfec872 upstream. We may end up with no planes set yet, depending on the ordering, but we should have the proper blanking state which is either handled by either DPG or TG depending on the hardware generation. Check both to determine the proper blanked state. Bug: https://gitlab.freedesktop.org/drm/amd/issues/781 Fixes: 5fc0cbfad45648 ("drm/amd/display: determine if a pipe is synced by plane state") Cc: nicholas.kazlauskas@amd.com Reviewed-by: Nicholas Kazlauskas Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 482fae5b020e86d159b2baef8690de3754141be4 Author: Huacai Chen Date: Tue Mar 31 14:18:08 2020 +0800 drm/qxl: Use correct notify port address when creating cursor ring commit 80e5f89da3ab949fbbf1cae01dfaea29f5483a75 upstream. The command ring and cursor ring use different notify port addresses definition: QXL_IO_NOTIFY_CMD and QXL_IO_NOTIFY_CURSOR. However, in qxl_device_init() we use QXL_IO_NOTIFY_CMD to create both command ring and cursor ring. This doesn't cause any problems now, because QEMU's behaviors on QXL_IO_NOTIFY_CMD and QXL_IO_NOTIFY_CURSOR are the same. However, QEMU's behavior may be change in future, so let's fix it. P.S.: In the X.org QXL driver, the notify port address of cursor ring is correct. Signed-off-by: Huacai Chen Cc: Link: http://patchwork.freedesktop.org/patch/msgid/1585635488-17507-1-git-send-email-chenhc@lemote.com Signed-off-by: Gerd Hoffmann Signed-off-by: Greg Kroah-Hartman commit 5c6be713f9d0c84909a96b3978e1c543b8ea7ffd Author: Lyude Paul Date: Fri Apr 3 14:08:32 2020 -0400 drm/dp_mst: Reformat drm_dp_check_act_status() a bit commit a5cb5fa6c3a5c2cf492db667b8670ee7b044b79f upstream. Just add a bit more line wrapping, get rid of some extraneous whitespace, remove an unneeded goto label, and move around some variable declarations. No functional changes here. Signed-off-by: Lyude Paul [this isn't a fix, but it's needed for the fix that comes after this] Fixes: ad7f8a1f9ced ("drm/helper: add Displayport multi-stream helper (v0.6)") Cc: Sean Paul Cc: # v3.17+ Reviewed-by: Sean Paul Link: https://patchwork.freedesktop.org/patch/msgid/20200406221253.1307209-3-lyude@redhat.com Signed-off-by: Greg Kroah-Hartman commit ef8dcc48c6328217f327dbe03c24f06a73c63909 Author: Takashi Iwai Date: Thu Apr 16 09:54:28 2020 +0200 drm/nouveau/kms: Fix regression by audio component transition commit 61a41097e4bd4bf5d4abf3b3b58d5bf0856ce144 upstream. Since the commit 742db30c4ee6 ("drm/nouveau: Add HD-audio component notifier support"), the nouveau driver notifies and pokes the HD-audio HPD and ELD via audio component, but this seems broken. The culprit is the naive assumption that crtc->index corresponds to the HDA pin. Actually this rather corresponds to the MST dev_id (alias "pipe" in the audio component framework) while the actual port number is given from the output ior id number. This patch corrects the assignment of port and dev_id arguments in the audio component ops to recover from the HDMI/DP audio regression. Fixes: 742db30c4ee6 ("drm/nouveau: Add HD-audio component notifier support") BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207223 Cc: Signed-off-by: Takashi Iwai Signed-off-by: Ben Skeggs Signed-off-by: Greg Kroah-Hartman commit 9c58a05950695e2364b7523af778a73478e3cb9e Author: Kuninori Morimoto Date: Mon Jan 20 10:22:17 2020 +0900 sh: Convert iounmap() macros to inline functions commit 4580ba4ad2e6b8ddaada3db61d179d4dfac12047 upstream. Macro iounmap() do nothing, but that results in unused variable warnings all over the place. This patch convert it to inline to avoid warning We will get this warning without this patch ${LINUX}/drivers/thermal/broadcom/ns-thermal.c:78:21: \ warning: unused variable 'ns_thermal' [-Wunused-variable] struct ns_thermal *ns_thermal = platform_get_drvdata(pdev); ^~~~~~~~~~ Fixes: 98c90e5ea34e9 ("sh: remove __iounmap") Signed-off-by: Kuninori Morimoto Signed-off-by: Rich Felker Signed-off-by: Greg Kroah-Hartman commit 9676bb60106de8a207d486d86d5bd39baf355dff Author: Andreas Färber Date: Sat Nov 30 19:20:53 2019 +0100 arm64: dts: realtek: rtd129x: Carve out boot ROM from memory commit 3040e132beda2aee56e6ea9be8db69889bcb2e7a upstream. Update DS418j, MeLE V9, PROBOX2 AVA, Zidoo X9S and DS418 /memory nodes to exclude 0..0x1efff from reg entry and update unit address to match. Add this region to /soc ranges and for now just update the /memreserve/s. Suggested-by: Rob Herring Fixes: 72a7786c0a0d ("ARM64: dts: Add Realtek RTD1295 and Zidoo X9S") Fixes: d938a964a966 ("arm64: dts: realtek: Add ProBox2 Ava") Fixes: a9ce6f854581 ("arm64: dts: realtek: Add MeLE V9") Fixes: cf976f660ee8 ("arm64: dts: realtek: Add RTD1293 and Synology DS418j") Fixes: 5133636e41a2 ("arm64: dts: realtek: Add RTD1296 and Synology DS418") Cc: James Tai Signed-off-by: Andreas Färber Signed-off-by: Greg Kroah-Hartman commit c67831a4bb0117e2dc9a08760c5bbd47cfe1e776 Author: Andreas Färber Date: Sun Nov 10 07:02:43 2019 +0100 arm64: dts: realtek: rtd129x: Use reserved-memory for RPC regions commit 690677c22d5fa5dfdaa609a1739b75fdfb1c4a24 upstream. Move /reserved-memory node from RTD1295 to RTD129x DT. Convert RPC /memreserve/s into /reserved-memory nodes. Fixes: 72a7786c0a0d ("ARM64: dts: Add Realtek RTD1295 and Zidoo X9S") Fixes: f8b3436dad5c ("arm64: dts: realtek: Factor out common RTD129x parts") Signed-off-by: Andreas Färber Signed-off-by: Greg Kroah-Hartman commit 3db6f8f81cfc11b05f29ec0d6339191522139d1b Author: zhangyi (F) Date: Tue Jun 9 15:35:40 2020 +0800 ext4, jbd2: ensure panic by fix a race between jbd2 abort and ext4 error handlers commit 7b97d868b7ab2448859668de9222b8af43f76e78 upstream. In the ext4 filesystem with errors=panic, if one process is recording errno in the superblock when invoking jbd2_journal_abort() due to some error cases, it could be raced by another __ext4_abort() which is setting the SB_RDONLY flag but missing panic because errno has not been recorded. jbd2_journal_commit_transaction() jbd2_journal_abort() journal->j_flags |= JBD2_ABORT; jbd2_journal_update_sb_errno() | ext4_journal_check_start() | __ext4_abort() | sb->s_flags |= SB_RDONLY; | if (!JBD2_REC_ERR) | return; journal->j_flags |= JBD2_REC_ERR; Finally, it will no longer trigger panic because the filesystem has already been set read-only. Fix this by introduce j_abort_mutex to make sure journal abort is completed before panic, and remove JBD2_REC_ERR flag. Fixes: 4327ba52afd03 ("ext4, jbd2: ensure entering into panic after recording an error in superblock") Signed-off-by: zhangyi (F) Reviewed-by: Jan Kara Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20200609073540.3810702-1-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit c5e1a22df277d51745777d3028a299baa82b8551 Author: Eric Biggers Date: Mon Jun 1 13:05:43 2020 -0700 ext4: avoid utf8_strncasecmp() with unstable name commit 2ce3ee931a097e9720310db3f09c01c825a4580c upstream. If the dentry name passed to ->d_compare() fits in dentry::d_iname, then it may be concurrently modified by a rename. This can cause undefined behavior (possibly out-of-bounds memory accesses or crashes) in utf8_strncasecmp(), since fs/unicode/ isn't written to handle strings that may be concurrently modified. Fix this by first copying the filename to a stack buffer if needed. This way we get a stable snapshot of the filename. Fixes: b886ee3e778e ("ext4: Support case-insensitive file name lookups") Cc: # v5.2+ Cc: Al Viro Cc: Daniel Rosenberg Cc: Gabriel Krisman Bertazi Signed-off-by: Eric Biggers Reviewed-by: Andreas Dilger Link: https://lore.kernel.org/r/20200601200543.59417-1-ebiggers@kernel.org Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit c85e8d16f75a6e627e71a9ca8c9e7a55dfc6cccd Author: Jeffle Xu Date: Fri May 22 12:18:44 2020 +0800 ext4: fix partial cluster initialization when splitting extent commit cfb3c85a600c6aa25a2581b3c1c4db3460f14e46 upstream. Fix the bug when calculating the physical block number of the first block in the split extent. This bug will cause xfstests shared/298 failure on ext4 with bigalloc enabled occasionally. Ext4 error messages indicate that previously freed blocks are being freed again, and the following fsck will fail due to the inconsistency of block bitmap and bg descriptor. The following is an example case: 1. First, Initialize a ext4 filesystem with cluster size '16K', block size '4K', in which case, one cluster contains four blocks. 2. Create one file (e.g., xxx.img) on this ext4 filesystem. Now the extent tree of this file is like: ... 36864:[0]4:220160 36868:[0]14332:145408 51200:[0]2:231424 ... 3. Then execute PUNCH_HOLE fallocate on this file. The hole range is like: .. ext4_ext_remove_space: dev 254,16 ino 12 since 49506 end 49506 depth 1 ext4_ext_remove_space: dev 254,16 ino 12 since 49544 end 49546 depth 1 ext4_ext_remove_space: dev 254,16 ino 12 since 49605 end 49607 depth 1 ... 4. Then the extent tree of this file after punching is like ... 49507:[0]37:158047 49547:[0]58:158087 ... 5. Detailed procedure of punching hole [49544, 49546] 5.1. The block address space: ``` lblk ~49505 49506 49507~49543 49544~49546 49547~ ---------+------+-------------+----------------+-------- extent | hole | extent | hole | extent ---------+------+-------------+----------------+-------- pblk ~158045 158046 158047~158083 158084~158086 158087~ ``` 5.2. The detailed layout of cluster 39521: ``` cluster 39521 <-------------------------------> hole extent <----------------------><-------- lblk 49544 49545 49546 49547 +-------+-------+-------+-------+ | | | | | +-------+-------+-------+-------+ pblk 158084 1580845 158086 158087 ``` 5.3. The ftrace output when punching hole [49544, 49546]: - ext4_ext_remove_space (start 49544, end 49546) - ext4_ext_rm_leaf (start 49544, end 49546, last_extent [49507(158047), 40], partial [pclu 39522 lblk 0 state 2]) - ext4_remove_blocks (extent [49507(158047), 40], from 49544 to 49546, partial [pclu 39522 lblk 0 state 2] - ext4_free_blocks: (block 158084 count 4) - ext4_mballoc_free (extent 1/6753/1) 5.4. Ext4 error message in dmesg: EXT4-fs error (device vdb): mb_free_blocks:1457: group 1, block 158084:freeing already freed block (bit 6753); block bitmap corrupt. EXT4-fs error (device vdb): ext4_mb_generate_buddy:747: group 1, block bitmap and bg descriptor inconsistent: 19550 vs 19551 free clusters In this case, the whole cluster 39521 is freed mistakenly when freeing pblock 158084~158086 (i.e., the first three blocks of this cluster), although pblock 158087 (the last remaining block of this cluster) has not been freed yet. The root cause of this isuue is that, the pclu of the partial cluster is calculated mistakenly in ext4_ext_remove_space(). The correct partial_cluster.pclu (i.e., the cluster number of the first block in the next extent, that is, lblock 49597 (pblock 158086)) should be 39521 rather than 39522. Fixes: f4226d9ea400 ("ext4: fix partial cluster initialization") Signed-off-by: Jeffle Xu Reviewed-by: Eric Whitney Cc: stable@kernel.org # v3.19+ Link: https://lore.kernel.org/r/1590121124-37096-1-git-send-email-jefflexu@linux.alibaba.com Signed-off-by: Theodore Ts'o Signed-off-by: Greg Kroah-Hartman commit 456195c01fec3df9e20b0f9581d93c441109c711 Author: Sivaprakash Murugesan Date: Fri Jun 19 10:01:29 2020 +0530 pinctrl: qcom: ipq6018 Add missing pins in qpic pin group [ Upstream commit 7f5f4de83ca30a4922bb178b80144e2778faad01 ] The patch adds missing qpic data pins to qpic pingroup. These pins are necessary for the qpic nand to work. Fixes: ef1ea54eab0e ("pinctrl: qcom: Add ipq6018 pinctrl driver") Signed-off-by: Sivaprakash Murugesan Link: https://lore.kernel.org/r/1592541089-17700-1-git-send-email-sivaprak@codeaurora.org Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 50bda152c4d98ddf8f880edf21eb167758584c45 Author: Wolfram Sang Date: Mon Jun 15 09:58:10 2020 +0200 drm: encoder_slave: fix refcouting error for modules [ Upstream commit f78d4032de60f50fd4afaa0fb68ea03b985f820a ] module_put() balances try_module_get(), not request_module(). Fix the error path to match that. Fixes: 2066facca4c7 ("drm/kms: slave encoder interface.") Signed-off-by: Wolfram Sang Reviewed-by: Emil Velikov Acked-by: Daniel Vetter Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 75415eb3eca29d3c24fd5cdd31287d9388d0236c Author: Kai-Heng Feng Date: Wed Jun 3 15:48:19 2020 +0800 libata: Use per port sync for detach [ Upstream commit b5292111de9bb70cba3489075970889765302136 ] Commit 130f4caf145c ("libata: Ensure ata_port probe has completed before detach") may cause system freeze during suspend. Using async_synchronize_full() in PM callbacks is wrong, since async callbacks that are already scheduled may wait for not-yet-scheduled callbacks, causes a circular dependency. Instead of using big hammer like async_synchronize_full(), use async cookie to make sure port probe are synced, without affecting other scheduled PM callbacks. Fixes: 130f4caf145c ("libata: Ensure ata_port probe has completed before detach") Suggested-by: John Garry Signed-off-by: Kai-Heng Feng Tested-by: John Garry BugLink: https://bugs.launchpad.net/bugs/1867983 Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2d5e512b6cf7d8aef226ca7777067f89181bdec5 Author: Will Deacon Date: Fri May 29 14:12:18 2020 +0100 arm64: hw_breakpoint: Don't invoke overflow handler on uaccess watchpoints [ Upstream commit 24ebec25fb270100e252b19c288e21bd7d8cc7f7 ] Unprivileged memory accesses generated by the so-called "translated" instructions (e.g. STTR) at EL1 can cause EL0 watchpoints to fire unexpectedly if kernel debugging is enabled. In such cases, the hw_breakpoint logic will invoke the user overflow handler which will typically raise a SIGTRAP back to the current task. This is futile when returning back to the kernel because (a) the signal won't have been delivered and (b) userspace can't handle the thing anyway. Avoid invoking the user overflow handler for watchpoints triggered by kernel uaccess routines, and instead single-step over the faulting instruction as we would if no overflow handler had been installed. (Fixes tag identifies the introduction of unprivileged memory accesses, which exposed this latent bug in the hw_breakpoint code) Cc: Catalin Marinas Cc: James Morse Fixes: 57f4959bad0a ("arm64: kernel: Add support for User Access Override") Reported-by: Luis Machado Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 6fed937c9a187f7896e53e38afc55894cdb9a162 Author: Barry Song Date: Thu Jun 18 09:58:28 2020 +1200 arm64: mm: reserve hugetlb CMA after numa_init [ Upstream commit 618e07865b7453d02410c1f3407c2d78a670eabb ] hugetlb_cma_reserve() is called at the wrong place. numa_init has not been done yet. so all reserved memory will be located at node0. Fixes: cf11e85fc08c ("mm: hugetlb: optionally allocate gigantic hugepages using cma") Signed-off-by: Barry Song Reviewed-by: Anshuman Khandual Acked-by: Roman Gushchin Cc: Matthias Brugger Cc: Will Deacon Link: https://lore.kernel.org/r/20200617215828.25296-1-song.bao.hua@hisilicon.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 357db9e8ff4778c99d1a44efa1afd584d447224f Author: Ido Schimmel Date: Tue Jun 16 10:14:58 2020 +0300 mlxsw: spectrum: Adjust headroom buffers for 8x ports [ Upstream commit 60833d54d56c21e7538296eb2e00e104768fd047 ] The port's headroom buffers are used to store packets while they traverse the device's pipeline and also to store packets that are egress mirrored. On Spectrum-3, ports with eight lanes use two headroom buffers between which the configured headroom size is split. In order to prevent packet loss, multiply the calculated headroom size by two for 8x ports. Fixes: da382875c616 ("mlxsw: spectrum: Extend to support Spectrum-3 ASIC") Signed-off-by: Ido Schimmel Reviewed-by: Jiri Pirko Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit b92aa0bbfda24d89bdcddf6f5df6fe1de5531dd9 Author: Martin Date: Tue Jun 16 11:18:58 2020 +0530 bareudp: Fixed configuration to avoid having garbage values [ Upstream commit b15bb8817f991497d97ae55d8c0e349a9d1e1478 ] Code to initialize the conf structure while gathering the configuration of the device was missing. Fixes: 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.") Signed-off-by: Martin Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8db9849ddfb8a2abdd7c5b0249e312569dc38bff Author: Sven Auhagen Date: Tue Jun 16 06:35:29 2020 +0200 mvpp2: remove module bugfix [ Upstream commit 807eaf99688ce162a98a7501477644782d4af098 ] The remove function does not destroy all BM Pools when per cpu pool is active. When reloading the mvpp2 as a module the BM Pools are still active in hardware and due to the bug have twice the size now old + new. This eventually leads to a kernel crash. v2: * add Fixes tag Fixes: 7d04b0b13b11 ("mvpp2: percpu buffers") Signed-off-by: Sven Auhagen Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 4f8d723f871edb95a05d43ad88faf406c66393db Author: Jason Yan Date: Tue Jun 16 20:16:55 2020 +0800 block: Fix use-after-free in blkdev_get() [ Upstream commit 2d3a8e2deddea6c89961c422ec0c5b851e648c14 ] In blkdev_get() we call __blkdev_get() to do some internal jobs and if there is some errors in __blkdev_get(), the bdput() is called which means we have released the refcount of the bdev (actually the refcount of the bdev inode). This means we cannot access bdev after that point. But acctually bdev is still accessed in blkdev_get() after calling __blkdev_get(). This results in use-after-free if the refcount is the last one we released in __blkdev_get(). Let's take a look at the following scenerio: CPU0 CPU1 CPU2 blkdev_open blkdev_open Remove disk bd_acquire blkdev_get __blkdev_get del_gendisk bdev_unhash_inode bd_acquire bdev_get_gendisk bd_forget failed because of unhashed bdput bdput (the last one) bdev_evict_inode access bdev => use after free [ 459.350216] BUG: KASAN: use-after-free in __lock_acquire+0x24c1/0x31b0 [ 459.351190] Read of size 8 at addr ffff88806c815a80 by task syz-executor.0/20132 [ 459.352347] [ 459.352594] CPU: 0 PID: 20132 Comm: syz-executor.0 Not tainted 4.19.90 #2 [ 459.353628] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014 [ 459.354947] Call Trace: [ 459.355337] dump_stack+0x111/0x19e [ 459.355879] ? __lock_acquire+0x24c1/0x31b0 [ 459.356523] print_address_description+0x60/0x223 [ 459.357248] ? __lock_acquire+0x24c1/0x31b0 [ 459.357887] kasan_report.cold+0xae/0x2d8 [ 459.358503] __lock_acquire+0x24c1/0x31b0 [ 459.359120] ? _raw_spin_unlock_irq+0x24/0x40 [ 459.359784] ? lockdep_hardirqs_on+0x37b/0x580 [ 459.360465] ? _raw_spin_unlock_irq+0x24/0x40 [ 459.361123] ? finish_task_switch+0x125/0x600 [ 459.361812] ? finish_task_switch+0xee/0x600 [ 459.362471] ? mark_held_locks+0xf0/0xf0 [ 459.363108] ? __schedule+0x96f/0x21d0 [ 459.363716] lock_acquire+0x111/0x320 [ 459.364285] ? blkdev_get+0xce/0xbe0 [ 459.364846] ? blkdev_get+0xce/0xbe0 [ 459.365390] __mutex_lock+0xf9/0x12a0 [ 459.365948] ? blkdev_get+0xce/0xbe0 [ 459.366493] ? bdev_evict_inode+0x1f0/0x1f0 [ 459.367130] ? blkdev_get+0xce/0xbe0 [ 459.367678] ? destroy_inode+0xbc/0x110 [ 459.368261] ? mutex_trylock+0x1a0/0x1a0 [ 459.368867] ? __blkdev_get+0x3e6/0x1280 [ 459.369463] ? bdev_disk_changed+0x1d0/0x1d0 [ 459.370114] ? blkdev_get+0xce/0xbe0 [ 459.370656] blkdev_get+0xce/0xbe0 [ 459.371178] ? find_held_lock+0x2c/0x110 [ 459.371774] ? __blkdev_get+0x1280/0x1280 [ 459.372383] ? lock_downgrade+0x680/0x680 [ 459.373002] ? lock_acquire+0x111/0x320 [ 459.373587] ? bd_acquire+0x21/0x2c0 [ 459.374134] ? do_raw_spin_unlock+0x4f/0x250 [ 459.374780] blkdev_open+0x202/0x290 [ 459.375325] do_dentry_open+0x49e/0x1050 [ 459.375924] ? blkdev_get_by_dev+0x70/0x70 [ 459.376543] ? __x64_sys_fchdir+0x1f0/0x1f0 [ 459.377192] ? inode_permission+0xbe/0x3a0 [ 459.377818] path_openat+0x148c/0x3f50 [ 459.378392] ? kmem_cache_alloc+0xd5/0x280 [ 459.379016] ? entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 459.379802] ? path_lookupat.isra.0+0x900/0x900 [ 459.380489] ? __lock_is_held+0xad/0x140 [ 459.381093] do_filp_open+0x1a1/0x280 [ 459.381654] ? may_open_dev+0xf0/0xf0 [ 459.382214] ? find_held_lock+0x2c/0x110 [ 459.382816] ? lock_downgrade+0x680/0x680 [ 459.383425] ? __lock_is_held+0xad/0x140 [ 459.384024] ? do_raw_spin_unlock+0x4f/0x250 [ 459.384668] ? _raw_spin_unlock+0x1f/0x30 [ 459.385280] ? __alloc_fd+0x448/0x560 [ 459.385841] do_sys_open+0x3c3/0x500 [ 459.386386] ? filp_open+0x70/0x70 [ 459.386911] ? trace_hardirqs_on_thunk+0x1a/0x1c [ 459.387610] ? trace_hardirqs_off_caller+0x55/0x1c0 [ 459.388342] ? do_syscall_64+0x1a/0x520 [ 459.388930] do_syscall_64+0xc3/0x520 [ 459.389490] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 459.390248] RIP: 0033:0x416211 [ 459.390720] Code: 75 14 b8 02 00 00 00 0f 05 48 3d 01 f0 ff ff 0f 83 04 19 00 00 c3 48 83 ec 08 e8 0a fa ff ff 48 89 04 24 b8 02 00 00 00 0f 05 <48> 8b 3c 24 48 89 c2 e8 53 fa ff ff 48 89 d0 48 83 c4 08 48 3d 01 [ 459.393483] RSP: 002b:00007fe45dfe9a60 EFLAGS: 00000293 ORIG_RAX: 0000000000000002 [ 459.394610] RAX: ffffffffffffffda RBX: 00007fe45dfea6d4 RCX: 0000000000416211 [ 459.395678] RDX: 00007fe45dfe9b0a RSI: 0000000000000002 RDI: 00007fe45dfe9b00 [ 459.396758] RBP: 000000000076bf20 R08: 0000000000000000 R09: 000000000000000a [ 459.397930] R10: 0000000000000075 R11: 0000000000000293 R12: 00000000ffffffff [ 459.399022] R13: 0000000000000bd9 R14: 00000000004cdb80 R15: 000000000076bf2c [ 459.400168] [ 459.400430] Allocated by task 20132: [ 459.401038] kasan_kmalloc+0xbf/0xe0 [ 459.401652] kmem_cache_alloc+0xd5/0x280 [ 459.402330] bdev_alloc_inode+0x18/0x40 [ 459.402970] alloc_inode+0x5f/0x180 [ 459.403510] iget5_locked+0x57/0xd0 [ 459.404095] bdget+0x94/0x4e0 [ 459.404607] bd_acquire+0xfa/0x2c0 [ 459.405113] blkdev_open+0x110/0x290 [ 459.405702] do_dentry_open+0x49e/0x1050 [ 459.406340] path_openat+0x148c/0x3f50 [ 459.406926] do_filp_open+0x1a1/0x280 [ 459.407471] do_sys_open+0x3c3/0x500 [ 459.408010] do_syscall_64+0xc3/0x520 [ 459.408572] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 459.409415] [ 459.409679] Freed by task 1262: [ 459.410212] __kasan_slab_free+0x129/0x170 [ 459.410919] kmem_cache_free+0xb2/0x2a0 [ 459.411564] rcu_process_callbacks+0xbb2/0x2320 [ 459.412318] __do_softirq+0x225/0x8ac Fix this by delaying bdput() to the end of blkdev_get() which means we have finished accessing bdev. Fixes: 77ea887e433a ("implement in-kernel gendisk events handling") Reported-by: Hulk Robot Signed-off-by: Jason Yan Tested-by: Sedat Dilek Reviewed-by: Jan Kara Reviewed-by: Christoph Hellwig Reviewed-by: Dan Carpenter Cc: Christoph Hellwig Cc: Jens Axboe Cc: Ming Lei Cc: Jan Kara Cc: Dan Carpenter Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit ccf0cca97fa66db796c0b9be3520013f5193eb78 Author: Heiko Carstens Date: Wed Jun 10 10:36:05 2020 +0200 s390/numa: let NODES_SHIFT depend on NEED_MULTIPLE_NODES [ Upstream commit 64438e1bc0cdbe6d30bcdcb976f935eb3c297adc ] Qian Cai reported: """ When NUMA=n and nr_node_ids=2, in apply_wqattrs_prepare(), it has, for_each_node(node) { if (wq_calc_node_cpumask(... where it will trigger a booting warning, WARNING: workqueue cpumask: online intersect > possible intersect because it found 2 nodes and wq_numa_possible_cpumask[1] is an empty cpumask. """ Let NODES_SHIFT depend on NEED_MULTIPLE_NODES like it is done on other architectures in order to fix this. Fixes: 701dc81e7412 ("s390/mm: remove fake numa support") Reported-by: Qian Cai Signed-off-by: Heiko Carstens Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 749911b61da658530ca8951d46490d1ea3e0b778 Author: Dinghao Liu Date: Fri May 22 12:59:29 2020 +0800 scsi: ufs-bsg: Fix runtime PM imbalance on error [ Upstream commit a1e17eb03e69bb61bd1b1a14610436b7b9be12d9 ] When ufs_bsg_alloc_desc_buffer() returns an error code, a pairing runtime PM usage counter decrement is needed to keep the counter balanced. Link: https://lore.kernel.org/r/20200522045932.31795-1-dinghao.liu@zju.edu.cn Fixes: 74e5e468b664 (scsi: ufs-bsg: Wake the device before sending raw upiu commands) Reviewed-by: Avri Altman Signed-off-by: Dinghao Liu Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 339bd51339beeec716ca362a9f8ae60550ab9dd6 Author: Vladimir Oltean Date: Sun Jun 14 23:54:09 2020 +0300 net: dsa: sja1105: fix PTP timestamping with large tc-taprio cycles [ Upstream commit c92cbaea3cc0a80807e386922f801eb6d3652c81 ] It isn't actually described clearly at all in UM10944.pdf, but on TX of a management frame (such as PTP), this needs to happen: - The destination MAC address (i.e. 01-80-c2-00-00-0e), along with the desired destination port, need to be installed in one of the 4 management slots of the switch, over SPI. - The host can poll over SPI for that management slot's ENFPORT field. That gets unset when the switch has matched the slot to the frame. And therein lies the problem. ENFPORT does not mean that the packet has been transmitted. Just that it has been received over the CPU port, and that the mgmt slot is yet again available. This is relevant because of what we are doing in sja1105_ptp_txtstamp_skb, which is called right after sja1105_mgmt_xmit. We are in a hard real-time deadline, since the hardware only gives us 24 bits of TX timestamp, so we need to read the full PTP clock to reconstruct it. Because we're in a hurry (in an attempt to make sure that we have a full 64-bit PTP time which is as close as possible to the actual transmission time of the frame, to avoid 24-bit wraparounds), first we read the PTP clock, then we poll for the TX timestamp to become available. But of course, we don't know for sure that the frame has been transmitted when we read the full PTP clock. We had assumed that ENFPORT means it has, but the assumption is incorrect. And while in most real-life scenarios this has never been caught due to software delays, nowhere is this fact more obvious than with a tc-taprio offload, where PTP traffic gets a small timeslot very rarely (example: 1 packet per 10 ms). In that case, we will be reading the PTP clock for timestamp reconstruction too early (before the packet has been transmitted), and this renders the reconstruction procedure incorrect (see the assumptions described in the comments found on function sja1105_tstamp_reconstruct). So the PTP TX timestamps will be off by 1<<24 clock ticks, or 135 ms (1 tick is 8 ns). So fix this case of premature optimization by simply reordering the sja1105_ptpegr_ts_poll and the sja1105_ptpclkval_read function calls. It turns out that in practice, the 135 ms hard deadline for PTP timestamp wraparound is not so hard, since even the most bandwidth-intensive PTP profiles, such as 802.1AS-2011, have a sync frame interval of 125 ms. So if we couldn't deliver a timestamp in 135 ms (which we can), we're toast and have much bigger problems anyway. Fixes: 47ed985e97f5 ("net: dsa: sja1105: Add logic for TX timestamping") Signed-off-by: Vladimir Oltean Acked-by: Richard Cochran Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0085227eaed5f80c280741bd9fc75d55d3351668 Author: Vasundhara Volam Date: Sun Jun 14 19:57:10 2020 -0400 bnxt_en: Return from timer if interface is not in open state. [ Upstream commit e000940473d1423a42ef9c823fb23ccffe3f07ea ] This will avoid many uneccessary error logs when driver or firmware is in reset. Fixes: 230d1f0de754 ("bnxt_en: Handle firmware reset.") Signed-off-by: Vasundhara Volam Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit d690474e336c76cf82121ce2e8bc0915f3ad6ba3 Author: Michael Chan Date: Sun Jun 14 19:57:09 2020 -0400 bnxt_en: Fix AER reset logic on 57500 chips. [ Upstream commit 6e2f83884c099de0e87b15a820736e522755d074 ] AER reset should follow the same steps as suspend/resume. We need to free context memory during AER reset and allocate new context memory during recovery by calling bnxt_hwrm_func_qcaps(). We also need to call bnxt_reenable_sriov() to restore the VFs. Fixes: bae361c54fb6 ("bnxt_en: Improve AER slot reset.") Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a88141f15a04a946f0a483ff87e336bbd07bb6fd Author: Michael Chan Date: Sun Jun 14 19:57:08 2020 -0400 bnxt_en: Re-enable SRIOV during resume. [ Upstream commit 59ae210173ff86256fa0cdba4ea4d608c61e123d ] If VFs are enabled, we need to re-configure them during resume because firmware has been reset while resuming. Otherwise, the VFs won't work after resume. Fixes: c16d4ee0e397 ("bnxt_en: Refactor logic to re-enable SRIOV after firmware reset detected.") Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 3c8cf20c4712a5227a953b5279c73fed9d05e022 Author: Michael Chan Date: Sun Jun 14 19:57:07 2020 -0400 bnxt_en: Simplify bnxt_resume(). [ Upstream commit 2084ccf6259cc95e0575f0fafc93595d0219a9f6 ] The separate steps we do in bnxt_resume() can be done more simply by calling bnxt_hwrm_func_qcaps(). This change will add an extra __bnxt_hwrm_func_qcaps() call which is needed anyway on older firmware. Fixes: f9b69d7f6279 ("bnxt_en: Fix suspend/resume path on 57500 chips") Signed-off-by: Michael Chan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 01f20ab961db397296f5a862209b04f939532b92 Author: David Howells Date: Sun Jun 14 22:12:05 2020 +0100 afs: Fix the mapping of the UAEOVERFLOW abort code [ Upstream commit 4ec89596d06bd481ba827f3b409b938d63914157 ] Abort code UAEOVERFLOW is returned when we try and set a time that's out of range, but it's currently mapped to EREMOTEIO by the default case. Fix UAEOVERFLOW to map instead to EOVERFLOW. Found with the generic/258 xfstest. Note that the test is wrong as it assumes that the filesystem will support a pre-UNIX-epoch date. Fixes: 1eda8bab70ca ("afs: Add support for the UAE error table") Signed-off-by: David Howells Signed-off-by: Sasha Levin commit ddf4dd789fddd73e8591b8e5ad8c5332289c0ca6 Author: David Howells Date: Wed Apr 8 16:49:08 2020 +0100 afs: Remove the error argument from afs_protocol_error() [ Upstream commit 7126ead910aa9fcc9e16e9e7a8c9179658261f1d ] Remove the error argument from afs_protocol_error() as it's always -EBADMSG. Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 2b0014318da2a072d645e74a0df1c5d8d960ed10 Author: David Howells Date: Wed Apr 8 16:13:20 2020 +0100 afs: Set error flag rather than return error from file status decode [ Upstream commit 38355eec6a7d2b8f2f313f9174736dc877744e59 ] Set a flag in the call struct to indicate an unmarshalling error rather than return and handle an error from the decoding of file statuses. This flag is checked on a successful return from the delivery function. Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 2251a0f3d52ad065b92225fa90b42205df2c517a Author: David Howells Date: Thu Apr 16 14:20:32 2020 +0100 afs: Always include dir in bulk status fetch from afs_do_lookup() [ Upstream commit 13fcc6356a94558a0a4857dc00cd26b3834a1b3e ] When a lookup is done in an AFS directory, the filesystem will speculate and fetch up to 49 other statuses for files in the same directory and fetch those as well, turning them into inodes or updating inodes that already exist. However, occasionally, a callback break might go missing due to NAT timing out, but the afs filesystem doesn't then realise that the directory is not up to date. Alleviate this by using one of the status slots to check the directory in which the lookup is being done. Reported-by: Dave Botsch Suggested-by: Jeffrey Altman Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 72b655e21fcc99c0f1b17e2c3d9414d477b30dd2 Author: David Howells Date: Sat Jun 13 00:03:48 2020 +0100 afs: Fix EOF corruption [ Upstream commit 3f4aa981816368fe6b1d13c2bfbe76df9687e787 ] When doing a partial writeback, afs_write_back_from_locked_page() may generate an FS.StoreData RPC request that writes out part of a file when a file has been constructed from pieces by doing seek, write, seek, write, ... as is done by ld. The FS.StoreData RPC is given the current i_size as the file length, but the server basically ignores it unless the data length is 0 (in which case it's just a truncate operation). The revised file length returned in the result of the RPC may then not reflect what we suggested - and this leads to i_size getting moved backwards - which causes issues later. Fix the client to take account of this by ignoring the returned file size unless the data version number jumped unexpectedly - in which case we're going to have to clear the pagecache and reload anyway. This can be observed when doing a kernel build on an AFS mount. The following pair of commands produce the issue: ld -m elf_x86_64 -z max-page-size=0x200000 --emit-relocs \ -T arch/x86/realmode/rm/realmode.lds \ arch/x86/realmode/rm/header.o \ arch/x86/realmode/rm/trampoline_64.o \ arch/x86/realmode/rm/stack.o \ arch/x86/realmode/rm/reboot.o \ -o arch/x86/realmode/rm/realmode.elf arch/x86/tools/relocs --realmode \ arch/x86/realmode/rm/realmode.elf \ >arch/x86/realmode/rm/realmode.relocs This results in the latter giving: Cannot read ELF section headers 0/18: Success as the realmode.elf file got corrupted. The sequence of events can also be driven with: xfs_io -t -f \ -c "pwrite -S 0x58 0 0x58" \ -c "pwrite -S 0x59 10000 1000" \ -c "close" \ /afs/example.com/scratch/a Fixes: 31143d5d515e ("AFS: implement basic file write support") Signed-off-by: David Howells Signed-off-by: Sasha Levin commit cd7ec922b044964f8bb900ed032bc97013bf7fac Author: David Howells Date: Fri Jun 12 23:58:51 2020 +0100 afs: afs_write_end() should change i_size under the right lock [ Upstream commit 1f32ef79897052ef7d3d154610d8d6af95abde83 ] Fix afs_write_end() to change i_size under vnode->cb_lock rather than ->wb_lock so that it doesn't race with afs_vnode_commit_status() and afs_getattr(). The ->wb_lock is only meant to guard access to ->wb_keys which isn't accessed by that piece of code. Fixes: 4343d00872e1 ("afs: Get rid of the afs_writeback record") Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 467f654f800ca470593ced33e69c5d22925b8bd3 Author: David Howells Date: Fri Jun 12 00:15:13 2020 +0100 afs: Fix non-setting of mtime when writing into mmap [ Upstream commit bb413489288e4e457353bac513fddb6330d245ca ] The mtime on an inode needs to be updated when a write is made into an mmap'ed section. There are three ways in which this could be done: update it when page_mkwrite is called, update it when a page is changed from dirty to writeback or leave it to the server and fix the mtime up from the reply to the StoreData RPC. Found with the generic/215 xfstest. Fixes: 1cf7a1518aef ("afs: Implement shared-writeable mmap") Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 1357148122938a09e3562512081c252446990eb2 Author: Aneesh Kumar K.V Date: Sun May 24 15:08:19 2020 +0530 powerpc: Fix kernel crash in show_instructions() w/DEBUG_VIRTUAL [ Upstream commit a6e2c226c3d51fd93636320e47cabc8a8f0824c5 ] With CONFIG_DEBUG_VIRTUAL=y, we can hit a BUG() if we take a hard lockup watchdog interrupt when in OPAL mode. This happens in show_instructions() if the kernel takes the watchdog NMI IPI, or any other interrupt, with MSR_IR == 0. show_instructions() updates the variable pc in the loop and the second iteration will result in BUG(). We hit the BUG_ON due the below check in __va() #define __va(x) ({ VIRTUAL_BUG_ON((unsigned long)(x) >= PAGE_OFFSET); (void *)(unsigned long)((phys_addr_t)(x) | PAGE_OFFSET); }) Fix it by moving the check out of the loop. Also update nip so that the nip == pc check still matches. Fixes: 4dd7554a6456 ("powerpc/64: Add VIRTUAL_BUG_ON checks for __va and __pa addresses") Signed-off-by: Aneesh Kumar K.V [mpe: Use IS_ENABLED(), massage change log] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200524093822.423487-1-aneesh.kumar@linux.ibm.com Signed-off-by: Sasha Levin commit 7458d93ac4ca5056c92841bdb44b204bdb41677b Author: Dan Carpenter Date: Fri Jun 5 14:03:39 2020 +0300 crypto: marvell/octeontx - Fix a potential NULL dereference [ Upstream commit 1f5b07f5dd1748a6f9363fb1a76d599c74af8231 ] Smatch reports that: drivers/crypto/marvell/octeontx/otx_cptvf_algs.c:132 otx_cpt_aead_callback() warn: variable dereferenced before check 'cpt_info' (see line 121) This function is called from process_pending_queue() as: drivers/crypto/marvell/octeontx/otx_cptvf_reqmgr.c 599 /* 600 * Call callback after current pending entry has been 601 * processed, we don't do it if the callback pointer is 602 * invalid. 603 */ 604 if (callback) 605 callback(res_code, areq, cpt_info); It does appear to me that "cpt_info" can be NULL so this could lead to a NULL dereference. Fixes: 10b4f09491bf ("crypto: marvell - add the Virtual Function driver for CPT") Signed-off-by: Dan Carpenter Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit ea91187b906d2252bcb0c6de610768a4fb517045 Author: Herbert Xu Date: Thu Jun 4 17:37:50 2020 +1000 crypto: hisilicon - Cap block size at 2^31 [ Upstream commit c61e5644c69775ae9d54b86018fca238aca64a9b ] The function hisi_acc_create_sg_pool may allocate a block of memory of size PAGE_SIZE * 2^(MAX_ORDER - 1). This value may exceed 2^31 on ia64, which would overflow the u32. This patch caps it at 2^31. Reported-by: kernel test robot Fixes: d8ac7b85236b ("crypto: hisilicon - fix large sgl memory...") Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 4813dd656732207ad9df7738652bbbbde4c7c928 Author: Zhiqiang Liu Date: Mon Jun 15 00:53:30 2020 +0800 bcache: fix potential deadlock problem in btree_gc_coalesce [ Upstream commit be23e837333a914df3f24bf0b32e87b0331ab8d1 ] coccicheck reports: drivers/md//bcache/btree.c:1538:1-7: preceding lock on line 1417 In btree_gc_coalesce func, if the coalescing process fails, we will goto to out_nocoalesce tag directly without releasing new_nodes[i]->write_lock. Then, it will cause a deadlock when trying to acquire new_nodes[i]-> write_lock for freeing new_nodes[i] before return. btree_gc_coalesce func details as follows: if alloc new_nodes[i] fails: goto out_nocoalesce; // obtain new_nodes[i]->write_lock mutex_lock(&new_nodes[i]->write_lock) // main coalescing process for (i = nodes - 1; i > 0; --i) [snipped] if coalescing process fails: // Here, directly goto out_nocoalesce // tag will cause a deadlock goto out_nocoalesce; [snipped] // release new_nodes[i]->write_lock mutex_unlock(&new_nodes[i]->write_lock) // coalesing succ, return return; out_nocoalesce: btree_node_free(new_nodes[i]) // free new_nodes[i] // obtain new_nodes[i]->write_lock mutex_lock(&new_nodes[i]->write_lock); // set flag for reuse clear_bit(BTREE_NODE_dirty, &ew_nodes[i]->flags); // release new_nodes[i]->write_lock mutex_unlock(&new_nodes[i]->write_lock); To fix the problem, we add a new tag 'out_unlock_nocoalesce' for releasing new_nodes[i]->write_lock before out_nocoalesce tag. If coalescing process fails, we will go to out_unlock_nocoalesce tag for releasing new_nodes[i]->write_lock before free new_nodes[i] in out_nocoalesce tag. (Coly Li helps to clean up commit log format.) Fixes: 2a285686c109816 ("bcache: btree locking rework") Signed-off-by: Zhiqiang Liu Signed-off-by: Coly Li Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2f79d8ab7f717c6a5d2ec21d89fe686094ddc03e Author: yangerkun Date: Mon Jun 1 15:34:04 2020 +0800 ext4: stop overwrite the errcode in ext4_setup_super [ Upstream commit 5adaccac46ea79008d7b75f47913f1a00f91d0ce ] Now the errcode from ext4_commit_super will overwrite EROFS exists in ext4_setup_super. Actually, no need to call ext4_commit_super since we will return EROFS. Fix it by goto done directly. Fixes: c89128a00838 ("ext4: handle errors on ext4_commit_super") Signed-off-by: yangerkun Reviewed-by: Jan Kara Link: https://lore.kernel.org/r/20200601073404.3712492-1-yangerkun@huawei.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 4e3f8bb50cd0dee2f74c91c557ef7cc7cc4fe440 Author: Ian Rogers Date: Mon Jun 8 22:36:09 2020 -0700 perf parse-events: Fix an incompatible pointer [ Upstream commit c2412fae3f01725615b0de472095a9e16ed30ca9 ] Arrays are pointer types and don't need their address taking. Fixes: 8255718f4bed (perf pmu: Expand PMU events by prefix match) Signed-off-by: Ian Rogers Cc: Alexander Shishkin Cc: Andi Kleen Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Stephane Eranian Link: http://lore.kernel.org/lkml/20200609053610.206588-1-irogers@google.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 7b39d9f170ff3bde41653d6b28a99c31b28a8723 Author: Sumanth Korikkar Date: Tue Jun 9 10:10:18 2020 +0200 perf probe: Fix user attribute access in kprobes [ Upstream commit 9256c3031eb9beafa3957c61093104c3c75a6148 ] Issue: # perf probe -a 'do_sched_setscheduler pid policy param->sched_priority@user' did not work before. Fix: Make: # perf probe -a 'do_sched_setscheduler pid policy param->sched_priority@user' output equivalent to ftrace: # echo 'p:probe/do_sched_setscheduler _text+517384 pid=%r2:s32 policy=%r3:s32 sched_priority=+u0(%r4):s32' > /sys/kernel/debug/tracing/kprobe_events Other: 1. Right now, __match_glob() does not handle [u]. For now, use *u]. 2. @user attribute was introduced in commit 1e032f7cfa14 ("perf-probe: Add user memory access attribute support") Test: 1. perf probe -a 'do_sched_setscheduler pid policy param->sched_priority@user' 2 ./perf script sched 305669 [000] 1614458.838675: perf_bpf_probe:func: (2904e508) pid=261614 policy=2 sched_priority=1 3. cat /sys/kernel/debug/tracing/trace <...>-309956 [006] .... 1616098.093957: 0: prio: 1 Committer testing: Before: # perf probe -a 'do_sched_setscheduler pid policy param->sched_priority@user' param(type:sched_param) has no member sched_priority@user. Error: Failed to add events. # pahole sched_param struct sched_param { int sched_priority; /* 0 4 */ /* size: 4, cachelines: 1, members: 1 */ /* last cacheline: 4 bytes */ }; # After: # perf probe -a 'do_sched_setscheduler pid policy param->sched_priority@user' Added new event: probe:do_sched_setscheduler (on do_sched_setscheduler with pid policy sched_priority=param->sched_priority) You can now use it in all perf tools, such as: perf record -e probe:do_sched_setscheduler -aR sleep 1 # cat /sys/kernel/debug/tracing/kprobe_events p:probe/do_sched_setscheduler _text+1113792 pid=%di:s32 policy=%si:s32 sched_priority=+u0(%dx):s32 # Fixes: 1e032f7cfa14 ("perf-probe: Add user memory access attribute support") Signed-off-by: Sumanth Korikkar Reviewed-by: Thomas Richter Acked-by: Masami Hiramatsu Tested-by: Arnaldo Carvalho de Melo Cc: Heiko Carstens Cc: Ilya Leoshkevich Cc: Jiri Olsa Cc: Steven Rostedt (VMware) Cc: bpf@vger.kernel.org LPU-Reference: 20200609081019.60234-2-sumanthk@linux.ibm.com Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 4f519c4a3576fe4c2f1fc359bbefa1b9df204126 Author: Hongbo Yao Date: Fri Jun 5 17:17:40 2020 +0800 perf stat: Fix NULL pointer dereference [ Upstream commit c0c652fc705de75f4ba52e93053acc1ed3933e74 ] If config->aggr_map is NULL and config->aggr_get_id is not NULL, the function print_aggr() will still calling arrg_update_shadow(), which can result in accessing the invalid pointer. Fixes: 088519f318be ("perf stat: Move the display functions to stat-display.c") Signed-off-by: Hongbo Yao Cc: Alexander Shishkin Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Wei Li Link: https://lore.kernel.org/lkml/20200608163625.GC3073@kernel.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 1ba339548f44c941331a2b5266162e9b6dc25532 Author: Gaurav Singh Date: Mon Jun 8 13:18:17 2020 -0300 perf report: Fix NULL pointer dereference in hists__fprintf_nr_sample_events() [ Upstream commit 11b6e5482e178055ec1f2444b55f2518713809d1 ] The 'evname' variable can be NULL, as it is checked a few lines back, check it before using. Fixes: 9e207ddfa207 ("perf report: Show call graph from reference events") Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Ingo Molnar Cc: Jiri Olsa Cc: Kan Liang Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Link: http://lore.kernel.org/lkml/ Signed-off-by: Gaurav Singh Signed-off-by: Sasha Levin commit adcceb7b05d84d73727b28bafa9cc18229338dbc Author: Qais Yousef Date: Mon May 18 16:49:31 2020 +0100 usb/ehci-platform: Set PM runtime as active on resume [ Upstream commit 16bdc04cc98ab0c74392ceef2475ecc5e73fcf49 ] Follow suit of ohci-platform.c and perform pm_runtime_set_active() on resume. ohci-platform.c had a warning reported due to the missing pm_runtime_set_active() [1]. [1] https://lore.kernel.org/lkml/20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/ Acked-by: Alan Stern Signed-off-by: Qais Yousef CC: Tony Prisk CC: Greg Kroah-Hartman CC: Mathias Nyman CC: Oliver Neukum CC: linux-arm-kernel@lists.infradead.org CC: linux-usb@vger.kernel.org CC: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20200518154931.6144-3-qais.yousef@arm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b7f37b35f7ead11669fcd87ec0e1dccd98d26331 Author: Qais Yousef Date: Mon May 18 16:49:30 2020 +0100 usb/xhci-plat: Set PM runtime as active on resume [ Upstream commit 79112cc3c29f4a8c73a21428fbcbcb0afb005e3e ] Follow suit of ohci-platform.c and perform pm_runtime_set_active() on resume. ohci-platform.c had a warning reported due to the missing pm_runtime_set_active() [1]. [1] https://lore.kernel.org/lkml/20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/ Signed-off-by: Qais Yousef CC: Tony Prisk CC: Greg Kroah-Hartman CC: Mathias Nyman CC: Oliver Neukum CC: linux-arm-kernel@lists.infradead.org CC: linux-usb@vger.kernel.org CC: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20200518154931.6144-2-qais.yousef@arm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit bd12abafd9c173e3ee4a6179ae940d106987acf8 Author: Andrii Nakryiko Date: Fri Jun 12 17:21:15 2020 -0700 bpf: Undo internal BPF_PROBE_MEM in BPF insns dump [ Upstream commit 29fcb05bbf1a7008900bb9bee347bdbfc7171036 ] BPF_PROBE_MEM is kernel-internal implmementation details. When dumping BPF instructions to user-space, it needs to be replaced back with BPF_MEM mode. Fixes: 2a02759ef5f8 ("bpf: Add support for BTF pointers to interpreter") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200613002115.1632142-1-andriin@fb.com Signed-off-by: Sasha Levin commit 845357b602f6f2e0e3b47425e8764947460c7aa2 Author: Andrii Nakryiko Date: Fri Jun 12 12:45:04 2020 -0700 libbpf: Support pre-initializing .bss global variables [ Upstream commit caf62492f479585296e9d636c798d5ac256b7b04 ] Remove invalid assumption in libbpf that .bss map doesn't have to be updated in kernel. With addition of skeleton and memory-mapped initialization image, .bss doesn't have to be all zeroes when BPF map is created, because user-code might have initialized those variables from user-space. Fixes: eba9c5f498a1 ("libbpf: Refactor global data map initialization") Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200612194504.557844-1-andriin@fb.com Signed-off-by: Sasha Levin commit 14b3a7fef8d6b37315de543dc2122939cbd0066f Author: Andrey Ignatov Date: Thu Jun 11 17:08:57 2020 -0700 bpf: Fix memlock accounting for sock_hash [ Upstream commit 60e5ca8a64bad8f3e2e20a1e57846e497361c700 ] Add missed bpf_map_charge_init() in sock_hash_alloc() and correspondingly bpf_map_charge_finish() on ENOMEM. It was found accidentally while working on unrelated selftest that checks "map->memory.pages > 0" is true for all map types. Before: # bpftool m l ... 3692: sockhash name m_sockhash flags 0x0 key 4B value 4B max_entries 8 memlock 0B After: # bpftool m l ... 84: sockmap name m_sockmap flags 0x0 key 4B value 4B max_entries 8 memlock 4096B Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Andrey Ignatov Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200612000857.2881453-1-rdna@fb.com Signed-off-by: Sasha Levin commit 032f8eb4b9cec71a6e2ec47a846b293401bbea74 Author: Lorenz Bauer Date: Thu Jun 11 18:25:20 2020 +0100 bpf: sockmap: Don't attach programs to UDP sockets [ Upstream commit f6fede8569689dd31e7b0ed15024b25e5ce2e2e5 ] The stream parser infrastructure isn't set up to deal with UDP sockets, so we mustn't try to attach programs to them. I remember making this change at some point, but I must have lost it while rebasing or something similar. Fixes: 7b98cd42b049 ("bpf: sockmap: Add UDP support") Signed-off-by: Lorenz Bauer Signed-off-by: Alexei Starovoitov Acked-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20200611172520.327602-1-lmb@cloudflare.com Signed-off-by: Sasha Levin commit 511db12b4dca2b1954004999d4ea328e9b6ea6f6 Author: Alex Elder Date: Thu Jun 11 14:48:32 2020 -0500 net: ipa: program upper nibbles of sequencer type [ Upstream commit 636edeaad5577b6023f0de2b98a010d1cea73607 ] The upper two nibbles of the sequencer type were not used for SDM845, and were assumed to be 0. But for SC7180 they are used, and so they must be programmed by ipa_endpoint_init_seq(). Fix this bug. IPA_SEQ_PKT_PROCESS_NO_DEC_NO_UCP_DMAP doesn't have a descriptive comment, so add one. Signed-off-by: Alex Elder Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a0a178fcba05aa655cecb900c4654870536009e6 Author: Brett Creeley Date: Fri Jun 5 10:09:43 2020 -0700 iavf: fix speed reporting over virtchnl [ Upstream commit e0ef26fbe2b0c62f42ba7667076dc38b693b6fb8 ] Link speeds are communicated over virtchnl using an enum virtchnl_link_speed. Currently, the highest link speed is 40Gbps which leaves us unable to reflect some speeds that an ice VF is capable of. This causes link speed to be misreported on the iavf driver. Allow for communicating link speeds using Mbps so that the proper speed can be reported for an ice VF. Moving away from the enum allows us to communicate future speed changes without requiring a new enum to be added. In order to support communicating link speeds over virtchnl in Mbps the following functionality was added: - Added u32 link_speed_mbps in the iavf_adapter structure. - Added the macro ADV_LINK_SUPPORT(_a) to determine if the VF driver supports communicating link speeds in Mbps. - Added the function iavf_get_vpe_link_status() to fill the correct link_status in the event_data union based on the ADV_LINK_SUPPORT(_a) macro. - Added the function iavf_set_adapter_link_speed_from_vpe() to determine whether or not to fill the u32 link_speed_mbps or enum virtchnl_link_speed link_speed field in the iavf_adapter structure based on the ADV_LINK_SUPPORT(_a) macro. - Do not free vf_res in iavf_init_get_resources() as vf_res will be accessed in iavf_get_link_ksettings(); memset to 0 instead. This memory is subsequently freed in iavf_remove(). Fixes: 7c710869d64e ("ice: Add handlers for VF netdevice operations") Signed-off-by: Brett Creeley Signed-off-by: Sergey Nemov Signed-off-by: Paul Greenwalt Signed-off-by: Tony Nguyen Signed-off-by: Jeff Kirsher Signed-off-by: Sasha Levin commit 47b8c7029217946566d1ab9877e10a2fecf4bfa9 Author: Li RongQing Date: Thu Jun 11 13:11:06 2020 +0800 xdp: Fix xsk_generic_xmit errno [ Upstream commit aa2cad0600ed2ca6a0ab39948d4db1666b6c962b ] Propagate sock_alloc_send_skb error code, not set it to EAGAIN unconditionally, when fail to allocate skb, which might cause that user space unnecessary loops. Fixes: 35fcde7f8deb ("xsk: support for Tx") Signed-off-by: Li RongQing Signed-off-by: Daniel Borkmann Acked-by: Björn Töpel Link: https://lore.kernel.org/bpf/1591852266-24017-1-git-send-email-lirongqing@baidu.com Signed-off-by: Sasha Levin commit 3f88bed323d5a6428661c9643c0bac102ac3fbc3 Author: Chuck Lever Date: Fri May 29 14:14:40 2020 -0400 NFS: Fix direct WRITE throughput regression [ Upstream commit ba838a75e73f55a780f1ee896b8e3ecb032dba0f ] I measured a 50% throughput regression for large direct writes. The observed on-the-wire behavior is that the client sends every NFS WRITE twice: once as an UNSTABLE WRITE plus a COMMIT, and once as a FILE_SYNC WRITE. This is because the nfs_write_match_verf() check in nfs_direct_commit_complete() fails for every WRITE. Buffered writes use nfs_write_completion(), which sets req->wb_verf correctly. Direct writes use nfs_direct_write_completion(), which does not set req->wb_verf at all. This leaves req->wb_verf set to all zeroes for every direct WRITE, and thus nfs_direct_commit_completion() always sets NFS_ODIRECT_RESCHED_WRITES. This fix appears to restore nearly all of the lost performance. Fixes: 1f28476dcb98 ("NFS: Fix O_DIRECT commit verifier handling") Signed-off-by: Chuck Lever Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 411eb103c39253607e5f09a5184e66aaa7562369 Author: Zheng Bin Date: Thu May 21 17:17:21 2020 +0800 nfs: set invalid blocks after NFSv4 writes [ Upstream commit 3a39e778690500066b31fe982d18e2e394d3bce2 ] Use the following command to test nfsv4(size of file1M is 1MB): mount -t nfs -o vers=4.0,actimeo=60 127.0.0.1/dir1 /mnt cp file1M /mnt du -h /mnt/file1M -->0 within 60s, then 1M When write is done(cp file1M /mnt), will call this: nfs_writeback_done nfs4_write_done nfs4_write_done_cb nfs_writeback_update_inode nfs_post_op_update_inode_force_wcc_locked(change, ctime, mtime nfs_post_op_update_inode_force_wcc_locked nfs_set_cache_invalid nfs_refresh_inode_locked nfs_update_inode nfsd write response contains change, ctime, mtime, the flag will be clear after nfs_update_inode. Howerver, write response does not contain space_used, previous open response contains space_used whose value is 0, so inode->i_blocks is still 0. nfs_getattr -->called by "du -h" do_update |= force_sync || nfs_attribute_cache_expired -->false in 60s cache_validity = READ_ONCE(NFS_I(inode)->cache_validity) do_update |= cache_validity & (NFS_INO_INVALID_ATTR -->false if (do_update) { __nfs_revalidate_inode } Within 60s, does not send getattr request to nfsd, thus "du -h /mnt/file1M" is 0. Add a NFS_INO_INVALID_BLOCKS flag, set it when nfsv4 write is done. Fixes: 16e143751727 ("NFS: More fine grained attribute tracking") Signed-off-by: Zheng Bin Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 1292f619e706001f8b536102564b8b4aaadab1d4 Author: Christoph Hellwig Date: Wed Jun 3 08:24:17 2020 +0200 nvme-pci: use simple suspend when a HMB is enabled [ Upstream commit b97120b15ebd3de51325084136d3b9c3cce656d6 ] While the NVMe specification allows the device to access the host memory buffer in host DRAM from all power states, hosts will fail access to DRAM during S3 and similar power states. Fixes: d916b1be94b6 ("nvme-pci: use host managed power state for suspend") Signed-off-by: Christoph Hellwig Reviewed-by: Keith Busch Reviewed-by: Sagi Grimberg Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 00f08a9998e84d11a5459fb32a3fd428e89b2f57 Author: Daniel Wagner Date: Fri May 29 13:37:40 2020 +0200 nvme-fc: don't call nvme_cleanup_cmd() for AENs [ Upstream commit c9c12e51b82b2bd0c59ac4e27ee5427f382a503f ] Asynchronous event notifications do not have an associated request. When fcp_io() fails we unconditionally call nvme_cleanup_cmd() which leads to a crash. Fixes: 16686f3a6c3c ("nvme: move common call to nvme_cleanup_cmd to core layer") Signed-off-by: Daniel Wagner Reviewed-by: Himanshu Madhani Reviewed-by: Hannes Reinecke Reviewed-by: James Smart Signed-off-by: Christoph Hellwig Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 2c207411b808256f92b24e5d61b0f31089b268ed Author: Tobias Klauser Date: Wed Jun 10 15:08:04 2020 +0200 tools, bpftool: Fix memory leak in codegen error cases [ Upstream commit d4060ac969563113101c79433f2ae005feca1c29 ] Free the memory allocated for the template on error paths in function codegen. Signed-off-by: Tobias Klauser Signed-off-by: Daniel Borkmann Acked-by: Andrii Nakryiko Link: https://lore.kernel.org/bpf/20200610130804.21423-1-tklauser@distanz.ch Signed-off-by: Sasha Levin commit 8e337f731d86f422101f16f234cb961be9ed06d8 Author: YiFei Zhu Date: Wed Jun 10 13:41:39 2020 -0500 net/filter: Permit reading NET in load_bytes_relative when MAC not set [ Upstream commit 0f5d82f187e1beda3fe7295dfc500af266a5bd80 ] Added a check in the switch case on start_header that checks for the existence of the header, and in the case that MAC is not set and the caller requests for MAC, -EFAULT. If the caller requests for NET then MAC's existence is completely ignored. There is no function to check NET header's existence and as far as cgroup_skb/egress is concerned it should always be set. Removed for ptr >= the start of header, considering offset is bounded unsigned and should always be true. len <= end - mac is redundant to ptr + len <= end. Fixes: 3eee1f75f2b9 ("bpf: fix bpf_skb_load_bytes_relative pkt length check") Signed-off-by: YiFei Zhu Signed-off-by: Daniel Borkmann Reviewed-by: Stanislav Fomichev Link: https://lore.kernel.org/bpf/76bb820ddb6a95f59a772ecbd8c8a336f646b362.1591812755.git.zhuyifei@google.com Signed-off-by: Sasha Levin commit 55bcbfd8648209d581f85a84999c13c804aab1df Author: Tony Luck Date: Wed May 27 11:28:08 2020 -0700 x86/mce/dev-mcelog: Fix -Wstringop-truncation warning about strncpy() [ Upstream commit 7ccddc4613db446dc3cbb69a3763ba60ec651d13 ] The kbuild test robot reported this warning: arch/x86/kernel/cpu/mce/dev-mcelog.c: In function 'dev_mcelog_init_device': arch/x86/kernel/cpu/mce/dev-mcelog.c:346:2: warning: 'strncpy' output \ truncated before terminating nul copying 12 bytes from a string of the \ same length [-Wstringop-truncation] This is accurate, but I don't care that the trailing NUL character isn't copied. The string being copied is just a magic number signature so that crash dump tools can be sure they are decoding the right blob of memory. Use memcpy() instead of strncpy(). Fixes: d8ecca4043f2 ("x86/mce/dev-mcelog: Dynamically allocate space for machine check records") Reported-by: kbuild test robot Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20200527182808.27737-1-tony.luck@intel.com Signed-off-by: Sasha Levin commit 936d6f3de3a81eb89a447412b6b26583fcad1fca Author: Vitaly Kuznetsov Date: Tue Apr 28 11:38:24 2020 +0200 x86/idt: Keep spurious entries unset in system_vectors [ Upstream commit 1f1fbc70c10e81f70e9fbe2102d439c883269811 ] With commit dc20b2d52653 ("x86/idt: Move interrupt gate initialization to IDT code") non assigned system vectors are also marked as used in 'used_vectors' (now 'system_vectors') bitmap. This makes checks in arch_show_interrupts() whether a particular system vector is allocated to always pass and e.g. 'Hyper-V reenlightenment interrupts' entry always shows up in /proc/interrupts. Another side effect of having all unassigned system vectors marked as used is that irq_matrix_debug_show() will wrongly count them among 'System' vectors. As it is now ensured that alloc_intr_gate() is not called after init, it is possible to leave unused entries in 'system_vectors' unset to fix these issues. Signed-off-by: Vitaly Kuznetsov Signed-off-by: Thomas Gleixner Link: https://lkml.kernel.org/r/20200428093824.1451532-4-vkuznets@redhat.com Signed-off-by: Sasha Levin commit bfbdc124a83446df7f4907554b12fcae5c348834 Author: Colin Ian King Date: Wed Jun 10 12:58:04 2020 +0100 drm/ast: fix missing break in switch statement for format->cpp[0] case 4 [ Upstream commit 291ddeb621e4a9f1ced8302a777fbd7fbda058c6 ] Currently the switch statement for format->cpp[0] value 4 assigns color_index which is never read again and then falls through to the default case and returns. This looks like a missing break statement bug. Fix this by adding a break statement. Addresses-Coverity: ("Unused value") Fixes: 259d14a76a27 ("drm/ast: Split ast_set_vbios_mode_info()") Signed-off-by: Colin Ian King Signed-off-by: Thomas Zimmermann Tested-by: Thomas Zimmermann Reviewed-by: Thomas Zimmermann Link: https://patchwork.freedesktop.org/patch/msgid/20200610115804.1132338-1-colin.king@canonical.com Signed-off-by: Sasha Levin commit 1e84f34bb61a6393631add3edba806c800d9ff7c Author: Christophe JAILLET Date: Sat May 30 10:16:22 2020 +0200 scsi: acornscsi: Fix an error handling path in acornscsi_probe() [ Upstream commit 42c76c9848e13dbe0538d7ae0147a269dfa859cb ] 'ret' is known to be 0 at this point. Explicitly return -ENOMEM if one of the 'ecardm_iomap()' calls fail. Link: https://lore.kernel.org/r/20200530081622.577888-1-christophe.jaillet@wanadoo.fr Fixes: e95a1b656a98 ("[ARM] rpc: acornscsi: update to new style ecard driver") Signed-off-by: Christophe JAILLET Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f4113155fd1a505c0df11fa9361478d20424185d Author: Andrii Nakryiko Date: Tue Jun 9 22:23:35 2020 -0700 libbpf: Handle GCC noreturn-turned-volatile quirk [ Upstream commit 32022fd97ed34f6812802bf1288db27c313576f4 ] Handle a GCC quirk of emitting extra volatile modifier in DWARF (and subsequently preserved in BTF by pahole) for function pointers marked as __attribute__((noreturn)). This was the way to mark such functions before GCC 2.5 added noreturn attribute. Drop such func_proto modifiers, similarly to how it's done for array (also to handle GCC quirk/bug). Such volatile attribute is emitted by GCC only, so existing selftests can't express such test. Simple repro is like this (compiled with GCC + BTF generated by pahole): struct my_struct { void __attribute__((noreturn)) (*fn)(int); }; struct my_struct a; Without this fix, output will be: struct my_struct { voidvolatile (*fn)(int); }; With the fix: struct my_struct { void (*fn)(int); }; Fixes: 351131b51c7a ("libbpf: add btf_dump API for BTF-to-C conversion") Reported-by: Jean-Philippe Brucker Signed-off-by: Andrii Nakryiko Signed-off-by: Daniel Borkmann Tested-by: Jean-Philippe Brucker Link: https://lore.kernel.org/bpf/20200610052335.2862559-1-andriin@fb.com Signed-off-by: Sasha Levin commit 13b57f8f1b650605f626081e7f096310dfd1d3e6 Author: Jernej Skrabec Date: Mon Apr 13 11:54:57 2020 +0200 drm/sun4i: hdmi ddc clk: Fix size of m divider [ Upstream commit 54e1e06bcf1cf6e7ac3f86daa5f7454add24b494 ] m divider in DDC clock register is 4 bits wide. Fix that. Fixes: 9c5681011a0c ("drm/sun4i: Add HDMI support") Signed-off-by: Jernej Skrabec Reviewed-by: Chen-Yu Tsai Signed-off-by: Maxime Ripard Link: https://patchwork.freedesktop.org/patch/msgid/20200413095457.1176754-1-jernej.skrabec@siol.net Signed-off-by: Sasha Levin commit e0183d7c2a565b180dde245f58ac9687e6d094cb Author: Jean-Philippe Brucker Date: Mon Jun 8 14:45:32 2020 +0200 tracing/probe: Fix bpf_task_fd_query() for kprobes and uprobes [ Upstream commit 22d5bd6867364b41576a712755271a7d6161abd6 ] Commit 60d53e2c3b75 ("tracing/probe: Split trace_event related data from trace_probe") removed the trace_[ku]probe structure from the trace_event_call->data pointer. As bpf_get_[ku]probe_info() were forgotten in that change, fix them now. These functions are currently only used by the bpf_task_fd_query() syscall handler to collect information about a perf event. Fixes: 60d53e2c3b75 ("tracing/probe: Split trace_event related data from trace_probe") Signed-off-by: Jean-Philippe Brucker Signed-off-by: Alexei Starovoitov Acked-by: Yonghong Song Acked-by: Masami Hiramatsu Link: https://lore.kernel.org/bpf/20200608124531.819838-1-jean-philippe@linaro.org Signed-off-by: Sasha Levin commit 6fc372656a1ebed8c1ebe0011881058c02eeddc0 Author: Jakub Sitnicki Date: Sun Jun 7 22:52:29 2020 +0200 bpf, sockhash: Synchronize delete from bucket list on map free [ Upstream commit 75e68e5bf2c7fa9d3e874099139df03d5952a3e1 ] We can end up modifying the sockhash bucket list from two CPUs when a sockhash is being destroyed (sock_hash_free) on one CPU, while a socket that is in the sockhash is unlinking itself from it on another CPU it (sock_hash_delete_from_link). This results in accessing a list element that is in an undefined state as reported by KASAN: | ================================================================== | BUG: KASAN: wild-memory-access in sock_hash_free+0x13c/0x280 | Write of size 8 at addr dead000000000122 by task kworker/2:1/95 | | CPU: 2 PID: 95 Comm: kworker/2:1 Not tainted 5.7.0-rc7-02961-ge22c35ab0038-dirty #691 | Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 04/01/2014 | Workqueue: events bpf_map_free_deferred | Call Trace: | dump_stack+0x97/0xe0 | ? sock_hash_free+0x13c/0x280 | __kasan_report.cold+0x5/0x40 | ? mark_lock+0xbc1/0xc00 | ? sock_hash_free+0x13c/0x280 | kasan_report+0x38/0x50 | ? sock_hash_free+0x152/0x280 | sock_hash_free+0x13c/0x280 | bpf_map_free_deferred+0xb2/0xd0 | ? bpf_map_charge_finish+0x50/0x50 | ? rcu_read_lock_sched_held+0x81/0xb0 | ? rcu_read_lock_bh_held+0x90/0x90 | process_one_work+0x59a/0xac0 | ? lock_release+0x3b0/0x3b0 | ? pwq_dec_nr_in_flight+0x110/0x110 | ? rwlock_bug.part.0+0x60/0x60 | worker_thread+0x7a/0x680 | ? _raw_spin_unlock_irqrestore+0x4c/0x60 | kthread+0x1cc/0x220 | ? process_one_work+0xac0/0xac0 | ? kthread_create_on_node+0xa0/0xa0 | ret_from_fork+0x24/0x30 | ================================================================== Fix it by reintroducing spin-lock protected critical section around the code that removes the elements from the bucket on sockhash free. To do that we also need to defer processing of removed elements, until out of atomic context so that we can unlink the socket from the map when holding the sock lock. Fixes: 90db6d772f74 ("bpf, sockmap: Remove bucket->lock from sock_{hash|map}_free") Reported-by: Eric Dumazet Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200607205229.2389672-3-jakub@cloudflare.com Signed-off-by: Sasha Levin commit f7d516d43cfacfd66700240de7a1e2bf2022cba9 Author: dihu Date: Fri Jun 5 16:46:25 2020 +0800 bpf/sockmap: Fix kernel panic at __tcp_bpf_recvmsg [ Upstream commit 487082fb7bd2a32b66927d2b22e3a81b072b44f0 ] When user application calls read() with MSG_PEEK flag to read data of bpf sockmap socket, kernel panic happens at __tcp_bpf_recvmsg+0x12c/0x350. sk_msg is not removed from ingress_msg queue after read out under MSG_PEEK flag is set. Because it's not judged whether sk_msg is the last msg of ingress_msg queue, the next sk_msg may be the head of ingress_msg queue, whose memory address of sg page is invalid. So it's necessary to add check codes to prevent this problem. [20759.125457] BUG: kernel NULL pointer dereference, address: 0000000000000008 [20759.132118] CPU: 53 PID: 51378 Comm: envoy Tainted: G E 5.4.32 #1 [20759.140890] Hardware name: Inspur SA5212M4/YZMB-00370-109, BIOS 4.1.12 06/18/2017 [20759.149734] RIP: 0010:copy_page_to_iter+0xad/0x300 [20759.270877] __tcp_bpf_recvmsg+0x12c/0x350 [20759.276099] tcp_bpf_recvmsg+0x113/0x370 [20759.281137] inet_recvmsg+0x55/0xc0 [20759.285734] __sys_recvfrom+0xc8/0x130 [20759.290566] ? __audit_syscall_entry+0x103/0x130 [20759.296227] ? syscall_trace_enter+0x1d2/0x2d0 [20759.301700] ? __audit_syscall_exit+0x1e4/0x290 [20759.307235] __x64_sys_recvfrom+0x24/0x30 [20759.312226] do_syscall_64+0x55/0x1b0 [20759.316852] entry_SYSCALL_64_after_hwframe+0x44/0xa9 Signed-off-by: dihu Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Acked-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/20200605084625.9783-1-anny.hu@linux.alibaba.com Signed-off-by: Sasha Levin commit f0834d4546289e2743c7a59c52fa95faf89f2baf Author: Hans de Goede Date: Mon Jun 8 22:46:34 2020 +0200 ASoC: rt5645: Add platform-data for Asus T101HA [ Upstream commit 79d4f823a06796656289f97b922493da5690e46c ] The Asus T101HA uses the default jack-detect mode 3, but instead of using an analog microphone it is using a DMIC on dmic-data-pin 1, like the Asus T100HA. Note unlike the T100HA its jack-detect is not inverted. Add a DMI quirk with the correct settings for this model. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200608204634.93407-2-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 781b4485641ea196966071ab473a87107e301eba Author: Hans de Goede Date: Mon Jun 8 22:46:33 2020 +0200 ASoC: Intel: bytcr_rt5640: Add quirk for Toshiba Encore WT10-A tablet [ Upstream commit 199a5e8fda54ab3c8c6f6bf980c004e97ebf5ccb ] The Toshiba Encore WT10-A tablet almost fully works with the default settings for Bay Trail CR devices. The only issue is that it uses a digital mic. connected the the DMIC1 input instead of an analog mic. Add a quirk for this model using the default settings with the input-map replaced with BYT_RT5640_DMIC1_MAP. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200608204634.93407-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit b8b78a4b25955724705acbae887834307d5f40ea Author: Pierre-Louis Bossart Date: Mon Jun 8 14:44:15 2020 -0500 ASoC: SOF: nocodec: conditionally set dpcm_capture/dpcm_playback flags [ Upstream commit ba4e5abc6c4e173af7c941c03c067263b686665d ] With additional checks on dailinks, we see errors such as [ 3.000418] sof-nocodec sof-nocodec: CPU DAI DMIC01 Pin for rtd NoCodec-6 does not support playback It's not clear why we set the dpcm_playback and dpcm_capture flags unconditionally, add a check on number of channels for each direction to avoid invalid configurations. Fixes: 8017b8fd37bf5e ('ASoC: SOF: Add Nocodec machine driver support') Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Daniel Baluta Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20200608194415.4663-5-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 9f98b6cd1178b166b9ad663fae86ca542ec2a6a4 Author: Bard Liao Date: Mon Jun 8 14:44:13 2020 -0500 ASoC: core: only convert non DPCM link to DPCM link [ Upstream commit 607fa205a7e4dfad28b8a67ab1c985756ddbccb0 ] Additional checks for valid DAIs expose a corner case, where existing BE dailinks get modified, e.g. HDMI links are tagged with dpcm_capture=1 even if the DAIs are for playback. This patch makes those changes conditional and flags configuration issues when a BE dailink is has no_pcm=0 but dpcm_playback or dpcm_capture=1 (which makes no sense). As discussed on the alsa-devel mailing list, there are redundant flags for dpcm_playback, dpcm_capture, playback_only, capture_only. This will have to be cleaned-up in a future update. For now only correct and flag problematic configurations. Fixes: 218fe9b7ec7f3 ("ASoC: soc-core: Set dpcm_playback / dpcm_capture") Suggested-by: Daniel Baluta Signed-off-by: Bard Liao Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Daniel Baluta Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20200608194415.4663-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1bb707fbfd5c246028d76b8f11a19dfd118d6306 Author: Pierre-Louis Bossart Date: Mon Jun 8 14:44:12 2020 -0500 ASoC: soc-pcm: dpcm: fix playback/capture checks [ Upstream commit b73287f0b0745961b14e5ebcce92cc8ed24d4d52 ] Recent changes in the ASoC core prevent multi-cpu BE dailinks from being used. DPCM does support multi-cpu DAIs for BE Dailinks, but not for FE. Handle the FE checks first, and make sure all DAIs support the same capabilities within the same dailink. Fixes: 9b5db059366ae2 ("ASoC: soc-pcm: dpcm: Only allow playback/capture if supported") Signed-off-by: Pierre-Louis Bossart Reviewed-by: Bard Liao Reviewed-by: Guennadi Liakhovetski Reviewed-by: Ranjani Sridharan Reviewed-by: Daniel Baluta BugLink: https://github.com/thesofproject/linux/issues/2031 Link: https://lore.kernel.org/r/20200608194415.4663-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e3cd274437353f723b2b8e87f603fb9ca0942bc4 Author: Zhihao Cheng Date: Tue Jun 2 09:30:45 2020 +0800 afs: Fix memory leak in afs_put_sysnames() [ Upstream commit 2ca068be09bf8e285036603823696140026dcbe7 ] Fix afs_put_sysnames() to actually free the specified afs_sysnames object after its reference count has been decreased to zero and its contents have been released. Fixes: 6f8880d8e681557 ("afs: Implement @sys substitution handling") Signed-off-by: Zhihao Cheng Signed-off-by: David Howells Signed-off-by: Sasha Levin commit 2f7b5e7673926493bb95efbeed93d5dc0e10b5b8 Author: Eric Biggers Date: Thu Jun 4 21:57:48 2020 -0700 f2fs: don't return vmalloc() memory from f2fs_kmalloc() [ Upstream commit 0b6d4ca04a86b9dababbb76e58d33c437e127b77 ] kmalloc() returns kmalloc'ed memory, and kvmalloc() returns either kmalloc'ed or vmalloc'ed memory. But the f2fs wrappers, f2fs_kmalloc() and f2fs_kvmalloc(), both return both kinds of memory. It's redundant to have two functions that do the same thing, and also breaking the standard naming convention is causing bugs since people assume it's safe to kfree() memory allocated by f2fs_kmalloc(). See e.g. the various allocations in fs/f2fs/compress.c. Fix this by making f2fs_kmalloc() just use kmalloc(). And to avoid re-introducing the allocation failures that the vmalloc fallback was intended to fix, convert the largest allocations to use f2fs_kvmalloc(). Signed-off-by: Eric Biggers Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 394869c49ff5eee34dc05f19a8b5d7c100d415c7 Author: tannerlove Date: Mon Jun 8 15:37:15 2020 -0400 selftests/net: in timestamping, strncpy needs to preserve null byte [ Upstream commit 8027bc0307ce59759b90679fa5d8b22949586d20 ] If user passed an interface option longer than 15 characters, then device.ifr_name and hwtstamp.ifr_name became non-null-terminated strings. The compiler warned about this: timestamping.c:353:2: warning: ‘strncpy’ specified bound 16 equals \ destination size [-Wstringop-truncation] 353 | strncpy(device.ifr_name, interface, sizeof(device.ifr_name)); Fixes: cb9eff097831 ("net: new user space API for time stamping of incoming and outgoing packets") Signed-off-by: Tanner Love Acked-by: Willem de Bruijn Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 455fd835e4f7c241727f41a142e29f44f46b290b Author: Shaokun Zhang Date: Fri Jun 5 17:43:41 2020 +0800 drivers/perf: hisi: Fix wrong value for all counters enable [ Upstream commit 961abd78adcb4c72c343fcd9f9dc5e2ebbe9b448 ] In L3C uncore PMU drivers, bit16 is used to control all counters enable & disable. Wrong value is given in the driver and its default value is 1'b1, it can work because each PMU counter has its own control bits too. Let's fix the wrong value. Fixes: 2940bc433370 ("perf: hisi: Add support for HiSilicon SoC L3C PMU driver") Signed-off-by: Shaokun Zhang Cc: Will Deacon Cc: Mark Rutland Link: https://lore.kernel.org/r/1591350221-32275-1-git-send-email-zhangshaokun@hisilicon.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 599a51823adcb004819014cfb0c6744585e5ba4c Author: Joe Perches Date: Sat Jun 6 12:25:50 2020 -0700 arm64: ftrace: Change CONFIG_FTRACE_WITH_REGS to CONFIG_DYNAMIC_FTRACE_WITH_REGS [ Upstream commit 91970bef48d68d06b2bb3f464b572ad50941f6a9 ] CONFIG_FTRACE_WITH_REGS does not exist as a Kconfig symbol. Fixes: 3b23e4991fb6 ("arm64: implement ftrace with regs") Signed-off-by: Joe Perches Acked-by: Mark Rutland Link: https://lore.kernel.org/r/b9b27f2233bd1fa31d72ff937beefdae0e2104e5.camel@perches.com Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit 1af0bc2c1c9957603cac10320782e40b028b44d8 Author: Dong Aisheng Date: Wed Jun 3 13:15:42 2020 +0800 mailbox: imx: Add context save/restore for suspend/resume [ Upstream commit ba5f9fa0ca85a6137fa35efd3a1256d8bb6bc5ff ] For "mem" mode suspend on i.MX8 SoCs, MU settings could be lost because its power is off, so save/restore is needed for MU settings during suspend/resume. However, the restore can ONLY be done when MU settings are actually lost, for the scenario of settings NOT lost in "freeze" mode suspend, since there could be still IPC going on multiple CPUs, restoring the MU settings could overwrite the TIE by mistake and cause system freeze, so need to make sure ONLY restore the MU settings when it is powered off, Anson fixes this by checking whether restore is actually needed when resume. Signed-off-by: Dong Aisheng Signed-off-by: Anson Huang Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit 441b31b1bab8053a7c5067ad67c5a97b29ecbf03 Author: Max Staudt Date: Sun Jun 7 20:28:12 2020 +0200 i2c: icy: Fix build with CONFIG_AMIGA_PCMCIA=n [ Upstream commit cdb555397f438592bab00599037c347b700cf397 ] This has been found by the Kernel Test Robot: http://lkml.iu.edu/hypermail/linux/kernel/2006.0/06862.html With CONFIG_AMIGA_PCMCIA=n, io_mm.h does not pull in amigahw.h and ZTWO_VADDR is undefined. Add forgotten include to i2c-icy.c Fixes: 4768e90ecaec ("i2c: Add i2c-icy for I2C on m68k/Amiga") Reported-by: kernel test robot Signed-off-by: Max Staudt Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 1ce6ac210a09c2165df67a3ac94264dd1aab72a6 Author: Logan Gunthorpe Date: Wed Jan 9 12:22:33 2019 -0700 NTB: ntb_test: Fix bug when counting remote files [ Upstream commit 2130c0ba69d69bb21f5c52787f2587db00d13d8a ] When remote files are counted in get_files_count, without using SSH, the code returns 0 because there is a colon prepended to $LOC. $VPATH should have been used instead of $LOC. Fixes: 06bd0407d06c ("NTB: ntb_test: Update ntb_tool Scratchpad tests") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 47011450da2aebcfebe01f6e824f0ead5dbf93b7 Author: Logan Gunthorpe Date: Wed Jan 9 12:22:32 2019 -0700 NTB: perf: Fix race condition when run with ntb_test [ Upstream commit 34d8673a01b053b6231a995a4eec9341163d63be ] When running ntb_test, the script tries to run the ntb_perf test immediately after probing the modules. Since adding multi-port support, this fails seeing the new initialization procedure in ntb_perf can not complete instantly. To fix this we add a completion which is waited on when a test is started. In this way, run can be written any time after the module is loaded and it will wait for the initialization to complete instead of sending an error. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit d64669364a19c637f18e704d9cfc6f77f20ad78d Author: Logan Gunthorpe Date: Wed Jan 9 12:22:31 2019 -0700 NTB: perf: Fix support for hardware that doesn't have port numbers [ Upstream commit b54369a248c2e033bfcf5d6917e08cf9d73d54a6 ] Legacy drivers do not have port numbers (but is reliably only two ports) and was broken by the recent commit that added mult-port support to ntb_perf. This is especially important to support the cross link topology which is perfectly symmetric and cannot assign unique port numbers easily. Hardware that returns zero for both the local port and the peer should just always use gidx=0 for the only peer. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit cbce282d5ad4f0c8fdab1cdf05dce2cd2aa84b40 Author: Logan Gunthorpe Date: Wed Jan 9 12:22:30 2019 -0700 NTB: perf: Don't require one more memory window than number of peers [ Upstream commit a9c4211ac918ade1522aced6b5acfbe824722f7d ] ntb_perf should not require more than one memory window per peer. This was probably an off-by-one error. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 96133449ecbffb8f938665080a3993ab3a1e09f6 Author: Logan Gunthorpe Date: Wed Jan 9 12:22:27 2019 -0700 NTB: Revert the change to use the NTB device dev for DMA allocations [ Upstream commit 40da7d9a93c8941737ef4a1208d32c13ce017fe1 ] Commit 417cf39cfea9 ("NTB: Set dma mask and dma coherent mask to NTB devices") started using the NTB device for DMA allocations which was turns out was wrong. If the IOMMU is enabled, such alloctanions will always fail with messages such as: DMAR: Allocating domain for 0000:02:00.1 failed This is because the IOMMU has not setup the device for such use. Change the tools back to using the PCI device for allocations seeing it doesn't make sense to add an IOMMU group for the non-physical NTB device. Also remove the code that sets the DMA mask as it no longer makes sense to do this. Fixes: 7f46c8b3a552 ("NTB: ntb_tool: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 7ec040619b880c4e9caf3295f560a1c070a807b4 Author: Logan Gunthorpe Date: Wed Jan 9 12:22:26 2019 -0700 NTB: ntb_tool: reading the link file should not end in a NULL byte [ Upstream commit 912e12813dd03c602e4922fc34709ec4d4380cf0 ] When running ntb_test this warning is issued: ./ntb_test.sh: line 200: warning: command substitution: ignored null byte in input This is caused by the kernel returning one more byte than is necessary when reading the link file. Reduce the number of bytes read back to 2 as it was before the commit that regressed this. Fixes: 7f46c8b3a552 ("NTB: ntb_tool: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 38169a09f1e27b3cee5b57678c0bd02abf6f0eea Author: Sanjay R Mehta Date: Tue May 5 23:21:50 2020 -0500 ntb_tool: pass correct struct device to dma_alloc_coherent [ Upstream commit 433efe720674efd9fdbcef78be75793393cf05db ] Currently, ntb->dev is passed to dma_alloc_coherent and dma_free_coherent calls. The returned dma_addr_t is the CPU physical address. This works fine as long as IOMMU is disabled. But when IOMMU is enabled, we need to make sure that IOVA is returned for dma_addr_t. So the correct way to achieve this is by changing the first parameter of dma_alloc_coherent() as ntb->pdev->dev instead. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by: Sanjay R Mehta Signed-off-by: Arindam Nath Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit c79266a38ff6ef655fc4ed02d173655654602351 Author: Sanjay R Mehta Date: Tue May 5 23:21:49 2020 -0500 ntb_perf: pass correct struct device to dma_alloc_coherent [ Upstream commit 98f4e140264eeb52f22ff05be6b6dd48237255ac ] Currently, ntb->dev is passed to dma_alloc_coherent and dma_free_coherent calls. The returned dma_addr_t is the CPU physical address. This works fine as long as IOMMU is disabled. But when IOMMU is enabled, we need to make sure that IOVA is returned for dma_addr_t. So the correct way to achieve this is by changing the first parameter of dma_alloc_coherent() as ntb->pdev->dev instead. Fixes: 5648e56d03fa ("NTB: ntb_perf: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Signed-off-by: Sanjay R Mehta Signed-off-by: Arindam Nath Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 741b94e0559c692a010e1697ba21e5e0c07a18be Author: Dan Murphy Date: Fri Jun 5 09:01:07 2020 -0500 net: mscc: Fix OF_MDIO config check [ Upstream commit ae602786407fef34e1d66b3c8f278a10ed37197e ] When CONFIG_OF_MDIO is set to be a module the code block is not compiled. Use the IS_ENABLED macro that checks for both built in as well as module. Fixes: 4f58e6dceb0e4 ("net: phy: Cleanup the Edge-Rate feature in Microsemi PHYs.") Signed-off-by: Dan Murphy Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit c65428833322a5422d7446c4f11013b9e9659637 Author: Dan Murphy Date: Fri Jun 5 09:01:06 2020 -0500 net: marvell: Fix OF_MDIO config check [ Upstream commit 5cd119d9a05f1c1a08778a7305b4ca0f16bc1e20 ] When CONFIG_OF_MDIO is set to be a module the code block is not compiled. Use the IS_ENABLED macro that checks for both built in as well as module. Fixes: cf41a51db8985 ("of/phylib: Use device tree properties to initialize Marvell PHYs.") Signed-off-by: Dan Murphy Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 414baaaf82701949b3905e9293c0f433e20fbeeb Author: Dan Murphy Date: Fri Jun 5 09:01:05 2020 -0500 net: dp83867: Fix OF_MDIO config check [ Upstream commit 506de00677b84dfc6718cbbd3495b1d90df5d098 ] When CONFIG_OF_MDIO is set to be a module the code block is not compiled. Use the IS_ENABLED macro that checks for both built in as well as module. Fixes: 2a10154abcb75 ("net: phy: dp83867: Add TI dp83867 phy") Signed-off-by: Dan Murphy Reviewed-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0bcde2d82ef8ade94ee8f4cc5f7a8382d324a844 Author: Bob Peterson Date: Thu Jun 4 14:28:58 2020 -0500 gfs2: fix use-after-free on transaction ail lists [ Upstream commit 83d060ca8d90fa1e3feac227f995c013100862d3 ] Before this patch, transactions could be merged into the system transaction by function gfs2_merge_trans(), but the transaction ail lists were never merged. Because the ail flushing mechanism can run separately, bd elements can be attached to the transaction's buffer list during the transaction (trans_add_meta, etc) but quickly moved to its ail lists. Later, in function gfs2_trans_end, the transaction can be freed (by gfs2_trans_end) while it still has bd elements queued to its ail lists, which can cause it to either lose track of the bd elements altogether (memory leak) or worse, reference the bd elements after the parent transaction has been freed. Although I've not seen any serious consequences, the problem becomes apparent with the previous patch's addition of: gfs2_assert_warn(sdp, list_empty(&tr->tr_ail1_list)); to function gfs2_trans_free(). This patch adds logic into gfs2_merge_trans() to move the merged transaction's ail lists to the sdp transaction. This prevents the use-after-free. To do this properly, we need to hold the ail lock, so we pass sdp into the function instead of the transaction itself. Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit bfce064e3a3c3b1ff58aa611c6398913e8bca08d Author: Vitaly Kuznetsov Date: Fri Jun 5 16:20:28 2020 +0200 KVM: selftests: Fix build with "make ARCH=x86_64" [ Upstream commit b80db73dc8be7022adae1b4414a1bebce50fe915 ] Marcelo reports that kvm selftests fail to build with "make ARCH=x86_64": gcc -Wall -Wstrict-prototypes -Wuninitialized -O2 -g -std=gnu99 -fno-stack-protector -fno-PIE -I../../../../tools/include -I../../../../tools/arch/x86_64/include -I../../../../usr/include/ -Iinclude -Ilib -Iinclude/x86_64 -I.. -c lib/kvm_util.c -o /var/tmp/20200604202744-bin/lib/kvm_util.o In file included from lib/kvm_util.c:11: include/x86_64/processor.h:14:10: fatal error: asm/msr-index.h: No such file or directory #include ^~~~~~~~~~~~~~~~~ compilation terminated. "make ARCH=x86", however, works. The problem is that arch specific headers for x86_64 live in 'tools/arch/x86/include', not in 'tools/arch/x86_64/include'. Fixes: 66d69e081b52 ("selftests: fix kvm relocatable native/cross builds and installs") Reported-by: Marcelo Bandeira Condotta Signed-off-by: Vitaly Kuznetsov Message-Id: <20200605142028.550068-1-vkuznets@redhat.com> Signed-off-by: Paolo Bonzini Signed-off-by: Sasha Levin commit d99f36636f1a19e217fefacded9f0933038e20d8 Author: Chaitanya Kulkarni Date: Thu Jun 4 00:13:30 2020 -0700 blktrace: fix endianness for blk_log_remap() [ Upstream commit 5aec598c456fe3c1b71a1202cbb42bdc2a643277 ] The function blk_log_remap() can be simplified by removing the call to get_pdu_remap() that copies the values into extra variable to print the data, which also fixes the endiannness warning reported by sparse. Signed-off-by: Chaitanya Kulkarni Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 5c26339664aade506046f15896fc417759b7b986 Author: Chaitanya Kulkarni Date: Thu Jun 4 00:13:29 2020 -0700 blktrace: fix endianness in get_pdu_int() [ Upstream commit 71df3fd82e7cccec7b749a8607a4662d9f7febdd ] In function get_pdu_len() replace variable type from __u64 to __be64. This fixes sparse warning. Signed-off-by: Chaitanya Kulkarni Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 87bb400c4f17d3e561966be1bddff0d515c0ab9d Author: Chaitanya Kulkarni Date: Thu Jun 4 00:13:28 2020 -0700 blktrace: use errno instead of bi_status [ Upstream commit 48bc3cd3e07a1486f45d9971c75d6090976c3b1b ] In blk_add_trace_spliti() blk_add_trace_bio_remap() use blk_status_to_errno() to pass the error instead of pasing the bi_status. This fixes the sparse warning. Signed-off-by: Chaitanya Kulkarni Signed-off-by: Jens Axboe Signed-off-by: Sasha Levin commit 9d2a73a00f5fc6fb72632f8be57ecdfe0a8eee77 Author: Ram Pai Date: Thu Jun 4 16:52:05 2020 -0700 selftests/vm/pkeys: fix alloc_random_pkey() to make it really random [ Upstream commit 6e373263ce07eeaa6410843179535fbdf561fc31 ] alloc_random_pkey() was allocating the same pkey every time. Not all pkeys were geting tested. This fixes it. Signed-off-by: Ram Pai Signed-off-by: Sandipan Das Signed-off-by: Andrew Morton Acked-by: Dave Hansen Cc: Dave Hansen Cc: Florian Weimer Cc: "Desnes A. Nunes do Rosario" Cc: Ingo Molnar Cc: Thiago Jung Bauermann Cc: "Aneesh Kumar K.V" Cc: Michael Ellerman Cc: Michal Hocko Cc: Michal Suchanek Cc: Shuah Khan Link: http://lkml.kernel.org/r/0162f55816d4e783a0d6e49e554d0ab9a3c9a23b.1585646528.git.sandipan@linux.ibm.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 2501305a08cfa8bfc1bf234a2d377eb9b0f48834 Author: Arnd Bergmann Date: Thu Jun 4 16:50:30 2020 -0700 include/linux/bitops.h: avoid clang shift-count-overflow warnings [ Upstream commit bd93f003b7462ae39a43c531abca37fe7073b866 ] Clang normally does not warn about certain issues in inline functions when it only happens in an eliminated code path. However if something else goes wrong, it does tend to complain about the definition of hweight_long() on 32-bit targets: include/linux/bitops.h:75:41: error: shift count >= width of type [-Werror,-Wshift-count-overflow] return sizeof(w) == 4 ? hweight32(w) : hweight64(w); ^~~~~~~~~~~~ include/asm-generic/bitops/const_hweight.h:29:49: note: expanded from macro 'hweight64' define hweight64(w) (__builtin_constant_p(w) ? __const_hweight64(w) : __arch_hweight64(w)) ^~~~~~~~~~~~~~~~~~~~ include/asm-generic/bitops/const_hweight.h:21:76: note: expanded from macro '__const_hweight64' define __const_hweight64(w) (__const_hweight32(w) + __const_hweight32((w) >> 32)) ^ ~~ include/asm-generic/bitops/const_hweight.h:20:49: note: expanded from macro '__const_hweight32' define __const_hweight32(w) (__const_hweight16(w) + __const_hweight16((w) >> 16)) ^ include/asm-generic/bitops/const_hweight.h:19:72: note: expanded from macro '__const_hweight16' define __const_hweight16(w) (__const_hweight8(w) + __const_hweight8((w) >> 8 )) ^ include/asm-generic/bitops/const_hweight.h:12:9: note: expanded from macro '__const_hweight8' (!!((w) & (1ULL << 2))) + \ Adding an explicit cast to __u64 avoids that warning and makes it easier to read other output. Signed-off-by: Arnd Bergmann Signed-off-by: Andrew Morton Acked-by: Christian Brauner Cc: Andy Shevchenko Cc: Rasmus Villemoes Cc: Josh Poimboeuf Cc: Nick Desaulniers Link: http://lkml.kernel.org/r/20200505135513.65265-1-arnd@arndb.de Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit af0354c952f4453a5a2228830032fd0972bef8e4 Author: Jann Horn Date: Thu Jun 4 16:50:17 2020 -0700 lib/zlib: remove outdated and incorrect pre-increment optimization [ Upstream commit acaab7335bd6f0c0b54ce3a00bd7f18222ce0f5f ] The zlib inflate code has an old micro-optimization based on the assumption that for pre-increment memory accesses, the compiler will generate code that fits better into the processor's pipeline than what would be generated for post-increment memory accesses. This optimization was already removed in upstream zlib in 2016: https://github.com/madler/zlib/commit/9aaec95e8211 This optimization causes UB according to C99, which says in section 6.5.6 "Additive operators": "If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined". This UB is not only a theoretical concern, but can also cause trouble for future work on compiler-based sanitizers. According to the zlib commit, this optimization also is not optimal anymore with modern compilers. Replace uses of OFF, PUP and UP_UNALIGNED with their definitions in the POSTINC case, and remove the macro definitions, just like in the upstream patch. Signed-off-by: Jann Horn Signed-off-by: Andrew Morton Cc: Mikhail Zaslonko Link: http://lkml.kernel.org/r/20200507123112.252723-1-jannh@google.com Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 998240d099217309c51d431a868dcbef4de45aba Author: Jiri Benc Date: Wed Jun 3 11:12:14 2020 +0200 geneve: change from tx_error to tx_dropped on missing metadata [ Upstream commit 9d149045b3c0e44c049cdbce8a64e19415290017 ] If the geneve interface is in collect_md (external) mode, it can't send any packets submitted directly to its net interface, as such packets won't have metadata attached. This is expected. However, the kernel itself sends some packets to the interface, most notably, IPv6 DAD, IPv6 multicast listener reports, etc. This is not wrong, as tunnel metadata can be specified in routing table (although technically, that has never worked for IPv6, but hopefully will be fixed eventually) and then the interface must correctly participate in IPv6 housekeeping. The problem is that any such attempt increases the tx_error counter. Just bringing up a geneve interface with IPv6 enabled is enough to see a number of tx_errors. That causes confusion among users, prompting them to find a network error where there is none. Change the counter used to tx_dropped. That better conveys the meaning (there's nothing wrong going on, just some packets are getting dropped) and hopefully will make admins panic less. Signed-off-by: Jiri Benc Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 51c37c3fac2c4c2cda1a8dfc6c59c2d88d4120d5 Author: Dan Carpenter Date: Thu Jun 4 11:54:36 2020 +0300 bpf: Fix an error code in check_btf_func() [ Upstream commit e7ed83d6fa1a00d0f2ad0327e73d3ea9e7ea8de1 ] This code returns success if the "info_aux" allocation fails but it should return -ENOMEM. Fixes: 8c1b6e69dcc1 ("bpf: Compare BTF types of functions arguments with actual types") Signed-off-by: Dan Carpenter Signed-off-by: Daniel Borkmann Acked-by: Song Liu Link: https://lore.kernel.org/bpf/20200604085436.GA943001@mwanda Signed-off-by: Sasha Levin commit 0c26bff2bb582e06358d36b90f4aca23e11deee7 Author: Kees Cook Date: Wed Jun 3 15:40:56 2020 -0700 pwm: Add missing "CONFIG_" prefix [ Upstream commit f5641d053d46a9a18fe13f2ecb4a7b4a66d9cdf7 ] The IS_ENABLED() use was missing the CONFIG_ prefix which would have lead to skipping this code. Fixes: 3ad1f3a33286 ("pwm: Implement some checks for lowlevel drivers") Signed-off-by: Kees Cook Reviewed-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 34bd56feb39d8b66134390b46b8262ca10de4f40 Author: Tero Kristo Date: Wed May 27 15:24:29 2020 +0300 crypto: omap-sham - add proper load balancing support for multicore [ Upstream commit 281c377872ff5d15d80df25fc4df02d2676c7cde ] The current implementation of the multiple accelerator core support for OMAP SHA does not work properly. It always picks up the first probed accelerator core if this is available, and rest of the book keeping also gets confused if there are two cores available. Add proper load balancing support for SHA, and also fix any bugs related to the multicore support while doing it. Signed-off-by: Tero Kristo Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 255bc2b4994e20772dce0069ae049d5a0424d5e0 Author: Jens Axboe Date: Sun May 24 16:53:16 2020 -0600 ext4: don't block for O_DIRECT if IOCB_NOWAIT is set [ Upstream commit 6e014c621e7271649f0d51e54dbe1db4c10486c8 ] Running with some debug patches to detect illegal blocking triggered the extend/unaligned condition in ext4. If ext4 needs to extend the file (and hence go to buffered IO), or if the app is doing unaligned IO, then ext4 asks the iomap code to wait for IO completion. If the caller asked for no-wait semantics by setting IOCB_NOWAIT, then ext4 should return -EAGAIN instead. Signed-off-by: Jens Axboe Link: https://lore.kernel.org/r/76152096-2bbb-7682-8fce-4cb498bcd909@kernel.dk Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit 2ade6388e146d9d5a6fb93f45b5ca48c38969e4e Author: Harshad Shirwadkar Date: Sun Apr 26 18:34:37 2020 -0700 ext4: handle ext4_mark_inode_dirty errors [ Upstream commit 4209ae12b12265d475bba28634184423149bd14f ] ext4_mark_inode_dirty() can fail for real reasons. Ignoring its return value may lead ext4 to ignore real failures that would result in corruption / crashes. Harden ext4_mark_inode_dirty error paths to fail as soon as possible and return errors to the caller whenever appropriate. One of the possible scnearios when this bug could affected is that while creating a new inode, its directory entry gets added successfully but while writing the inode itself mark_inode_dirty returns error which is ignored. This would result in inconsistency that the directory entry points to a non-existent inode. Ran gce-xfstests smoke tests and verified that there were no regressions. Signed-off-by: Harshad Shirwadkar Link: https://lore.kernel.org/r/20200427013438.219117-1-harshadshirwadkar@gmail.com Signed-off-by: Theodore Ts'o Signed-off-by: Sasha Levin commit b5232e2ee8df85891514c73472cac09921e5d51d Author: Nicholas Kazlauskas Date: Tue Jun 2 20:42:33 2020 -0400 drm/amd/display: Revalidate bandwidth before commiting DC updates [ Upstream commit a24eaa5c51255b344d5a321f1eeb3205f2775498 ] [Why] Whenever we switch between tiled formats without also switching pixel formats or doing anything else that recreates the DC plane state we can run into underflow or hangs since we're not updating the DML parameters before committing to the hardware. [How] If the update type is FULL then call validate_bandwidth again to update the DML parmeters before committing the state. This is basically just a workaround and protective measure against update types being added DC where we could run into this issue in the future. We can only fully validate the state in advance before applying it to the hardware if we recreate all the plane and stream states since we can't modify what's currently in use. The next step is to update DM to ensure that we're creating the plane and stream states for whatever could potentially be a full update in DC to pre-emptively recreate the state for DC global validation. The workaround can stay until this has been fixed in DM. Signed-off-by: Nicholas Kazlauskas Reviewed-by: Hersen Wu Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 0209ff0ef722bea9b111b831f50c09dfb895b143 Author: Ka-Cheong Poon Date: Wed Jun 3 06:33:38 2020 -0700 RDMA/cm: Spurious WARNING triggered in cm_destroy_id() [ Upstream commit fba97dc7fc76b2c9a909fa0b3786d30a9899f5cf ] If the cm_id state is IB_CM_REP_SENT when cm_destroy_id() is called, it calls cm_send_rej_locked(). In cm_send_rej_locked(), it calls cm_enter_timewait() and the state is changed to IB_CM_TIMEWAIT. Now back to cm_destroy_id(), it breaks from the switch statement, and the next call is WARN_ON(cm_id->state != IB_CM_IDLE). This triggers a spurious warning. Instead, the code should goto retest after returning from cm_send_rej_locked() to move the state to IDLE. Fixes: 67b3c8dceac6 ("RDMA/cm: Make sure the cm_id is in the IB_CM_IDLE state in destroy") Link: https://lore.kernel.org/r/1591191218-9446-1-git-send-email-ka-cheong.poon@oracle.com Signed-off-by: Ka-Cheong Poon Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 87331261b7040510689bcfd00bae85245d0c6fbe Author: J. Bruce Fields Date: Wed Jun 3 11:12:32 2020 -0400 nfsd: safer handling of corrupted c_type [ Upstream commit c25bf185e57213b54ea0d632ac04907310993433 ] This can only happen if there's a bug somewhere, so let's make it a WARN not a printk. Also, I think it's safest to ignore the corruption rather than trying to fix it by removing a cache entry. Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 534fd0588f98103aaaf0fac1fa139e242e669abb Author: Christophe JAILLET Date: Sat May 30 22:49:55 2020 +0200 pinctrl: freescale: imx: Fix an error handling path in 'imx_pinctrl_probe()' [ Upstream commit 11d8da5cabf7c6c3263ba2cd9c00260395867048 ] 'pinctrl_unregister()' should not be called to undo 'devm_pinctrl_register_and_init()', it is already handled by the framework. This simplifies the error handling paths of the probe function. The 'imx_free_resources()' can be removed as well. Fixes: a51c158bf0f7 ("pinctrl: imx: use radix trees for groups and functions") Signed-off-by: Christophe JAILLET Reviewed-by: Dong Aisheng Link: https://lore.kernel.org/r/20200530204955.588962-1-christophe.jaillet@wanadoo.fr Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit a3b19dbb1274281f97ed009ff554c76043969176 Author: yu kuai Date: Wed Jun 3 09:35:32 2020 +0800 pinctrl: sirf: add missing put_device() call in sirfsoc_gpio_probe() [ Upstream commit 66339f2fba3fa05b0507e1887e4c6abcfc6228a3 ] A coccicheck run provided information like the following: drivers/pinctrl/sirf/pinctrl-sirf.c:798:2-8: ERROR: missing put_device; call of_find_device_by_node on line 792, but without a corresponding object release within this function. Generated by: scripts/coccinelle/free/put_device.cocci Thus add a jump target to fix the exception handling for this function implementation. Fixes: 5130216265f6 ("PINCTRL: SiRF: add GPIO and GPIO irq support in CSR SiRFprimaII") Signed-off-by: yu kuai Link: https://lore.kernel.org/r/20200603013532.755220-1-yukuai3@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 078820233b048f03fac89e5da529ad0a0b6729c9 Author: Christophe JAILLET Date: Sat May 30 22:19:52 2020 +0200 pinctrl: imxl: Fix an error handling path in 'imx1_pinctrl_core_probe()' [ Upstream commit 9eb728321286c4b31e964d2377fca2368526d408 ] When 'pinctrl_register()' has been turned into 'devm_pinctrl_register()', an error handling path has not been updated. Axe a now unneeded 'pinctrl_unregister()'. Fixes: e55e025d1687 ("pinctrl: imxl: Use devm_pinctrl_register() for pinctrl registration") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/20200530201952.585798-1-christophe.jaillet@wanadoo.fr Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 96cdf5f80a92db9faeb64e87435e7806bdedbd84 Author: Masahiro Yamada Date: Mon Jun 1 14:57:01 2020 +0900 modpost: fix -i (--ignore-errors) MAKEFLAGS detection [ Upstream commit 91e6ee581270b8ae970f028b898314d73f16870b ] $(filter -i,$(MAKEFLAGS)) works only in limited use-cases. The representation of $(MAKEFLAGS) depends on various factors: - GNU Make version (version 3.8x or version 4.x) - The presence of other flags like -j In my experiments, $(MAKEFLAGS) is expanded as follows: * GNU Make 3.8x: * without -j option: --no-print-directory -Rri * with -j option: --no-print-directory -Rr --jobserver-fds=3,4 -j -i * GNU Make 4.x: * without -j option: irR --no-print-directory * with -j option: irR -j --jobserver-fds=3,4 --no-print-directory For GNU Make 4.x, the flags are grouped as 'irR', which does not work. For the single thread build with GNU Make 3.8x, the flags are grouped as '-Rri', which does not work either. To make it work for all cases, do likewise as commit 6f0fa58e4596 ("kbuild: simplify silent build (-s) detection"). BTW, since commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead of $(MODVERDIR)/*.mod"), you also need to pass -k option to build final *.ko files. 'make -i -k' ignores compile errors in modules, and build as many remaining *.ko as possible. Please note this feature is kind of dangerous if other modules depend on the broken module because the generated modules will lack the correct module dependency or CRC. Honestly, I am not a big fan of it, but I am keeping this feature. Fixes: eed380f3f593 ("modpost: Optionally ignore secondary errors seen if a single module build fails") Cc: Guenter Roeck Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit b3dfab4e1fd54a1d4525fb84ceec9f8e5d67dc64 Author: Can Guo Date: Wed May 27 19:24:42 2020 -0700 scsi: ufs: Don't update urgent bkops level when toggling auto bkops [ Upstream commit be32acff43800c87dc5c707f5d47cc607b76b653 ] Urgent bkops level is used to compare against actual bkops status read from UFS device. Urgent bkops level is set during initialization and might be updated in exception event handler during runtime. But it should not be updated to the actual bkops status every time when auto bkops is toggled. Otherwise, if urgent bkops level is updated to 0, auto bkops shall always be kept enabled. Link: https://lore.kernel.org/r/1590632686-17866-1-git-send-email-cang@codeaurora.org Fixes: 24366c2afbb0 ("scsi: ufs: Recheck bkops level if bkops is disabled") Reviewed-by: Stanley Chu Signed-off-by: Can Guo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 786116f29136109bf2b154a4081aae9b6ea09dd6 Author: Qiushi Wu Date: Thu May 28 15:13:53 2020 -0500 scsi: iscsi: Fix reference count leak in iscsi_boot_create_kobj [ Upstream commit 0267ffce562c8bbf9b57ebe0e38445ad04972890 ] kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Link: https://lore.kernel.org/r/20200528201353.14849-1-wu000273@umn.edu Reviewed-by: Lee Duncan Signed-off-by: Qiushi Wu Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit c04bade718d8b6c3be0352960046e544cf264fe5 Author: Bob Peterson Date: Wed Apr 29 08:45:54 2020 -0500 gfs2: Allow lock_nolock mount to specify jid=X [ Upstream commit ea22eee4e6027d8927099de344f7fff43c507ef9 ] Before this patch, a simple typo accidentally added \n to the jid= string for lock_nolock mounts. This made it impossible to mount a gfs2 file system with a journal other than journal0. Thus: mount -tgfs2 -o hostdata="jid=1" Resulted in: mount: wrong fs type, bad option, bad superblock on In most cases this is not a problem. However, for debugging and testing purposes we sometimes want to test the integrity of other journals. This patch removes the unnecessary \n and thus allows lock_nolock users to specify an alternate journal. Signed-off-by: Bob Peterson Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin commit aa21778ddc8b39492d266e4a667734e7ce033ae9 Author: Uwe Kleine-König Date: Thu Apr 16 10:02:45 2020 +0200 pwm: imx27: Fix rounding behavior [ Upstream commit aef1a3799b5cb3ba4841f6034497b179646ccc70 ] To not trigger the warnings provided by CONFIG_PWM_DEBUG - use up-rounding in .get_state() - don't divide by the result of a division - don't use the rounded counter value for the period length to calculate the counter value for the duty cycle Signed-off-by: Uwe Kleine-König Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 14eb4eb5c591a7ae0463d5960b3ba2be6a780ee5 Author: J. Bruce Fields Date: Mon Jun 1 17:44:45 2020 -0400 nfsd4: make drc_slab global, not per-net [ Upstream commit 027690c75e8fd91b60a634d31c4891a6e39d45bd ] I made every global per-network-namespace instead. But perhaps doing that to this slab was a step too far. The kmem_cache_create call in our net init method also seems to be responsible for this lockdep warning: [ 45.163710] Unable to find swap-space signature [ 45.375718] trinity-c1 (855): attempted to duplicate a private mapping with mremap. This is not supported. [ 46.055744] futex_wake_op: trinity-c1 tries to shift op by -209; fix this program [ 51.011723] [ 51.013378] ====================================================== [ 51.013875] WARNING: possible circular locking dependency detected [ 51.014378] 5.2.0-rc2 #1 Not tainted [ 51.014672] ------------------------------------------------------ [ 51.015182] trinity-c2/886 is trying to acquire lock: [ 51.015593] 000000005405f099 (slab_mutex){+.+.}, at: slab_attr_store+0xa2/0x130 [ 51.016190] [ 51.016190] but task is already holding lock: [ 51.016652] 00000000ac662005 (kn->count#43){++++}, at: kernfs_fop_write+0x286/0x500 [ 51.017266] [ 51.017266] which lock already depends on the new lock. [ 51.017266] [ 51.017909] [ 51.017909] the existing dependency chain (in reverse order) is: [ 51.018497] [ 51.018497] -> #1 (kn->count#43){++++}: [ 51.018956] __lock_acquire+0x7cf/0x1a20 [ 51.019317] lock_acquire+0x17d/0x390 [ 51.019658] __kernfs_remove+0x892/0xae0 [ 51.020020] kernfs_remove_by_name_ns+0x78/0x110 [ 51.020435] sysfs_remove_link+0x55/0xb0 [ 51.020832] sysfs_slab_add+0xc1/0x3e0 [ 51.021332] __kmem_cache_create+0x155/0x200 [ 51.021720] create_cache+0xf5/0x320 [ 51.022054] kmem_cache_create_usercopy+0x179/0x320 [ 51.022486] kmem_cache_create+0x1a/0x30 [ 51.022867] nfsd_reply_cache_init+0x278/0x560 [ 51.023266] nfsd_init_net+0x20f/0x5e0 [ 51.023623] ops_init+0xcb/0x4b0 [ 51.023928] setup_net+0x2fe/0x670 [ 51.024315] copy_net_ns+0x30a/0x3f0 [ 51.024653] create_new_namespaces+0x3c5/0x820 [ 51.025257] unshare_nsproxy_namespaces+0xd1/0x240 [ 51.025881] ksys_unshare+0x506/0x9c0 [ 51.026381] __x64_sys_unshare+0x3a/0x50 [ 51.026937] do_syscall_64+0x110/0x10b0 [ 51.027509] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 51.028175] [ 51.028175] -> #0 (slab_mutex){+.+.}: [ 51.028817] validate_chain+0x1c51/0x2cc0 [ 51.029422] __lock_acquire+0x7cf/0x1a20 [ 51.029947] lock_acquire+0x17d/0x390 [ 51.030438] __mutex_lock+0x100/0xfa0 [ 51.030995] mutex_lock_nested+0x27/0x30 [ 51.031516] slab_attr_store+0xa2/0x130 [ 51.032020] sysfs_kf_write+0x11d/0x180 [ 51.032529] kernfs_fop_write+0x32a/0x500 [ 51.033056] do_loop_readv_writev+0x21d/0x310 [ 51.033627] do_iter_write+0x2e5/0x380 [ 51.034148] vfs_writev+0x170/0x310 [ 51.034616] do_pwritev+0x13e/0x160 [ 51.035100] __x64_sys_pwritev+0xa3/0x110 [ 51.035633] do_syscall_64+0x110/0x10b0 [ 51.036200] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 51.036924] [ 51.036924] other info that might help us debug this: [ 51.036924] [ 51.037876] Possible unsafe locking scenario: [ 51.037876] [ 51.038556] CPU0 CPU1 [ 51.039130] ---- ---- [ 51.039676] lock(kn->count#43); [ 51.040084] lock(slab_mutex); [ 51.040597] lock(kn->count#43); [ 51.041062] lock(slab_mutex); [ 51.041320] [ 51.041320] *** DEADLOCK *** [ 51.041320] [ 51.041793] 3 locks held by trinity-c2/886: [ 51.042128] #0: 000000001f55e152 (sb_writers#5){.+.+}, at: vfs_writev+0x2b9/0x310 [ 51.042739] #1: 00000000c7d6c034 (&of->mutex){+.+.}, at: kernfs_fop_write+0x25b/0x500 [ 51.043400] #2: 00000000ac662005 (kn->count#43){++++}, at: kernfs_fop_write+0x286/0x500 Reported-by: kernel test robot Fixes: 3ba75830ce17 "drc containerization" Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 10b7ddff50b3334414c0be4b6009671b18ba4845 Author: Luis Henriques Date: Mon May 18 18:47:26 2020 +0100 ceph: don't return -ESTALE if there's still an open file [ Upstream commit 878dabb64117406abd40977b87544d05bb3031fc ] Similarly to commit 03f219041fdb ("ceph: check i_nlink while converting a file handle to dentry"), this fixes another corner case with name_to_handle_at/open_by_handle_at. The issue has been detected by xfstest generic/467, when doing: - name_to_handle_at("/cephfs/myfile") - open("/cephfs/myfile") - unlink("/cephfs/myfile") - sync; sync; - drop caches - open_by_handle_at() The call to open_by_handle_at should not fail because the file hasn't been deleted yet (only unlinked) and we do have a valid handle to it. -ESTALE shall be returned only if i_nlink is 0 *and* i_count is 1. This patch also makes sure we have LINK caps before checking i_nlink. Signed-off-by: Luis Henriques Reviewed-by: Jeff Layton Acked-by: Amir Goldstein Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin commit bfe0bc40e53ac3198b6696282f83665757f26f67 Author: Ben Skeggs Date: Fri May 29 15:18:47 2020 +1000 drm/nouveau/disp/gm200-: fix NV_PDISP_SOR_HDMI2_CTRL(n) selection [ Upstream commit a1ef8bad506e4ffa0c57ac5f8cb99ab5cbc3b1fc ] This is a SOR register, and not indexed by the bound head. Fixes display not coming up on high-bandwidth HDMI displays under a number of configurations. Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 899501e480d99fa49abc1ceb5debad6eff9e9eda Author: Stafford Horne Date: Wed Apr 22 20:24:11 2020 +0900 openrisc: Fix issue with argument clobbering for clone/fork [ Upstream commit 6bd140e14d9aaa734ec37985b8b20a96c0ece948 ] Working on the OpenRISC glibc port I found that sometimes clone was working strange. That the tls data argument sent in r7 was always wrong. Further investigation revealed that the arguments were getting clobbered in the entry code. This patch removes the code that writes to the argument registers. This was likely due to some old code hanging around. This patch fixes this up for clone and fork. This fork clobber is harmless but also useless so remove. Signed-off-by: Stafford Horne Signed-off-by: Sasha Levin commit 81f7dd514bdce410d63c3fcb9045322f9f4089f3 Author: David Howells Date: Sat May 2 13:38:23 2020 +0100 rxrpc: Adjust /proc/net/rxrpc/calls to display call->debug_id not user_ID [ Upstream commit 32f71aa497cfb23d37149c2ef16ad71fce2e45e2 ] The user ID value isn't actually much use - and leaks a kernel pointer or a userspace value - so replace it with the call debug ID, which appears in trace points. Signed-off-by: David Howells Signed-off-by: Sasha Levin commit ec3b5cb2ac1c5c656df5009d53e344eea1f7bd34 Author: Wei Yongjun Date: Wed Apr 29 09:35:03 2020 +0000 mailbox: zynqmp-ipi: Fix NULL vs IS_ERR() check in zynqmp_ipi_mbox_probe() [ Upstream commit 445aeeb569f8d7904f8cf80b7c6826bb651ef80e ] In case of error, the function devm_ioremap() returns NULL pointer not ERR_PTR(). So we should check whether the return value of devm_ioremap() is NULL instead of IS_ERR. Fixes: 4981b82ba2ff ("mailbox: ZynqMP IPI mailbox controller") Signed-off-by: Wei Yongjun Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit a1d2e5c9f8a4a2087155cd703f255e167232dbac Author: Dan Carpenter Date: Tue Apr 7 12:27:53 2020 +0300 mailbox: imx: Fix return in imx_mu_scu_xlate() [ Upstream commit 1b3a347b7d56aa637157da1b7df225071af1421f ] This called from mbox_request_channel(). The caller is expecting error pointers and not NULL so this "return NULL;" will lead to an Oops. Fixes: 0a67003b1985 ("mailbox: imx: add SCU MU support") Signed-off-by: Dan Carpenter Signed-off-by: Jassi Brar Signed-off-by: Sasha Levin commit bd7de1bf3540150348237d268a33806c54dc61d2 Author: Chuhong Yuan Date: Thu May 28 18:39:50 2020 +0800 rtc: rv3028: Add missed check for devm_regmap_init_i2c() [ Upstream commit c3b29bf6f166f6ed5f04f9c125477358e0e25df8 ] rv3028_probe() misses a check for devm_regmap_init_i2c(). Add the missed check to fix it. Fixes: e6e7376cfd7b ("rtc: rv3028: add new driver") Signed-off-by: Chuhong Yuan Signed-off-by: Alexandre Belloni Link: https://lore.kernel.org/r/20200528103950.912353-1-hslester96@gmail.com Signed-off-by: Sasha Levin commit 0b1d3a4d6d89ee33e69662dc06638370c83d22e5 Author: Qiushi Wu Date: Wed May 27 21:01:09 2020 -0500 vfio/mdev: Fix reference count leak in add_mdev_supported_type [ Upstream commit aa8ba13cae3134b8ef1c1b6879f66372531da738 ] kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Thus, replace kfree() by kobject_put() to fix this issue. Previous commit "b8eb718348b8" fixed a similar problem. Fixes: 7b96953bc640 ("vfio: Mediated device Core driver") Signed-off-by: Qiushi Wu Reviewed-by: Cornelia Huck Reviewed-by: Kirti Wankhede Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 626fac3985a38fb6a1fd7265c100cf710f614809 Author: Kai Vehmanen Date: Fri May 29 19:03:58 2020 +0300 ASoC: SOF: Intel: hda: fix generic hda codec support [ Upstream commit 89d73ccab20a684d8446cea4d8ac6a2608c8d390 ] Add support for using generic codec driver with SOF. Generic driver is used if: - snd_sof_intel_hda_common.hda_model="generic" is set, or - fallback if no other codec driver is found The implementation is aligned with snd-hda-intel driver, and fixes audio support for systems like Acer Swift 3 SF314-57G, on which this issue was originally reported. Signed-off-by: Kai Vehmanen Reviewed-by: Hui Wang Reviewed-by: Guennadi Liakhovetski Reviewed-by: Pierre-Louis Bossart BugLink: https://github.com/thesofproject/linux/issues/1807 BugLink: https://bugs.launchpad.net/bugs/1877757 Link: https://lore.kernel.org/r/20200529160358.12134-1-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit af023099d1dbd3b72c205957ce7477dd4a894621 Author: Xiyu Yang Date: Mon May 25 22:12:46 2020 +0800 ASoC: fsl_asrc_dma: Fix dma_chan leak when config DMA channel failed [ Upstream commit 36124fb19f1ae68a500cd76a76d40c6e81bee346 ] fsl_asrc_dma_hw_params() invokes dma_request_channel() or fsl_asrc_get_dma_channel(), which returns a reference of the specified dma_chan object to "pair->dma_chan[dir]" with increased refcnt. The reference counting issue happens in one exception handling path of fsl_asrc_dma_hw_params(). When config DMA channel failed for Back-End, the function forgets to decrease the refcnt increased by dma_request_channel() or fsl_asrc_get_dma_channel(), causing a refcnt leak. Fix this issue by calling dma_release_channel() when config DMA channel failed. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Link: https://lore.kernel.org/r/1590415966-52416-1-git-send-email-xiyuyang19@fudan.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0ff9a6d7c502b33a662fe360701ff4b203e6df86 Author: Martin Blumenstingl Date: Tue May 26 22:29:42 2020 +0200 usb: dwc3: meson-g12a: fix error path when fetching the reset line fails [ Upstream commit be8c1001a7e681e8813882a42ed51c8dbffd8800 ] Disable and unprepare the clocks when devm_reset_control_get_shared() fails. This fixes the error path as this must disable the clocks which were previously enabled. Fixes: 1e355f21d3fb96 ("usb: dwc3: Add Amlogic A1 DWC3 glue") Cc: Yue Wang Cc: Hanjie Lin Acked-by: Neil Armstrong Signed-off-by: Martin Blumenstingl Link: https://lore.kernel.org/r/20200526202943.715220-2-martin.blumenstingl@googlemail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 834d4dd15395d6b022baad9211483ccfc99ec4cf Author: Christophe JAILLET Date: Sun May 10 11:53:03 2020 +0200 extcon: adc-jack: Fix an error handling path in 'adc_jack_probe()' [ Upstream commit bc84cff2c92ae5ccb2c37da73756e7174b1b430f ] In some error handling paths, a call to 'iio_channel_get()' is not balanced by a corresponding call to 'iio_channel_release()'. This can be achieved easily by using the devm_ variant of 'iio_channel_get()'. This has the extra benefit to simplify the remove function. Fixes: 19939860dcae ("extcon: adc_jack: adc-jack driver to support 3.5 pi or simliar devices") Signed-off-by: Christophe JAILLET Signed-off-by: Chanwoo Choi Signed-off-by: Sasha Levin commit e993b8a59cc284caebf8dc281182dc6b642315ba Author: Nicholas Piggin Date: Wed Apr 29 16:56:50 2020 +1000 powerpc/64s/kuap: Add missing isync to KUAP restore paths [ Upstream commit cb2b53cbffe3c388cd676b63f34e54ceb2643ae2 ] Writing the AMR register is documented to require context synchronizing operations before and after, for it to take effect as expected. The KUAP restore at interrupt exit time deliberately avoids the isync after the AMR update because it only needs to take effect after the context synchronizing RFID that soon follows. Add a comment for this. The missing isync before the update doesn't have an obvious justification, and seems it could theoretically allow a rogue user access to leak past the AMR update. Add isyncs for these. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200429065654.1677541-3-npiggin@gmail.com Signed-off-by: Sasha Levin commit 295c688d4f4adb624ad3dde731e9f135aaa55f18 Author: huhai Date: Thu May 21 17:26:48 2020 +1000 powerpc/4xx: Don't unmap NULL mbase [ Upstream commit bcec081ecc940fc38730b29c743bbee661164161 ] Signed-off-by: huhai Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200521072648.1254699-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 394ee307a8867774134ebf61fe5ccacbf4d2156e Author: Nathan Chancellor Date: Mon May 18 11:10:43 2020 -0700 input: i8042 - Remove special PowerPC handling [ Upstream commit e4f4ffa8a98c24a4ab482669b1e2b4cfce3f52f4 ] This causes a build error with CONFIG_WALNUT because kb_cs and kb_data were removed in commit 917f0af9e5a9 ("powerpc: Remove arch/ppc and include/asm-ppc"). ld.lld: error: undefined symbol: kb_cs > referenced by i8042-ppcio.h:28 (drivers/input/serio/i8042-ppcio.h:28) > input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a > referenced by i8042-ppcio.h:28 (drivers/input/serio/i8042-ppcio.h:28) > input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a > referenced by i8042-ppcio.h:28 (drivers/input/serio/i8042-ppcio.h:28) > input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a ld.lld: error: undefined symbol: kb_data > referenced by i8042.c:309 (drivers/input/serio/i8042.c:309) > input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a > referenced by i8042-ppcio.h:33 (drivers/input/serio/i8042-ppcio.h:33) > input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a > referenced by i8042.c:319 (drivers/input/serio/i8042.c:319) > input/serio/i8042.o:(__i8042_command) in archive drivers/built-in.a > referenced 15 more times Presumably since nobody has noticed this for the last 12 years, there is not anyone actually trying to use this driver so we can just remove this special walnut code and use the generic header so it builds for all configurations. Fixes: 917f0af9e5a9 ("powerpc: Remove arch/ppc and include/asm-ppc") Reported-by: kbuild test robot Signed-off-by: Nathan Chancellor Signed-off-by: Michael Ellerman Acked-by: Dmitry Torokhov Link: https://lore.kernel.org/r/20200518181043.3363953-1-natechancellor@gmail.com Signed-off-by: Sasha Levin commit 40dca4cc1279284a753c1461db02efb45f2a937f Author: Arnd Bergmann Date: Wed May 27 15:37:34 2020 +0200 ARM: davinci: fix build failure without I2C [ Upstream commit 147922f91965e734664374a3f226adfeaa586d72 ] The two supplies are referenced outside of #ifdef CONFIG_I2C but defined inside, which breaks the build if that is not built-in: mach-davinci/board-dm644x-evm.c:861:21: error: use of undeclared identifier 'fixed_supplies_1_8v' ARRAY_SIZE(fixed_supplies_1_8v), 1800000); ^ mach-davinci/board-dm644x-evm.c:861:21: error: use of undeclared identifier 'fixed_supplies_1_8v' mach-davinci/board-dm644x-evm.c:861:21: error: use of undeclared identifier 'fixed_supplies_1_8v' mach-davinci/board-dm644x-evm.c:860:49: error: use of undeclared identifier 'fixed_supplies_1_8v' regulator_register_always_on(0, "fixed-dummy", fixed_supplies_1_8v, I don't know if the regulators are used anywhere without I2C, but always registering them seems to be the safe choice here. On a related note, it might be best to also deal with CONFIG_I2C=m across the file, unless this is going to be moved to DT and removed really soon anyway. Link: https://lore.kernel.org/r/20200527133746.643895-1-arnd@arndb.de Fixes: 5e06d19694a4 ("ARM: davinci: dm644x-evm: Add Fixed regulators needed for tlv320aic33") Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 837a7d741285d223e2f362946f037e4866c16800 Author: Dan Carpenter Date: Wed May 20 15:04:14 2020 +0300 of: Fix a refcounting bug in __of_attach_node_sysfs() [ Upstream commit 8a325dd06f2358ea0888e4ff1c9ca4bc23bd53f3 ] The problem in this code is that if kobject_add() fails, then it should call of_node_put(np) to drop the reference count. I've actually moved the of_node_get(np) later in the function to avoid needing to do clean up. Fixes: 5b2c2f5a0ea3 ("of: overlay: add missing of_node_get() in __of_attach_node_sysfs") Signed-off-by: Dan Carpenter Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 52acdac16b0cae3513c330ace979f26b6ea28fee Author: Olga Kornievskaia Date: Sun Apr 26 11:30:00 2020 -0400 NFSv4.1 fix rpc_call_done assignment for BIND_CONN_TO_SESSION [ Upstream commit 1c709b766e73e54d64b1dde1b7cfbcf25bcb15b9 ] Fixes: 02a95dee8cf0 ("NFS add callback_ops to nfs4_proc_bind_conn_to_session_callback") Signed-off-by: Olga Kornievskaia Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit 11d93416617f49e6ef701a4a2f14664ca2440e17 Author: Fedor Tokarev Date: Sat Mar 28 14:56:55 2020 +0300 net: sunrpc: Fix off-by-one issues in 'rpc_ntop6' [ Upstream commit 118917d696dc59fd3e1741012c2f9db2294bed6f ] Fix off-by-one issues in 'rpc_ntop6': - 'snprintf' returns the number of characters which would have been written if enough space had been available, excluding the terminating null byte. Thus, a return value of 'sizeof(scopebuf)' means that the last character was dropped. - 'strcat' adds a terminating null byte to the string, thus if len == buflen, the null byte is written past the end of the buffer. Signed-off-by: Fedor Tokarev Signed-off-by: Anna Schumaker Signed-off-by: Sasha Levin commit e4b615bf52d69e4eb2f25f0cb5314ffae22cbd14 Author: Charles Keepax Date: Tue May 26 17:19:30 2020 +0100 ASoC: dapm: Move dai_link widgets to runtime to fix use after free [ Upstream commit f4aa5e214eeaf7f1c7f157526a5aa29784cb6a1f ] The newly added CODEC to CODEC DAI link widget pointers in snd_soc_dai_link are better placed in snd_soc_pcm_runtime. snd_soc_dai_link is really intended for static configuration of the DAI, and the runtime for dynamic data. The snd_soc_dai_link structures are not destroyed if the card is unbound. The widgets are cleared up on unbind, however if the card is rebound as the snd_soc_dai_link structures are reused these pointers will be left at their old values, causing access to freed memory. Fixes: 595571cca4de ("ASoC: dapm: Fix regression introducing multiple copies of DAI widgets") Signed-off-by: Charles Keepax Link: https://lore.kernel.org/r/20200526161930.30759-1-ckeepax@opensource.cirrus.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 82cb5f72ad22e7cf7ddd3e52f93c2eac6182c2db Author: Dan Williams Date: Thu May 21 14:06:17 2020 -0700 /dev/mem: Revoke mappings when a driver claims the region [ Upstream commit 3234ac664a870e6ea69ae3a57d824cd7edbeacc5 ] Close the hole of holding a mapping over kernel driver takeover event of a given address range. Commit 90a545e98126 ("restrict /dev/mem to idle io memory ranges") introduced CONFIG_IO_STRICT_DEVMEM with the goal of protecting the kernel against scenarios where a /dev/mem user tramples memory that a kernel driver owns. However, this protection only prevents *new* read(), write() and mmap() requests. Established mappings prior to the driver calling request_mem_region() are left alone. Especially with persistent memory, and the core kernel metadata that is stored there, there are plentiful scenarios for a /dev/mem user to violate the expectations of the driver and cause amplified damage. Teach request_mem_region() to find and shoot down active /dev/mem mappings that it believes it has successfully claimed for the exclusive use of the driver. Effectively a driver call to request_mem_region() becomes a hole-punch on the /dev/mem device. The typical usage of unmap_mapping_range() is part of truncate_pagecache() to punch a hole in a file, but in this case the implementation is only doing the "first half" of a hole punch. Namely it is just evacuating current established mappings of the "hole", and it relies on the fact that /dev/mem establishes mappings in terms of absolute physical address offsets. Once existing mmap users are invalidated they can attempt to re-establish the mapping, or attempt to continue issuing read(2) / write(2) to the invalidated extent, but they will then be subject to the CONFIG_IO_STRICT_DEVMEM checking that can block those subsequent accesses. Cc: Arnd Bergmann Cc: Ingo Molnar Cc: Kees Cook Cc: Matthew Wilcox Cc: Russell King Cc: Andrew Morton Cc: Greg Kroah-Hartman Fixes: 90a545e98126 ("restrict /dev/mem to idle io memory ranges") Signed-off-by: Dan Williams Reviewed-by: Kees Cook Link: https://lore.kernel.org/r/159009507306.847224.8502634072429766747.stgit@dwillia2-desk3.amr.corp.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cf51d0911f3eb074a97b6d12e315ffd2be9fa050 Author: John Hubbard Date: Tue May 26 18:26:26 2020 -0700 misc: xilinx-sdfec: improve get_user_pages_fast() error handling [ Upstream commit 57343d51613227373759f5b0f2eede257fd4b82e ] This fixes the case of get_user_pages_fast() returning a -errno. The result needs to be stored in a signed integer. And for safe signed/unsigned comparisons, it's best to keep everything signed. And get_user_pages_fast() also expects a signed value for number of pages to pin. Therefore, change most relevant variables, from u32 to int. Leave "n" unsigned, for convenience in checking for overflow. And provide a WARN_ON_ONCE() and early return, if overflow occurs. Also, as long as we're tidying up: rename the page array from page, to pages, in order to match the conventions used in most other call sites. Fixes: 20ec628e8007e ("misc: xilinx_sdfec: Add ability to configure LDPC") Cc: Derek Kiernan Cc: Dragan Cvetic Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Michal Simek Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: John Hubbard Link: https://lore.kernel.org/r/20200527012628.1100649-2-jhubbard@nvidia.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c06a864367bf2c01a1c889f7fdc540ce7cada1bf Author: Eddie James Date: Wed Apr 8 15:36:16 2020 -0500 clk: ast2600: Fix AHB clock divider for A1 [ Upstream commit 2d491066ccd4286538450c227fc5094ceb04b494 ] The latest specs for the AST2600 A1 chip include some different bit definitions for calculating the AHB clock divider. Implement these in order to get the correct AHB clock value in Linux. Signed-off-by: Eddie James Link: https://lkml.kernel.org/r/20200408203616.4031-1-eajames@linux.ibm.com Fixes: d3d04f6c330a ("clk: Add support for AST2600 SoC") Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 1e84ccf45937c66137a568ed8b3d127591127a2a Author: Chunyan Zhang Date: Tue May 19 11:00:36 2020 +0800 clk: sprd: return correct type of value for _sprd_pll_recalc_rate [ Upstream commit c2f30986d418f26abefc2eec90ebf06716c970d2 ] The function _sprd_pll_recalc_rate() defines return value to unsigned long, but it would return a negative value when malloc fail, changing to return its parent_rate makes more sense, since if the callback .recalc_rate() is not set, the framework returns the parent_rate as well. Fixes: 3e37b005580b ("clk: sprd: add adjustable pll support") Signed-off-by: Chunyan Zhang Link: https://lkml.kernel.org/r/20200519030036.1785-2-zhang.lyra@gmail.com Reviewed-by: Baolin Wang Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 97428a8bc94decef3c5b4cbd1346c4ae2fe1b838 Author: Laurent Dufour Date: Wed May 20 19:43:08 2020 +0200 KVM: PPC: Book3S HV: Relax check on H_SVM_INIT_ABORT [ Upstream commit e3326ae3d59e443a379367c6936941d6ab55d316 ] The commit 8c47b6ff29e3 ("KVM: PPC: Book3S HV: Check caller of H_SVM_* Hcalls") added checks of secure bit of SRR1 to filter out the Hcall reserved to the Ultravisor. However, the Hcall H_SVM_INIT_ABORT is made by the Ultravisor passing the context of the VM calling UV_ESM. This allows the Hypervisor to return to the guest without going through the Ultravisor. Thus the Secure bit of SRR1 is not set in that particular case. In the case a regular VM is calling H_SVM_INIT_ABORT, this hcall will be filtered out in kvmppc_h_svm_init_abort() because kvm->arch.secure_guest is not set in that case. Fixes: 8c47b6ff29e3 ("KVM: PPC: Book3S HV: Check caller of H_SVM_* Hcalls") Signed-off-by: Laurent Dufour Reviewed-by: Greg Kurz Reviewed-by: Ram Pai Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit 0ca64e49424e19f35b3435eebfa39ac4855d60d2 Author: Qian Cai Date: Sun May 10 01:18:34 2020 -0400 KVM: PPC: Book3S: Fix some RCU-list locks [ Upstream commit ab8b65be183180c3eef405d449163964ecc4b571 ] It is unsafe to traverse kvm->arch.spapr_tce_tables and stt->iommu_tables without the RCU read lock held. Also, add cond_resched_rcu() in places with the RCU read lock held that could take a while to finish. arch/powerpc/kvm/book3s_64_vio.c:76 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 no locks held by qemu-kvm/4265. stack backtrace: CPU: 96 PID: 4265 Comm: qemu-kvm Not tainted 5.7.0-rc4-next-20200508+ #2 Call Trace: [c000201a8690f720] [c000000000715948] dump_stack+0xfc/0x174 (unreliable) [c000201a8690f770] [c0000000001d9470] lockdep_rcu_suspicious+0x140/0x164 [c000201a8690f7f0] [c008000010b9fb48] kvm_spapr_tce_release_iommu_group+0x1f0/0x220 [kvm] [c000201a8690f870] [c008000010b8462c] kvm_spapr_tce_release_vfio_group+0x54/0xb0 [kvm] [c000201a8690f8a0] [c008000010b84710] kvm_vfio_destroy+0x88/0x140 [kvm] [c000201a8690f8f0] [c008000010b7d488] kvm_put_kvm+0x370/0x600 [kvm] [c000201a8690f990] [c008000010b7e3c0] kvm_vm_release+0x38/0x60 [kvm] [c000201a8690f9c0] [c0000000005223f4] __fput+0x124/0x330 [c000201a8690fa20] [c000000000151cd8] task_work_run+0xb8/0x130 [c000201a8690fa70] [c0000000001197e8] do_exit+0x4e8/0xfa0 [c000201a8690fb70] [c00000000011a374] do_group_exit+0x64/0xd0 [c000201a8690fbb0] [c000000000132c90] get_signal+0x1f0/0x1200 [c000201a8690fcc0] [c000000000020690] do_notify_resume+0x130/0x3c0 [c000201a8690fda0] [c000000000038d64] syscall_exit_prepare+0x1a4/0x280 [c000201a8690fe20] [c00000000000c8f8] system_call_common+0xf8/0x278 ==== arch/powerpc/kvm/book3s_64_vio.c:368 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 2 locks held by qemu-kvm/4264: #0: c000201ae2d000d8 (&vcpu->mutex){+.+.}-{3:3}, at: kvm_vcpu_ioctl+0xdc/0x950 [kvm] #1: c000200c9ed0c468 (&kvm->srcu){....}-{0:0}, at: kvmppc_h_put_tce+0x88/0x340 [kvm] ==== arch/powerpc/kvm/book3s_64_vio.c:108 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by qemu-kvm/4257: #0: c000200b1b363a40 (&kv->lock){+.+.}-{3:3}, at: kvm_vfio_set_attr+0x598/0x6c0 [kvm] ==== arch/powerpc/kvm/book3s_64_vio.c:146 RCU-list traversed in non-reader section!! other info that might help us debug this: rcu_scheduler_active = 2, debug_locks = 1 1 lock held by qemu-kvm/4257: #0: c000200b1b363a40 (&kv->lock){+.+.}-{3:3}, at: kvm_vfio_set_attr+0x598/0x6c0 [kvm] Signed-off-by: Qian Cai Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit 8b15b0d3956bb54d34ac35698c977ab77a26b2ad Author: Qian Cai Date: Wed May 13 09:39:15 2020 -0400 KVM: PPC: Book3S HV: Ignore kmemleak false positives [ Upstream commit 0aca8a5575544bd21b3363058afb8f1e81505150 ] kvmppc_pmd_alloc() and kvmppc_pte_alloc() allocate some memory but then pud_populate() and pmd_populate() will use __pa() to reference the newly allocated memory. Since kmemleak is unable to track the physical memory resulting in false positives, silence those by using kmemleak_ignore(). unreferenced object 0xc000201c382a1000 (size 4096): comm "qemu-kvm", pid 124828, jiffies 4295733767 (age 341.250s) hex dump (first 32 bytes): c0 00 20 09 f4 60 03 87 c0 00 20 10 72 a0 03 87 .. ..`.... .r... c0 00 20 0e 13 a0 03 87 c0 00 20 1b dc c0 03 87 .. ....... ..... backtrace: [<000000004cc2790f>] kvmppc_create_pte+0x838/0xd20 [kvm_hv] kvmppc_pmd_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:366 (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:590 [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv] [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv] [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv] [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv] [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm] [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm] [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm] [<0000000048155cd6>] ksys_ioctl+0xd8/0x130 [<0000000041ffeaa7>] sys_ioctl+0x28/0x40 [<000000004afc4310>] system_call_exception+0x114/0x1e0 [<00000000fb70a873>] system_call_common+0xf0/0x278 unreferenced object 0xc0002001f0c03900 (size 256): comm "qemu-kvm", pid 124830, jiffies 4295735235 (age 326.570s) hex dump (first 32 bytes): c0 00 20 10 fa a0 03 87 c0 00 20 10 fa a1 03 87 .. ....... ..... c0 00 20 10 fa a2 03 87 c0 00 20 10 fa a3 03 87 .. ....... ..... backtrace: [<0000000023f675b8>] kvmppc_create_pte+0x854/0xd20 [kvm_hv] kvmppc_pte_alloc at arch/powerpc/kvm/book3s_64_mmu_radix.c:356 (inlined by) kvmppc_create_pte at arch/powerpc/kvm/book3s_64_mmu_radix.c:593 [<00000000d123c49a>] kvmppc_book3s_instantiate_page+0x2e0/0x8c0 [kvm_hv] [<00000000bb549087>] kvmppc_book3s_radix_page_fault+0x1b4/0x2b0 [kvm_hv] [<0000000086dddc0e>] kvmppc_book3s_hv_page_fault+0x214/0x12a0 [kvm_hv] [<000000005ae9ccc2>] kvmppc_vcpu_run_hv+0xc5c/0x15f0 [kvm_hv] [<00000000d22162ff>] kvmppc_vcpu_run+0x34/0x48 [kvm] [<00000000d6953bc4>] kvm_arch_vcpu_ioctl_run+0x314/0x420 [kvm] [<000000002543dd54>] kvm_vcpu_ioctl+0x33c/0x950 [kvm] [<0000000048155cd6>] ksys_ioctl+0xd8/0x130 [<0000000041ffeaa7>] sys_ioctl+0x28/0x40 [<000000004afc4310>] system_call_exception+0x114/0x1e0 [<00000000fb70a873>] system_call_common+0xf0/0x278 Signed-off-by: Qian Cai Signed-off-by: Paul Mackerras Signed-off-by: Sasha Levin commit ca46bd432f1cd13718a42b26859990ffd46559c1 Author: Vignesh Raghavendra Date: Tue May 26 15:33:40 2020 +0530 scsi: ufs: ti-j721e-ufs: Fix unwinding of pm_runtime changes [ Upstream commit 22617e21633142dd2b81541cb3b95d6fb59aa85f ] Fix unwinding of pm_runtime changes when bailing out of driver probe due to a failure and also on removal of driver. Link: https://lore.kernel.org/r/20200526100340.15032-1-vigneshr@ti.com Fixes: 6979e56cec97 ("scsi: ufs: Add driver for TI wrapper for Cadence UFS IP") Reported-by: Dinghao Liu Signed-off-by: Vignesh Raghavendra Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7fdbc547624b85497b1da5fd61577afd0874b5ab Author: Gabriel Krisman Bertazi Date: Tue May 19 22:29:59 2020 -0400 scsi: iscsi: Fix deadlock on recovery path during GFP_IO reclaim [ Upstream commit 7e7cd796f2776d055351d80328f45633bbb0aae5 ] iSCSI suffers from a deadlock in case a management command submitted via the netlink socket sleeps on an allocation while holding the rx_queue_mutex if that allocation causes a memory reclaim that writebacks to a failed iSCSI device. The recovery procedure can never make progress to recover the failed disk or abort outstanding IO operations to complete the reclaim (since rx_queue_mutex is locked), thus locking the system. Nevertheless, just marking all allocations under rx_queue_mutex as GFP_NOIO (or locking the userspace process with something like PF_MEMALLOC_NOIO) is not enough, since the iSCSI command code relies on other subsystems that try to grab locked mutexes, whose threads are GFP_IO, leading to the same deadlock. One instance where this situation can be observed is in the backtraces below, stitched from multiple bugs reports, involving the kobj uevent sent when a session is created. The root of the problem is not the fact that iSCSI does GFP_IO allocations, that is acceptable. The actual problem is that rx_queue_mutex has a very large granularity, covering every unrelated netlink command execution at the same time as the error recovery path. The proposed fix leverages the recently added mechanism to stop failed connections from the kernel, by enabling it to execute even though a management command from the netlink socket is being run (rx_queue_mutex is held), provided that the command is known to be safe. It splits the rx_queue_mutex in two mutexes, one protecting from concurrent command execution from the netlink socket, and one protecting stop_conn from racing with other connection management operations that might conflict with it. It is not very pretty, but it is the simplest way to resolve the deadlock. I considered making it a lock per connection, but some external mutex would still be needed to deal with iscsi_if_destroy_conn. The patch was tested by forcing a memory shrinker (unrelated, but used bufio/dm-verity) to reclaim iSCSI pages every time ISCSI_UEVENT_CREATE_SESSION happens, which is reasonable to simulate reclaims that might happen with GFP_KERNEL on that path. Then, a faulty hung target causes a connection to fail during intensive IO, at the same time a new session is added by iscsid. The following stacktraces are stiches from several bug reports, showing a case where the deadlock can happen. iSCSI-write holding: rx_queue_mutex waiting: uevent_sock_mutex kobject_uevent_env+0x1bd/0x419 kobject_uevent+0xb/0xd device_add+0x48a/0x678 scsi_add_host_with_dma+0xc5/0x22d iscsi_host_add+0x53/0x55 iscsi_sw_tcp_session_create+0xa6/0x129 iscsi_if_rx+0x100/0x1247 netlink_unicast+0x213/0x4f0 netlink_sendmsg+0x230/0x3c0 iscsi_fail iscsi_conn_failure waiting: rx_queue_mutex schedule_preempt_disabled+0x325/0x734 __mutex_lock_slowpath+0x18b/0x230 mutex_lock+0x22/0x40 iscsi_conn_failure+0x42/0x149 worker_thread+0x24a/0xbc0 EventManager_ holding: uevent_sock_mutex waiting: dm_bufio_client->lock dm_bufio_lock+0xe/0x10 shrink+0x34/0xf7 shrink_slab+0x177/0x5d0 do_try_to_free_pages+0x129/0x470 try_to_free_mem_cgroup_pages+0x14f/0x210 memcg_kmem_newpage_charge+0xa6d/0x13b0 __alloc_pages_nodemask+0x4a3/0x1a70 fallback_alloc+0x1b2/0x36c __kmalloc_node_track_caller+0xb9/0x10d0 __alloc_skb+0x83/0x2f0 kobject_uevent_env+0x26b/0x419 dm_kobject_uevent+0x70/0x79 dev_suspend+0x1a9/0x1e7 ctl_ioctl+0x3e9/0x411 dm_ctl_ioctl+0x13/0x17 do_vfs_ioctl+0xb3/0x460 SyS_ioctl+0x5e/0x90 MemcgReclaimerD" holding: dm_bufio_client->lock waiting: stuck io to finish (needs iscsi_fail thread to progress) schedule at ffffffffbd603618 io_schedule at ffffffffbd603ba4 do_io_schedule at ffffffffbdaf0d94 __wait_on_bit at ffffffffbd6008a6 out_of_line_wait_on_bit at ffffffffbd600960 wait_on_bit.constprop.10 at ffffffffbdaf0f17 __make_buffer_clean at ffffffffbdaf18ba __cleanup_old_buffer at ffffffffbdaf192f shrink at ffffffffbdaf19fd do_shrink_slab at ffffffffbd6ec000 shrink_slab at ffffffffbd6ec24a do_try_to_free_pages at ffffffffbd6eda09 try_to_free_mem_cgroup_pages at ffffffffbd6ede7e mem_cgroup_resize_limit at ffffffffbd7024c0 mem_cgroup_write at ffffffffbd703149 cgroup_file_write at ffffffffbd6d9c6e sys_write at ffffffffbd6662ea system_call_fastpath at ffffffffbdbc34a2 Link: https://lore.kernel.org/r/20200520022959.1912856-1-krisman@collabora.com Reported-by: Khazhismel Kumykov Reviewed-by: Lee Duncan Signed-off-by: Gabriel Krisman Bertazi Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8cf6d686d616e1615e7cdf77c3839c773fd07390 Author: Tejas Patel Date: Mon Mar 2 13:50:41 2020 -0800 clk: zynqmp: Fix divider2 calculation [ Upstream commit b8c1049c68d634a412ed5980ae666ed7c8839305 ] zynqmp_get_divider2_val() calculates, divider value of type DIV2 clock, considering best possible combination of DIV1 and DIV2. To find best possible values of DIV1 and DIV2, DIV1's parent rate should be consider and not DIV2's parent rate since it would rate of div1 clock. Consider a below topology, out_clk->div2_clk->div1_clk->fixed_parent where out_clk = (fixed_parent/div1_clk) / div2_clk, so parent clock of div1_clk (i.e. out_clk) should be divided by div1_clk and div2_clk. Existing code divides parent rate of div2_clk's clock instead of div1_clk's parent rate, which is wrong. Fix the same by considering div1's parent clock rate. Fixes: 4ebd92d2e228 ("clk: zynqmp: Fix divider calculation") Signed-off-by: Tejas Patel Signed-off-by: Jolly Shah Link: https://lkml.kernel.org/r/1583185843-20707-3-git-send-email-jolly.shah@xilinx.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 6f7f3052e9418eb0e039c971b85cf00501ed43f6 Author: Jeffrey Hugo Date: Mon May 25 13:41:25 2020 -0700 scsi: ufs-qcom: Fix scheduling while atomic issue [ Upstream commit 3be60b564de49875e47974c37fabced893cd0931 ] ufs_qcom_dump_dbg_regs() uses usleep_range, a sleeping function, but can be called from atomic context in the following flow: ufshcd_intr -> ufshcd_sl_intr -> ufshcd_check_errors -> ufshcd_print_host_regs -> ufshcd_vops_dbg_register_dump -> ufs_qcom_dump_dbg_regs This causes a boot crash on the Lenovo Miix 630 when the interrupt is handled on the idle thread. Fix the issue by switching to udelay(). Link: https://lore.kernel.org/r/20200525204125.46171-1-jeffrey.l.hugo@gmail.com Fixes: 9c46b8676271 ("scsi: ufs-qcom: dump additional testbus registers") Reviewed-by: Bean Huo Reviewed-by: Avri Altman Signed-off-by: Jeffrey Hugo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 89cfdc5230706dc270f8bfe42185ed51992902bb Author: Nathan Chancellor Date: Sat May 16 01:08:06 2020 -0700 clk: bcm2835: Fix return type of bcm2835_register_gate [ Upstream commit f376c43bec4f8ee8d1ba5c5c4cfbd6e84fb279cb ] bcm2835_register_gate is used as a callback for the clk_register member of bcm2835_clk_desc, which expects a struct clk_hw * return type but bcm2835_register_gate returns a struct clk *. This discrepancy is hidden by the fact that bcm2835_register_gate is cast to the typedef bcm2835_clk_register by the _REGISTER macro. This turns out to be a control flow integrity violation, which is how this was noticed. Change the return type of bcm2835_register_gate to be struct clk_hw * and use clk_hw_register_gate to do so. This should be a non-functional change as clk_register_gate calls clk_hw_register_gate anyways but this is needed to avoid issues with further changes. Fixes: b19f009d4510 ("clk: bcm2835: Migrate to clk_hw based registration and OF APIs") Link: https://github.com/ClangBuiltLinux/linux/issues/1028 Signed-off-by: Nathan Chancellor Link: https://lkml.kernel.org/r/20200516080806.1459784-1-natechancellor@gmail.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 510fe47005f3d13d910363cae086d5b71daf1ce2 Author: Dan Carpenter Date: Sat May 23 13:11:29 2020 +0300 scsi: target: tcmu: Fix a use after free in tcmu_check_expired_queue_cmd() [ Upstream commit 9d7464b18892332e35ff37f0b024429a1a9835e6 ] The pr_debug() dereferences "cmd" after we already freed it by calling tcmu_free_cmd(cmd). The debug printk needs to be done earlier. Link: https://lore.kernel.org/r/20200523101129.GB98132@mwanda Fixes: 61fb24822166 ("scsi: target: tcmu: Userspace must not complete queued commands") Reviewed-by: Mike Christie Reviewed-by: David Disseldorp Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit e1377dc0715c4b2b03f8085927fda5db37c3b5b5 Author: Qiushi Wu Date: Mon May 25 00:50:11 2020 -0500 ASoC: fix incomplete error-handling in img_i2s_in_probe. [ Upstream commit 25bf943e4e7b47282bd86ae7d39e039217ebb007 ] Function "pm_runtime_get_sync()" is not handled by "pm_runtime_put()" if "PTR_ERR(rst) == -EPROBE_DEFER". Fix this issue by adding "pm_runtime_put()" into this error path. Fixes: f65bb92ca12e ("ASoC: img-i2s-in: Add runtime PM") Signed-off-by: Qiushi Wu Link: https://lore.kernel.org/r/20200525055011.31925-1-wu000273@umn.edu Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ad8379a6bd907e8bed907c641d9d7917a870c76e Author: Christophe Leroy Date: Tue May 19 05:49:07 2020 +0000 powerpc/8xx: Drop CONFIG_8xx_COPYBACK option [ Upstream commit d3efcd38c0b99162d889e36a30425345a18edb33 ] CONFIG_8xx_COPYBACK was there to help disabling copyback cache mode for debuging hardware. But nobody will design new boards with 8xx now. All 8xx platforms select it, so make it the default and remove the option. Also remove the Mx_RESETVAL values which are pretty useless and hide the real value while reading code. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/bcc968cda075516eb76e2f25e09821f582c566b4.1589866984.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 09686a9f63ff362a2ac312900d4c75753be38833 Author: Christophe Leroy Date: Tue May 19 05:48:56 2020 +0000 powerpc/32s: Don't warn when mapping RO data ROX. [ Upstream commit 4b19f96a81bceaf0bcf44d79c0855c61158065ec ] Mapping RO data as ROX is not an issue since that data cannot be modified to introduce an exploit. PPC64 accepts to have RO data mapped ROX, as a trade off between kernel size and strictness of protection. On PPC32, kernel size is even more critical as amount of memory is usually small. Depending on the number of available IBATs, the last IBATs might overflow the end of text. Only warn if it crosses the end of RO data. Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/6499f8eeb2a36330e5c9fc1cee9a79374875bd54.1589866984.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit c3283b65a882b838995d7f77540ea2eb22729935 Author: Wei Yongjun Date: Mon Apr 27 12:29:22 2020 +0000 mfd: wcd934x: Drop kfree for memory allocated with devm_kzalloc [ Upstream commit 652b7b6740eb52d98377a881c7730e36997f00ab ] It's not necessary to free memory allocated with devm_kzalloc and using kfree leads to a double free. Fixes: 6ac7e4d7ad70 ("mfd: wcd934x: Add support to wcd9340/wcd9341 codec") Signed-off-by: Wei Yongjun Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 8fd0afd8bc11f841cc49dd383864cbb058b73fcb Author: Amelie Delaunay Date: Wed Apr 22 11:08:33 2020 +0200 mfd: stmfx: Disable IRQ in suspend to avoid spurious interrupt [ Upstream commit 97eda5dcc2cde5dcc778bef7a9344db3b6bf8ef5 ] When STMFX supply is stopped, spurious interrupt can occur. To avoid that, disable the interrupt in suspend before disabling the regulator and re-enable it at the end of resume. Fixes: 06252ade9156 ("mfd: Add ST Multi-Function eXpander (STMFX) core driver") Signed-off-by: Amelie Delaunay Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 7951ecb467bbdb7f612f1e175af37777b10c092c Author: Amelie Delaunay Date: Wed Apr 22 11:08:32 2020 +0200 mfd: stmfx: Fix stmfx_irq_init error path [ Upstream commit 60c2c4bcb9202acad4cc26af20b44b6bd7874f7b ] In case the interrupt signal can't be configured, IRQ domain needs to be removed. Fixes: 06252ade9156 ("mfd: Add ST Multi-Function eXpander (STMFX) core driver") Signed-off-by: Amelie Delaunay Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit ac51ebdea42cdbec29af8995fe186c9bcb0bbb61 Author: Amelie Delaunay Date: Wed Apr 22 11:08:31 2020 +0200 mfd: stmfx: Reset chip on resume as supply was disabled [ Upstream commit e583649d87ec090444aa5347af0927cd6e8581ae ] STMFX supply is disabled during suspend. To avoid a too early access to the STMFX firmware on resume, reset the chip and wait for its firmware to be loaded. Fixes: 06252ade9156 ("mfd: Add ST Multi-Function eXpander (STMFX) core driver") Signed-off-by: Amelie Delaunay Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 646f6be320195549dafe78fb11270eb19a0d1d84 Author: Borislav Petkov Date: Mon May 25 12:38:39 2020 +0200 x86/apic: Make TSC deadline timer detection message visible [ Upstream commit de308d1815c9e8fe602a958c5c76142ff6501d75 ] The commit c84cb3735fd5 ("x86/apic: Move TSC deadline timer debug printk") removed the message which said that the deadline timer was enabled. It added a pr_debug() message which is issued when deadline timer validation succeeds. Well, issued only when CONFIG_DYNAMIC_DEBUG is enabled - otherwise pr_debug() calls get optimized away if DEBUG is not defined in the compilation unit. Therefore, make the above message pr_info() so that it is visible in dmesg. Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200525104218.27018-1-bp@alien8.de Signed-off-by: Sasha Levin commit 9c0cec79e5c914662c2cf98b4a729c0fcc8c872e Author: Potnuri Bharat Teja Date: Mon May 25 00:38:14 2020 +0530 RDMA/iw_cxgb4: cleanup device debugfs entries on ULD remove [ Upstream commit 49ea0c036ede81f126f1a9389d377999fdf5c5a1 ] Remove device specific debugfs entries immediately if LLD detaches a particular ULD device in case of fatal PCI errors. Link: https://lore.kernel.org/r/20200524190814.17599-1-bharat@chelsio.com Signed-off-by: Potnuri Bharat Teja Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 672ae3d2185030db181b2557fe8d21d5e470ad9f Author: Siddharth Gupta Date: Tue May 5 18:52:37 2020 -0700 scripts: headers_install: Exit with error on config leak [ Upstream commit 5967577231f9b19acd5a59485e9075964065bbe3 ] Misuse of CONFIG_* in UAPI headers should result in an error. These config options can be set in userspace by the user application which includes these headers to control the APIs and structures being used in a kernel which supports multiple targets. Signed-off-by: Siddharth Gupta Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit e3c5b8a18980e40e63fc543522bc713d59237e3d Author: Tiezhu Yang Date: Sat May 23 19:45:25 2020 +0800 pinctrl: Fix return value about devm_platform_ioremap_resource() [ Upstream commit b5d9ff10dca49f4d4b7846c3751c6bec50d07375 ] When call function devm_platform_ioremap_resource(), we should use IS_ERR() to check the return value and return PTR_ERR() if failed. Fixes: 4b024225c4a8 ("pinctrl: use devm_platform_ioremap_resource() to simplify code") Signed-off-by: Tiezhu Yang Link: https://lore.kernel.org/r/1590234326-2194-1-git-send-email-yangtiezhu@loongson.cn Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 332276077e0eb6b7c1159da88bdadbe7538fdf3c Author: Pawel Laszczak Date: Mon May 18 12:08:45 2020 +0200 usb: gadget: Fix issue with config_ep_by_speed function [ Upstream commit 5d363120aa548ba52d58907a295eee25f8207ed2 ] This patch adds new config_ep_by_speed_and_alt function which extends the config_ep_by_speed about alt parameter. This additional parameter allows to find proper usb_ss_ep_comp_descriptor. Problem has appeared during testing f_tcm (BOT/UAS) driver function. f_tcm function for SS use array of headers for both BOT/UAS alternate setting: static struct usb_descriptor_header *uasp_ss_function_desc[] = { (struct usb_descriptor_header *) &bot_intf_desc, (struct usb_descriptor_header *) &uasp_ss_bi_desc, (struct usb_descriptor_header *) &bot_bi_ep_comp_desc, (struct usb_descriptor_header *) &uasp_ss_bo_desc, (struct usb_descriptor_header *) &bot_bo_ep_comp_desc, (struct usb_descriptor_header *) &uasp_intf_desc, (struct usb_descriptor_header *) &uasp_ss_bi_desc, (struct usb_descriptor_header *) &uasp_bi_ep_comp_desc, (struct usb_descriptor_header *) &uasp_bi_pipe_desc, (struct usb_descriptor_header *) &uasp_ss_bo_desc, (struct usb_descriptor_header *) &uasp_bo_ep_comp_desc, (struct usb_descriptor_header *) &uasp_bo_pipe_desc, (struct usb_descriptor_header *) &uasp_ss_status_desc, (struct usb_descriptor_header *) &uasp_status_in_ep_comp_desc, (struct usb_descriptor_header *) &uasp_status_pipe_desc, (struct usb_descriptor_header *) &uasp_ss_cmd_desc, (struct usb_descriptor_header *) &uasp_cmd_comp_desc, (struct usb_descriptor_header *) &uasp_cmd_pipe_desc, NULL, }; The first 5 descriptors are associated with BOT alternate setting, and others are associated with UAS. During handling UAS alternate setting f_tcm driver invokes config_ep_by_speed and this function sets incorrect companion endpoint descriptor in usb_ep object. Instead setting ep->comp_desc to uasp_bi_ep_comp_desc function in this case set ep->comp_desc to uasp_ss_bi_desc. This is due to the fact that it searches endpoint based on endpoint address: for_each_ep_desc(speed_desc, d_spd) { chosen_desc = (struct usb_endpoint_descriptor *)*d_spd; if (chosen_desc->bEndpoitAddress == _ep->address) goto ep_found; } And in result it uses the descriptor from BOT alternate setting instead UAS. Finally, it causes that controller driver during enabling endpoints detect that just enabled endpoint for bot. Signed-off-by: Jayshri Pawar Signed-off-by: Pawel Laszczak Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 5712c7bfee30c7851af4355804c9f71c34994aca Author: Qiushi Wu Date: Fri May 22 23:06:25 2020 -0500 usb: gadget: fix potential double-free in m66592_probe. [ Upstream commit 44734a594196bf1d474212f38fe3a0d37a73278b ] m66592_free_request() is called under label "err_add_udc" and "clean_up", and m66592->ep0_req is not set to NULL after first free, leading to a double-free. Fix this issue by setting m66592->ep0_req to NULL after the first free. Fixes: 0f91349b89f3 ("usb: gadget: convert all users to the new udc infrastructure") Signed-off-by: Qiushi Wu Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 2ede53dd99188eac0ebc900a1923bfb82afcac6c Author: Colin Ian King Date: Thu May 21 16:13:00 2020 +0100 usb: gadget: lpc32xx_udc: don't dereference ep pointer before null check [ Upstream commit eafa80041645cd7604c4357b1a0cd4a3c81f2227 ] Currently pointer ep is being dereferenced before it is null checked leading to a null pointer dereference issue. Fix this by only assigning pointer udc once ep is known to be not null. Also remove a debug message that requires a valid udc which may not be possible at that point. Addresses-Coverity: ("Dereference before null check") Fixes: 24a28e428351 ("USB: gadget driver for LPC32xx") Signed-off-by: Colin Ian King Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit e9e7dd28d2a5a4d7e3c7a98df1332f82bfd2e8f7 Author: Nathan Chancellor Date: Thu Apr 23 09:29:24 2020 -0700 USB: gadget: udc: s3c2410_udc: Remove pointless NULL check in s3c2410_udc_nuke [ Upstream commit 7a0fbcf7c308920bc6116b3a5fb21c8cc5fec128 ] Clang warns: drivers/usb/gadget/udc/s3c2410_udc.c:255:11: warning: comparison of address of 'ep->queue' equal to a null pointer is always false [-Wtautological-pointer-compare] if (&ep->queue == NULL) ~~~~^~~~~ ~~~~ 1 warning generated. It is not wrong, queue is not a pointer so if ep is not NULL, the address of queue cannot be NULL. No other driver does a check like this and this check has been around since the driver was first introduced, presumably with no issues so it does not seem like this check should be something else. Just remove it. Commit afe956c577b2d ("kbuild: Enable -Wtautological-compare") exposed this but it is not the root cause of the warning. Fixes: 3fc154b6b8134 ("USB Gadget driver for Samsung s3c2410 ARM SoC") Link: https://github.com/ClangBuiltLinux/linux/issues/1004 Reviewed-by: Nick Desaulniers Reported-by: kbuild test robot Signed-off-by: Nathan Chancellor Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 48f9d772d66d55cbda28b23d103fbf4c583af7d1 Author: Fabrice Gasnier Date: Thu Apr 23 13:55:53 2020 +0200 usb: dwc2: gadget: move gadget resume after the core is in L0 state [ Upstream commit 8c935deacebb8fac8f41378701eb79d12f3c2e2d ] When the remote wakeup interrupt is triggered, lx_state is resumed from L2 to L0 state. But when the gadget resume is called, lx_state is still L2. This prevents the resume callback to queue any request. Any attempt to queue a request from resume callback will result in: - "submit request only in active state" debug message to be issued - dwc2_hsotg_ep_queue() returns -EAGAIN Call the gadget resume routine after the core is in L0 state. Fixes: f81f46e1f530 ("usb: dwc2: implement hibernation during bus suspend/resume") Acked-by: Minas Harutyunyan Signed-off-by: Fabrice Gasnier Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 05c3b2314a7141898b95b11ba8dc40038090f381 Author: Stefan Riedmueller Date: Fri Apr 3 15:07:28 2020 +0200 watchdog: da9062: No need to ping manually before setting timeout [ Upstream commit a0948ddba65f4f6d3cfb5e2b84685485d0452966 ] There is actually no need to ping the watchdog before disabling it during timeout change. Disabling the watchdog already takes care of resetting the counter. This fixes an issue during boot when the userspace watchdog handler takes over and the watchdog is already running. Opening the watchdog in this case leads to the first ping and directly after that without the required heartbeat delay a second ping issued by the set_timeout call. Due to the missing delay this resulted in a reset. Signed-off-by: Stefan Riedmueller Reviewed-by: Guenter Roeck Reviewed-by: Adam Thomson Link: https://lore.kernel.org/r/20200403130728.39260-3-s.riedmueller@phytec.de Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin commit a6482530f4f7dc3f7fe336982272e538d3231bfe Author: Andrei Vagin Date: Thu May 21 00:52:52 2020 -0700 selftests/timens: handle a case when alarm clocks are not supported [ Upstream commit 558ae0355a91c7d28fdf4c0011bee6ebb5118632 ] This can happen if a testing node doesn't have RTC (real time clock) hardware or it doesn't support alarms. Fixes: 61c57676035d ("selftests/timens: Add Time Namespace test for supported clocks") Acked-by: Vincenzo Frascino Reported-by: Vincenzo Frascino Signed-off-by: Andrei Vagin Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit cfc408a35fadf353f21ea665de701b8723606cf2 Author: Maor Gottlieb Date: Thu May 21 10:26:50 2020 +0300 IB/cma: Fix ports memory leak in cma_configfs [ Upstream commit 63a3345c2d42a9b29e1ce2d3a4043689b3995cea ] The allocated ports structure in never freed. The free function should be called by release_cma_ports_group, but the group is never released since we don't remove its default group. Remove default groups when device group is deleted. Fixes: 045959db65c6 ("IB/cma: Add configfs for rdma_cm") Link: https://lore.kernel.org/r/20200521072650.567908-1-leon@kernel.org Signed-off-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit f3e84bf3f86bb3b7bd50666bb8ef7a203a656ca3 Author: Jonathan Bakker Date: Sun May 10 08:58:18 2020 -0700 iio: light: gp2ap002: Take runtime PM reference on light read [ Upstream commit f6dbf83c17cb223ceabd7c42d441414f3e0e8a86 ] The light sensor needs the regulators to be enabled which means the runtime PM needs to be on. This only happened when the proximity part of the chip was enabled. As fallout from this change, only report changes to the prox state in the interrupt handler when it is explicitly enabled. Fixes: 97d642e23037 ("iio: light: Add a driver for Sharp GP2AP002x00F") Signed-off-by: Jonathan Bakker Reviewed-by: Linus Walleij Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 943a72f2becd5224358d1610cf52337c7de67a97 Author: Marc Zyngier Date: Wed Apr 29 17:42:30 2020 +0100 PCI: amlogic: meson: Don't use FAST_LINK_MODE to set up link [ Upstream commit 87dccf09323fc363bd0d072fcc12b96622ab8c69 ] The vim3l board does not work with a standard PCIe switch (ASM1184e), spitting all kind of errors - hinting at HW misconfiguration (no link, port enumeration issues, etc). According to the the Synopsys DWC PCIe Reference Manual, in the section dedicated to the PLCR register, bit 7 is described (FAST_LINK_MODE) as: "Sets all internal timers to fast mode for simulation purposes." it is sound to set this bit from a simulation perspective, but on actual silicon, which expects timers to have a nominal value, it is not. Make sure the FAST_LINK_MODE bit is cleared when configuring the RC to solve this problem. Link: https://lore.kernel.org/r/20200429164230.309922-1-maz@kernel.org Fixes: 9c0ef6d34fdb ("PCI: amlogic: Add the Amlogic Meson PCIe controller driver") Signed-off-by: Marc Zyngier [lorenzo.pieralisi@arm.com: commit log] Signed-off-by: Lorenzo Pieralisi Reviewed-by: Neil Armstrong Acked-by: Rob Herring Signed-off-by: Sasha Levin commit 59b3c55624a917ca8ecf6d36f87db030611bdd59 Author: Marc Zyngier Date: Fri May 1 12:39:21 2020 +0100 PCI: dwc: Fix inner MSI IRQ domain registration [ Upstream commit 0414b93e78d87ecc24ae1a7e61fe97deb29fa2f4 ] On a system that uses the internal DWC MSI widget, I get this warning from debugfs when CONFIG_GENERIC_IRQ_DEBUGFS is selected: debugfs: File ':soc:pcie@fc000000' in directory 'domains' already present! This is due to the fact that the DWC MSI code tries to register two IRQ domains for the same firmware node, without telling the low level code how to distinguish them (by setting a bus token). This further confuses debugfs which tries to create corresponding files for each domain. Fix it by tagging the inner domain as DOMAIN_BUS_NEXUS, which is the closest thing we have as to "generic MSI". Link: https://lore.kernel.org/r/20200501113921.366597-1-maz@kernel.org Signed-off-by: Marc Zyngier Signed-off-by: Lorenzo Pieralisi Acked-by: Jingoo Han Signed-off-by: Sasha Levin commit e2006bb79235bbb6792bddeb06e3b57a02d49714 Author: Wei Yongjun Date: Wed Apr 29 01:50:27 2020 +0000 PCI: dwc: pci-dra7xx: Use devm_platform_ioremap_resource_byname() [ Upstream commit c8a119779f5609de8dcd98630f71cc7f1b2e4e8c ] platform_get_resource() may fail and return NULL, so we had better check its return value to avoid a NULL pointer dereference a bit later in the code. Fix it to use devm_platform_ioremap_resource_byname() instead of calling platform_get_resource_byname() and devm_ioremap(). Link: https://lore.kernel.org/r/20200429015027.134485-1-weiyongjun1@huawei.com Signed-off-by: Wei Yongjun [lorenzo.pieralisi@arm.com: commit log] Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit 12b1de9ca00be16624fd14d2dfd03b6c33b78799 Author: Hemant Kumar Date: Thu May 21 22:32:39 2020 +0530 bus: mhi: core: Read transfer length from an event properly [ Upstream commit ee75cedf82d832561af8ba8380aeffd00a9eea77 ] When MHI Driver receives an EOT event, it reads xfer_len from the event in the last TRE. The value is under control of the MHI device and never validated by Host MHI driver. The value should never be larger than the real size of the buffer but a malicious device can set the value 0xFFFF as maximum. This causes driver to memory overflow (both read or write). Fix this issue by reading minimum of transfer length from event and the buffer length provided. Signed-off-by: Hemant Kumar Signed-off-by: Bhaumik Bhatt Reviewed-by: Jeffrey Hugo Reviewed-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Link: https://lore.kernel.org/r/20200521170249.21795-5-manivannan.sadhasivam@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 453b4e15a057ece15b216d4be23c660c1ca39fcb Author: Bjorn Helgaas Date: Thu May 21 15:40:07 2020 -0500 PCI/PTM: Inherit Switch Downstream Port PTM settings from Upstream Port [ Upstream commit 7b38fd9760f51cc83d80eed2cfbde8b5ead9e93a ] Except for Endpoints, we enable PTM at enumeration-time. Previously we did not account for the fact that Switch Downstream Ports are not permitted to have a PTM capability; their PTM behavior is controlled by the Upstream Port (PCIe r5.0, sec 7.9.16). Since Downstream Ports don't have a PTM capability, we did not mark them as "ptm_enabled", which meant that pci_enable_ptm() on an Endpoint failed because there was no PTM path to it. Mark Downstream Ports as "ptm_enabled" if their Upstream Port has PTM enabled. Fixes: eec097d43100 ("PCI: Add pci_enable_ptm() for drivers to enable PTM on endpoints") Reported-by: Aditya Paluri Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit 96566670aab7a3590b5e7ab64fd04518aca31b4c Author: Boris Ostrovsky Date: Fri May 8 18:28:43 2020 -0400 xen/cpuhotplug: Fix initial CPU offlining for PV(H) guests [ Upstream commit c54b071c192dfe8061336f650ceaf358e6386e0b ] Commit a926f81d2f6c ("xen/cpuhotplug: Replace cpu_up/down() with device_online/offline()") replaced cpu_down() with device_offline() call which requires that the CPU has been registered before. This registration, however, happens later from topology_init() which is called as subsys_initcall(). setup_vcpu_hotplug_event(), on the other hand, is invoked earlier, during arch_initcall(). As result, booting a PV(H) guest with vcpus < maxvcpus causes a crash. Move setup_vcpu_hotplug_event() (and therefore setup_cpu_watcher()) to late_initcall(). In addition, instead of performing all offlining steps in setup_cpu_watcher() simply call disable_hotplug_cpu(). Fixes: a926f81d2f6c (xen/cpuhotplug: Replace cpu_up/down() with device_online/offline()" Signed-off-by: Boris Ostrovsky Link: https://lore.kernel.org/r/1588976923-3667-1-git-send-email-boris.ostrovsky@oracle.com Reviewed-by: Juergen Gross Signed-off-by: Boris Ostrovsky Signed-off-by: Sasha Levin commit 51086af6e31e97c533266ef00e2f0cf6cbb835c3 Author: Gal Pressman Date: Tue May 12 18:22:03 2020 +0300 RDMA/efa: Fix setting of wrong bit in get/set_feature commands [ Upstream commit cc8a635e24acf2793605f243c913c51b8c3702ab ] When using a control buffer the ctrl_data bit should be set in order to indicate the control buffer address is valid, not ctrl_data_indirect which is used when the control buffer itself is indirect. Fixes: e9c6c5373088 ("RDMA/efa: Add common command handlers") Link: https://lore.kernel.org/r/20200512152204.93091-2-galpress@amazon.com Reviewed-by: Firas JahJah Reviewed-by: Yossi Leybovich Signed-off-by: Gal Pressman Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 6c364afe71197d42584f17893a44c331f8d159b0 Author: Hannes Reinecke Date: Tue May 19 10:14:19 2020 +0200 dm zoned: return NULL if dmz_get_zone_for_reclaim() fails to find a zone [ Upstream commit 489dc0f06a5837f87482c0ce61d830d24e17082e ] The only case where dmz_get_zone_for_reclaim() cannot return a zone is if the respective lists are empty. So we should just return a simple NULL value here as we really don't have an error code which would make sense. Signed-off-by: Hannes Reinecke Reviewed-by: Damien Le Moal Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 537bd8c492ca05bb9c8f5a95b3296bf8f94f8469 Author: Christophe Leroy Date: Tue May 19 05:48:43 2020 +0000 powerpc/kasan: Fix error detection on memory allocation [ Upstream commit d132443a73d7a131775df46f33000f67ed92de1e ] In case (k_start & PAGE_MASK) doesn't equal (kstart), 'va' will never be NULL allthough 'block' is NULL Check the return of memblock_alloc() directly instead of the resulting address in the loop. Fixes: 509cd3f2b473 ("powerpc/32: Simplify KASAN init") Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/7cb8ca82042bfc45a5cfe726c921cd7e7eeb12a3.1589866984.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 701892a9549c282eef59d0338644bf30bd4f9243 Author: Qian Cai Date: Thu Mar 5 23:48:52 2020 -0500 powerpc/64s/pgtable: fix an undefined behaviour [ Upstream commit c2e929b18cea6cbf71364f22d742d9aad7f4677a ] Booting a power9 server with hash MMU could trigger an undefined behaviour because pud_offset(p4d, 0) will do, 0 >> (PAGE_SHIFT:16 + PTE_INDEX_SIZE:8 + H_PMD_INDEX_SIZE:10) Fix it by converting pud_index() and friends to static inline functions. UBSAN: shift-out-of-bounds in arch/powerpc/mm/ptdump/ptdump.c:282:15 shift exponent 34 is too large for 32-bit type 'int' CPU: 6 PID: 1 Comm: swapper/0 Not tainted 5.6.0-rc4-next-20200303+ #13 Call Trace: dump_stack+0xf4/0x164 (unreliable) ubsan_epilogue+0x18/0x78 __ubsan_handle_shift_out_of_bounds+0x160/0x21c walk_pagetables+0x2cc/0x700 walk_pud at arch/powerpc/mm/ptdump/ptdump.c:282 (inlined by) walk_pagetables at arch/powerpc/mm/ptdump/ptdump.c:311 ptdump_check_wx+0x8c/0xf0 mark_rodata_ro+0x48/0x80 kernel_init+0x74/0x194 ret_from_kernel_thread+0x5c/0x74 Suggested-by: Christophe Leroy Signed-off-by: Qian Cai Signed-off-by: Michael Ellerman Reviewed-by: Christophe Leroy Link: https://lore.kernel.org/r/20200306044852.3236-1-cai@lca.pw Signed-off-by: Sasha Levin commit 38b682916f26be3a8a569cfaa8d9684198ab2969 Author: Chen Zhou Date: Sat May 9 10:08:38 2020 +0800 powerpc/powernv: add NULL check after kzalloc [ Upstream commit ceffa63acce7165c442395b7d64a11ab8b5c5dca ] Fixes coccicheck warning: ./arch/powerpc/platforms/powernv/opal.c:813:1-5: alloc with no test, possible model on line 814 Add NULL check after kzalloc. Signed-off-by: Chen Zhou Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200509020838.121660-1-chenzhou10@huawei.com Signed-off-by: Sasha Levin commit 24f523946a1252ecef8cd404535912236ae5ef72 Author: Vidya Sagar Date: Thu May 14 19:24:37 2020 +0530 arm64: tegra: Fix flag for 64-bit resources in 'ranges' property [ Upstream commit 3482a7afb261e2de9269a7f9ad0f4a3a82a83a53 ] Fix flag in PCIe controllers device-tree nodes 'ranges' property to correctly represent 64-bit resources. Fixes: 2602c32f15e7 ("arm64: tegra: Add P2U and PCIe controller nodes to Tegra194 DT") Signed-off-by: Vidya Sagar Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit eaf887231e9d6cb6c7723fa54dd2d5e570f3c8be Author: Jon Hunter Date: Fri May 1 08:27:56 2020 +0100 arm64: tegra: Fix ethernet phy-mode for Jetson Xavier [ Upstream commit bba25915b172c72f6fa635f091624d799e3c9cae ] The 'phy-mode' property is currently defined as 'rgmii' for Jetson Xavier. This indicates that the RGMII RX and TX delays are set by the MAC and the internal delays set by the PHY are not used. If the Marvell PHY driver is enabled, such that it is used and not the generic PHY, ethernet failures are seen (DHCP is failing to obtain an IP address) and this is caused because the Marvell PHY driver is disabling the internal RX and TX delays. For Jetson Xavier the internal PHY RX and TX delay should be used and so fix this by setting the 'phy-mode' to 'rgmii-id' and not 'rgmii'. Fixes: f89b58ce71a9 ("arm64: tegra: Add ethernet controller on Tegra194") Signed-off-by: Jon Hunter Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 6805031556e1e702c2eafa838d93651abe33824f Author: Miklos Szeredi Date: Wed May 20 11:39:35 2020 +0200 fuse: copy_file_range should truncate cache [ Upstream commit 9b46418c40fe910e6537618f9932a8be78a3dd6c ] After the copy operation completes the cache is not up-to-date. Truncate all pages in the interval that has successfully been copied. Truncating completely copied dirty pages is okay, since the data has been overwritten anyway. Truncating partially copied dirty pages is not okay; add a comment for now. Fixes: 88bc7d5097a1 ("fuse: add support for copy_file_range()") Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 44c7d90ef8178b7908d105070ab60b8bc30027f5 Author: Miklos Szeredi Date: Wed May 20 11:39:35 2020 +0200 fuse: fix copy_file_range cache issues [ Upstream commit 2c4656dfd994538176db30ce09c02cc0dfc361ae ] a) Dirty cache needs to be written back not just in the writeback_cache case, since the dirty pages may come from memory maps. b) The fuse_writeback_range() helper takes an inclusive interval, so the end position needs to be pos+len-1 instead of pos+len. Fixes: 88bc7d5097a1 ("fuse: add support for copy_file_range()") Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 6dc1d4511e0ff6db45fafa76c74012ad05c30c34 Author: Wei Yongjun Date: Wed May 6 05:14:10 2020 +0000 firmware: imx: scu: Fix possible memory leak in imx_scu_probe() [ Upstream commit 89f12d6509bff004852c51cb713a439a86816b24 ] 'chan_name' is malloced in imx_scu_probe() and should be freed before leaving from the error handling cases, otherwise it will cause memory leak. Fixes: edbee095fafb ("firmware: imx: add SCU firmware driver support") Signed-off-by: Wei Yongjun Reviewed-by: Dong Aisheng Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin commit 74c5fd5dedde91e58acc52eb5948788496a017a2 Author: Ye Bin Date: Mon May 18 15:44:20 2020 +0800 scsi: core: Fix incorrect usage of shost_for_each_device [ Upstream commit 4dea170f4fb225984b4f2f1cf0a41d485177b905 ] shost_for_each_device(sdev, shost) \ for ((sdev) = __scsi_iterate_devices((shost), NULL); \ (sdev); \ (sdev) = __scsi_iterate_devices((shost), (sdev))) When terminating shost_for_each_device() iteration with break or return, scsi_device_put() should be used to prevent stale scsi device references from being left behind. Link: https://lore.kernel.org/r/20200518074420.39275-1-yebin10@huawei.com Reviewed-by: Bart Van Assche Signed-off-by: Ye Bin Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 07a98d17eb1dd896de475c1a74121c3b3e301ea3 Author: Bodo Stroesser Date: Mon May 18 18:48:33 2020 +0200 scsi: target: tcmu: Userspace must not complete queued commands [ Upstream commit 61fb2482216679b9e1e797440c148bb143a5040a ] When tcmu queues a new command - no matter whether in command ring or in qfull_queue - a cmd_id from IDR udev->commands is assigned to the command. If userspace sends a wrong command completion containing the cmd_id of a command on the qfull_queue, tcmu_handle_completions() finds the command in the IDR and calls tcmu_handle_completion() for it. This might do some nasty things because commands in qfull_queue do not have a valid dbi list. To fix this bug, we no longer add queued commands to the idr. Instead the cmd_id is assign when a command is written to the command ring. Due to this change I had to adapt the source code at several places where up to now an idr_for_each had been done. [mkp: fix checkpatch warnings] Link: https://lore.kernel.org/r/20200518164833.12775-1-bstroesser@ts.fujitsu.com Acked-by: Mike Christie Signed-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 48c9005de047854c07f12630e991145a15cd522c Author: Lang Cheng Date: Fri May 8 17:45:52 2020 +0800 RDMA/hns: Fix cmdq parameter of querying pf timer resource [ Upstream commit 441c88d5b3ff80108ff536c6cf80591187015403 ] The firmware has reduced the number of descriptions of command HNS_ROCE_OPC_QUERY_PF_TIMER_RES to 1. The driver needs to adapt, otherwise the hardware will report error 4(CMD_NEXT_ERR). Fixes: 0e40dc2f70cd ("RDMA/hns: Add timer allocation support for hip08") Link: https://lore.kernel.org/r/1588931159-56875-3-git-send-email-liweihang@huawei.com Signed-off-by: Lang Cheng Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 745eff893dbc11be832b32b99c26e09b62697e04 Author: Lijun Ou Date: Fri May 8 17:45:51 2020 +0800 RDMA/hns: Bugfix for querying qkey [ Upstream commit 349be276509455ac2f19fa4051ed773082c6a27e ] The qkey queried through the query ud qp verb is a fixed value and it should be read from qp context. Fixes: 926a01dc000d ("RDMA/hns: Add QP operations support for hip08 SoC") Link: https://lore.kernel.org/r/1588931159-56875-2-git-send-email-liweihang@huawei.com Signed-off-by: Lijun Ou Signed-off-by: Weihang Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit a92b984a110863b42a3abf32e3f049b02b19e350 Author: Marek Szyprowski Date: Tue May 19 12:26:52 2020 +0200 clk: samsung: exynos5433: Add IGNORE_UNUSED flag to sclk_i2s1 [ Upstream commit 25bdae0f1c6609ceaf55fe6700654f0be2253d8e ] Mark the SCLK clock for Exynos5433 I2S1 device with IGNORE_UNUSED flag to match its behaviour with SCLK clock for AUD_I2S (I2S0) device until a proper fix for Exynos I2S driver is ready. This fixes the following synchronous abort issue revealed by the probe order change caused by the commit 93d2e4322aa7 ("of: platform: Batch fwnode parsing when adding all top level devices") Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 50 Comm: kworker/0:1 Not tainted 5.7.0-rc5+ #701 Hardware name: Samsung TM2E board (DT) Workqueue: events deferred_probe_work_func pstate: 60000005 (nZCv daif -PAN -UAO) pc : samsung_i2s_probe+0x768/0x8f0 lr : samsung_i2s_probe+0x688/0x8f0 ... Call trace: samsung_i2s_probe+0x768/0x8f0 platform_drv_probe+0x50/0xa8 really_probe+0x108/0x370 driver_probe_device+0x54/0xb8 __device_attach_driver+0x90/0xc0 bus_for_each_drv+0x70/0xc8 __device_attach+0xdc/0x140 device_initial_probe+0x10/0x18 bus_probe_device+0x94/0xa0 deferred_probe_work_func+0x70/0xa8 process_one_work+0x2a8/0x718 worker_thread+0x48/0x470 kthread+0x134/0x160 ret_from_fork+0x10/0x1c Code: 17ffffaf d503201f f94086c0 91003000 (88dffc00) ---[ end trace ccf721c9400ddbd6 ]--- Signed-off-by: Marek Szyprowski Signed-off-by: Sylwester Nawrocki Signed-off-by: Sasha Levin commit e79b4cf4ecd1fa6c002243420a0bc5459d768a6d Author: Souptick Joarder Date: Mon May 18 23:49:51 2020 +0530 fpga: dfl: afu: Corrected error handling levels [ Upstream commit c9d7e3da1f3c4cf5dddfc5d7ce4d76d013aba1cc ] Corrected error handling goto sequnece. Level put_pages should be called when pinned pages >= 0 && pinned != npages. Level free_pages should be called when pinned pages < 0. Fixes: fa8dda1edef9 ("fpga: dfl: afu: add DFL_FPGA_PORT_DMA_MAP/UNMAP ioctls support") Signed-off-by: Souptick Joarder Acked-by: Wu Hao Reviewed-by: Xu Yilun Link: https://lore.kernel.org/r/1589825991-3545-1-git-send-email-jrdr.linux@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a02dcdff7b5ba9c948efccd02795df7c8904ed9c Author: Suzuki K Poulose Date: Mon May 18 12:02:40 2020 -0600 coresight: etm4x: Fix use-after-free of per-cpu etm drvdata [ Upstream commit 3f4943d422c5febbb3c764670011a00eb2a86238 ] etm probe could be deferred due to the dependency in the trace path chain and may be retried. We need to clear the per-cpu etmdrvdata entry for the etm in case of a failure to avoid use-after-free cases as reported below: KASAN use-after-free bug in etm4_cpu_pm_notify(): [ 8.574566] coresight etm0: CPU0: ETM v4.2 initialized [ 8.581920] BUG: KASAN: use-after-free in etm4_cpu_pm_notify+0x580/0x2024 [ 8.581925] Read of size 8 at addr ffffff813304f8c8 by task swapper/3/0 [ 8.581927] [ 8.581934] CPU: 3 PID: 0 Comm: swapper/3 Tainted: G S W 5.4.28 #314 [ 8.587775] coresight etm1: CPU1: ETM v4.2 initialized [ 8.594195] Call trace: [ 8.594205] dump_backtrace+0x0/0x188 [ 8.594209] show_stack+0x20/0x2c [ 8.594216] dump_stack+0xdc/0x144 [ 8.594227] print_address_description+0x3c/0x494 [ 8.594232] __kasan_report+0x144/0x168 [ 8.601598] coresight etm2: CPU2: ETM v4.2 initialized [ 8.602563] kasan_report+0x10/0x18 [ 8.602568] check_memory_region+0x1a4/0x1b4 [ 8.602572] __kasan_check_read+0x18/0x24 [ 8.602577] etm4_cpu_pm_notify+0x580/0x2024 [ 8.665945] notifier_call_chain+0x5c/0x90 [ 8.670166] __atomic_notifier_call_chain+0x90/0xf8 [ 8.675182] cpu_pm_notify+0x40/0x6c [ 8.678858] cpu_pm_enter+0x38/0x80 [ 8.682451] psci_enter_idle_state+0x34/0x70 [ 8.686844] cpuidle_enter_state+0xb8/0x20c [ 8.691143] cpuidle_enter+0x38/0x4c [ 8.694820] call_cpuidle+0x3c/0x68 [ 8.698408] do_idle+0x1a0/0x280 [ 8.701729] cpu_startup_entry+0x24/0x28 [ 8.705768] secondary_start_kernel+0x15c/0x170 [ 8.710423] [ 8.711972] Allocated by task 242: [ 8.715473] __kasan_kmalloc+0xf0/0x1ac [ 8.719426] kasan_slab_alloc+0x14/0x1c [ 8.723375] __kmalloc_track_caller+0x23c/0x388 [ 8.728040] devm_kmalloc+0x38/0x94 [ 8.731632] etm4_probe+0x48/0x3c8 [ 8.735140] amba_probe+0xbc/0x158 [ 8.738645] really_probe+0x144/0x408 [ 8.742412] driver_probe_device+0x70/0x140 [ 8.746716] __device_attach_driver+0x9c/0x110 [ 8.751287] bus_for_each_drv+0x90/0xd8 [ 8.755236] __device_attach+0xb4/0x164 [ 8.759188] device_initial_probe+0x20/0x2c [ 8.763490] bus_probe_device+0x34/0x94 [ 8.767436] device_add+0x34c/0x3e0 [ 8.771029] amba_device_try_add+0x68/0x440 [ 8.775332] amba_deferred_retry_func+0x48/0xc8 [ 8.779997] process_one_work+0x344/0x648 [ 8.784127] worker_thread+0x2ac/0x47c [ 8.787987] kthread+0x128/0x138 [ 8.791313] ret_from_fork+0x10/0x18 [ 8.794993] [ 8.796532] Freed by task 242: [ 8.799684] __kasan_slab_free+0x15c/0x22c [ 8.803897] kasan_slab_free+0x10/0x1c [ 8.807761] kfree+0x25c/0x4bc [ 8.810913] release_nodes+0x240/0x2b0 [ 8.814767] devres_release_all+0x3c/0x54 [ 8.818887] really_probe+0x178/0x408 [ 8.822661] driver_probe_device+0x70/0x140 [ 8.826963] __device_attach_driver+0x9c/0x110 [ 8.831539] bus_for_each_drv+0x90/0xd8 [ 8.835487] __device_attach+0xb4/0x164 [ 8.839431] device_initial_probe+0x20/0x2c [ 8.843732] bus_probe_device+0x34/0x94 [ 8.847678] device_add+0x34c/0x3e0 [ 8.851274] amba_device_try_add+0x68/0x440 [ 8.855576] amba_deferred_retry_func+0x48/0xc8 [ 8.860240] process_one_work+0x344/0x648 [ 8.864366] worker_thread+0x2ac/0x47c [ 8.868228] kthread+0x128/0x138 [ 8.871557] ret_from_fork+0x10/0x18 [ 8.875231] [ 8.876782] The buggy address belongs to the object at ffffff813304f800 [ 8.876782] which belongs to the cache kmalloc-1k of size 1024 [ 8.889632] The buggy address is located 200 bytes inside of [ 8.889632] 1024-byte region [ffffff813304f800, ffffff813304fc00) [ 8.901761] The buggy address belongs to the page: [ 8.906695] page:ffffffff04ac1200 refcount:1 mapcount:0 mapping:ffffff8146c03800 index:0x0 compound_mapcount: 0 [ 8.917047] flags: 0x4000000000010200(slab|head) [ 8.921799] raw: 4000000000010200 dead000000000100 dead000000000122 ffffff8146c03800 [ 8.929753] raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000 [ 8.937703] page dumped because: kasan: bad access detected [ 8.943433] [ 8.944974] Memory state around the buggy address: [ 8.949903] ffffff813304f780: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 8.957320] ffffff813304f800: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 8.964742] >ffffff813304f880: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 8.972157] ^ [ 8.977886] ffffff813304f900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 8.985298] ffffff813304f980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb [ 8.992713] ================================================================== Fixes: f188b5e76aae ("coresight: etm4x: Save/restore state across CPU low power states") Reported-by: Sai Prakash Ranjan Tested-by: Sai Prakash Ranjan Cc: Mathieu Poirier Cc: Mike Leach Signed-off-by: Suzuki K Poulose Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200518180242.7916-22-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 781d2308bafc3b5107d2f0c02aeb1f0a94026cfe Author: Suzuki K Poulose Date: Mon May 18 12:02:31 2020 -0600 coresight: Fix support for sparsely populated ports [ Upstream commit d375b356e687f2eefb51ddc3f1f2414cfa498f86 ] On some systems the firmware may not describe all the ports connected to a component (e.g, for security reasons). This could be especially problematic for "funnels" where we could end up in modifying memory beyond the allocated space for refcounts. e.g, for a funnel with input ports listed 0, 3, 5, nr_inport = 3. However the we could access refcnts[5] while checking for references, like : [ 526.110401] ================================================================== [ 526.117988] BUG: KASAN: slab-out-of-bounds in funnel_enable+0x54/0x1b0 [ 526.124706] Read of size 4 at addr ffffff8135f9549c by task bash/1114 [ 526.131324] [ 526.132886] CPU: 3 PID: 1114 Comm: bash Tainted: G S 5.4.25 #232 [ 526.140397] Hardware name: Qualcomm Technologies, Inc. SC7180 IDP (DT) [ 526.147113] Call trace: [ 526.149653] dump_backtrace+0x0/0x188 [ 526.153431] show_stack+0x20/0x2c [ 526.156852] dump_stack+0xdc/0x144 [ 526.160370] print_address_description+0x3c/0x494 [ 526.165211] __kasan_report+0x144/0x168 [ 526.169170] kasan_report+0x10/0x18 [ 526.172769] check_memory_region+0x1a4/0x1b4 [ 526.177164] __kasan_check_read+0x18/0x24 [ 526.181292] funnel_enable+0x54/0x1b0 [ 526.185072] coresight_enable_path+0x104/0x198 [ 526.189649] coresight_enable+0x118/0x26c ... [ 526.237782] Allocated by task 280: [ 526.241298] __kasan_kmalloc+0xf0/0x1ac [ 526.245249] kasan_kmalloc+0xc/0x14 [ 526.248849] __kmalloc+0x28c/0x3b4 [ 526.252361] coresight_register+0x88/0x250 [ 526.256587] funnel_probe+0x15c/0x228 [ 526.260365] dynamic_funnel_probe+0x20/0x2c [ 526.264679] amba_probe+0xbc/0x158 [ 526.268193] really_probe+0x144/0x408 [ 526.271970] driver_probe_device+0x70/0x140 ... [ 526.316810] [ 526.318364] Freed by task 0: [ 526.321344] (stack is not available) [ 526.325024] [ 526.326580] The buggy address belongs to the object at ffffff8135f95480 [ 526.326580] which belongs to the cache kmalloc-128 of size 128 [ 526.339439] The buggy address is located 28 bytes inside of [ 526.339439] 128-byte region [ffffff8135f95480, ffffff8135f95500) [ 526.351399] The buggy address belongs to the page: [ 526.356342] page:ffffffff04b7e500 refcount:1 mapcount:0 mapping:ffffff814b00c380 index:0x0 compound_mapcount: 0 [ 526.366711] flags: 0x4000000000010200(slab|head) [ 526.371475] raw: 4000000000010200 ffffffff05034008 ffffffff0501eb08 ffffff814b00c380 [ 526.379435] raw: 0000000000000000 0000000000190019 00000001ffffffff 0000000000000000 [ 526.387393] page dumped because: kasan: bad access detected [ 526.393128] [ 526.394681] Memory state around the buggy address: [ 526.399619] ffffff8135f95380: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.407046] ffffff8135f95400: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.414473] >ffffff8135f95480: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.421900] ^ [ 526.426029] ffffff8135f95500: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.433456] ffffff8135f95580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 526.440883] ================================================================== To keep the code simple, we now track the maximum number of possible input/output connections to/from this component @ nr_inport and nr_outport in platform_data, respectively. Thus the output connections could be sparse and code is adjusted to skip the unspecified connections. Cc: Mathieu Poirier Cc: Mike Leach Reported-by: Sai Prakash Ranjan Tested-by: Sai Prakash Ranjan Tested-by: Stephen Boyd Signed-off-by: Suzuki K Poulose Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200518180242.7916-13-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit aa5149b4ffde5e80abd438795b244ee4fc484c97 Author: Gregory CLEMENT Date: Mon May 18 10:45:13 2020 +0200 tty: n_gsm: Fix bogus i++ in gsm_data_kick [ Upstream commit 4dd31f1ffec6c370c3c2e0c605628bf5e16d5c46 ] When submitting the previous fix "tty: n_gsm: Fix waking up upper tty layer when room available". It was suggested to switch from a while to a for loop, but when doing it, there was a remaining bogus i++. This patch removes this i++ and also reorganizes the code making it more compact. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Gregory CLEMENT Link: https://lore.kernel.org/r/20200518084517.2173242-3-gregory.clement@bootlin.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 2f20a46ac3eb1387ddf3226a3e1e972e2837b586 Author: Tang Bin Date: Wed May 13 21:26:47 2020 +0800 USB: host: ehci-mxc: Add error handling in ehci_mxc_drv_probe() [ Upstream commit d49292025f79693d3348f8e2029a8b4703be0f0a ] The function ehci_mxc_drv_probe() does not perform sufficient error checking after executing platform_get_irq(), thus fix it. Fixes: 7e8d5cd93fac ("USB: Add EHCI support for MX27 and MX31 based boards") Signed-off-by: Zhang Shengju Signed-off-by: Tang Bin Reviewed-by: Peter Chen Link: https://lore.kernel.org/r/20200513132647.5456-1-tangbin@cmss.chinamobile.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c9753f824f7092fcdaeb846bfe7fd67e0f489406 Author: Hans de Goede Date: Mon May 18 09:24:16 2020 +0200 ASoC: Intel: bytcr_rt5640: Add quirk for Toshiba Encore WT8-A tablet [ Upstream commit 0e0e10fde0e9808d1991268f5dca69fb36c025f7 ] The Toshiba Encore WT8-A tablet almost fully works with the default settings for non-CR Bay Trail devices. The only problem is that its jack-detect switch is not inverted (it is active high instead of the normal active low). Add a quirk for this model using the default settings + BYT_RT5640_JD_NOT_INV. Signed-off-by: Hans de Goede Acked-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200518072416.5348-1-hdegoede@redhat.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c969f20d26874cbfd8d19ee5de77b8012ca739c1 Author: Roy Spliet Date: Tue Apr 7 18:07:37 2020 +0100 drm/msm/mdp5: Fix mdp5_init error path for failed mdp5_kms allocation [ Upstream commit e4337877c5d578722c0716f131fb774522013cf5 ] When allocation for mdp5_kms fails, calling mdp5_destroy() leads to undefined behaviour, likely a nullptr exception or use-after-free troubles. Signed-off-by: Roy Spliet Reviewed-by: Abhinav Kumar Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit 571bb8742c8272cd78f65a06d98c6f063ce9962f Author: Bjorn Andersson Date: Thu Apr 30 12:24:27 2020 -0700 drm/msm: Fix undefined "rd_full" link error [ Upstream commit 20aebe83698feb107d5a66b6cfd1d54459ccdfcf ] rd_full should be defined outside the CONFIG_DEBUG_FS region, in order to be able to link the msm driver even when CONFIG_DEBUG_FS is disabled. Fixes: e515af8d4a6f ("drm/msm: devcoredump should dump MSM_SUBMIT_BO_DUMP buffers") Reported-by: Stephen Rothwell Signed-off-by: Bjorn Andersson Reviewed-by: Rob Clark Signed-off-by: Rob Clark Signed-off-by: Sasha Levin commit fc67821bd2c23f656acc8a0dfa649ed8f94e2264 Author: Qais Yousef Date: Mon May 18 16:49:29 2020 +0100 usb/ohci-platform: Fix a warning when hibernating [ Upstream commit 1cb3b0095c3d0bb96912bfbbce4fc006d41f367c ] The following warning was observed when attempting to suspend to disk using a USB flash as a swap device. [ 111.779649] ------------[ cut here ]------------ [ 111.788382] URB (____ptrval____) submitted while active [ 111.796646] WARNING: CPU: 3 PID: 365 at drivers/usb/core/urb.c:363 usb_submit_urb+0x3d8/0x590 [ 111.805417] Modules linked in: [ 111.808584] CPU: 3 PID: 365 Comm: kworker/3:2 Not tainted 5.6.0-rc6-00002-gdfd1731f9a3e-dirty #545 [ 111.817796] Hardware name: ARM Juno development board (r2) (DT) [ 111.823896] Workqueue: usb_hub_wq hub_event [ 111.828217] pstate: 60000005 (nZCv daif -PAN -UAO) [ 111.833156] pc : usb_submit_urb+0x3d8/0x590 [ 111.837471] lr : usb_submit_urb+0x3d8/0x590 [ 111.841783] sp : ffff800018de38b0 [ 111.845205] x29: ffff800018de38b0 x28: 0000000000000003 [ 111.850682] x27: ffff000970530b20 x26: ffff8000133fd000 [ 111.856159] x25: ffff8000133fd000 x24: ffff800018de3b38 [ 111.861635] x23: 0000000000000004 x22: 0000000000000c00 [ 111.867112] x21: 0000000000000000 x20: 00000000fffffff0 [ 111.872589] x19: ffff0009704e7a00 x18: ffffffffffffffff [ 111.878065] x17: 00000000a7c8f4bc x16: 000000002af33de8 [ 111.883542] x15: ffff8000133fda88 x14: 0720072007200720 [ 111.889019] x13: 0720072007200720 x12: 0720072007200720 [ 111.894496] x11: 0000000000000000 x10: 00000000a5286134 [ 111.899973] x9 : 0000000000000002 x8 : ffff000970c837a0 [ 111.905449] x7 : 0000000000000000 x6 : ffff800018de3570 [ 111.910926] x5 : 0000000000000001 x4 : 0000000000000003 [ 111.916401] x3 : 0000000000000000 x2 : ffff800013427118 [ 111.921879] x1 : 9d4e965b4b7d7c00 x0 : 0000000000000000 [ 111.927356] Call trace: [ 111.929892] usb_submit_urb+0x3d8/0x590 [ 111.933852] hub_activate+0x108/0x7f0 [ 111.937633] hub_resume+0xac/0x148 [ 111.941149] usb_resume_interface.isra.10+0x60/0x138 [ 111.946265] usb_resume_both+0xe4/0x140 [ 111.950225] usb_runtime_resume+0x24/0x30 [ 111.954365] __rpm_callback+0xdc/0x138 [ 111.958236] rpm_callback+0x34/0x98 [ 111.961841] rpm_resume+0x4a8/0x720 [ 111.965445] rpm_resume+0x50c/0x720 [ 111.969049] __pm_runtime_resume+0x4c/0xb8 [ 111.973276] usb_autopm_get_interface+0x28/0x60 [ 111.977948] hub_event+0x80/0x16d8 [ 111.981466] process_one_work+0x2a4/0x748 [ 111.985604] worker_thread+0x48/0x498 [ 111.989387] kthread+0x13c/0x140 [ 111.992725] ret_from_fork+0x10/0x18 [ 111.996415] irq event stamp: 354 [ 111.999756] hardirqs last enabled at (353): [] console_unlock+0x504/0x5b8 [ 112.008441] hardirqs last disabled at (354): [] do_debug_exception+0x1a8/0x258 [ 112.017479] softirqs last enabled at (350): [] __do_softirq+0x4bc/0x568 [ 112.025984] softirqs last disabled at (343): [] irq_exit+0x144/0x150 [ 112.034129] ---[ end trace dc96030b9cf6c8a3 ]--- The problem was tracked down to a missing call to pm_runtime_set_active() on resume in ohci-platform. Link: https://lore.kernel.org/lkml/20200323143857.db5zphxhq4hz3hmd@e107158-lin.cambridge.arm.com/ Acked-by: Alan Stern Signed-off-by: Qais Yousef CC: Tony Prisk CC: Greg Kroah-Hartman CC: Mathias Nyman CC: Oliver Neukum CC: linux-arm-kernel@lists.infradead.org CC: linux-usb@vger.kernel.org CC: linux-kernel@vger.kernel.org Link: https://lore.kernel.org/r/20200518154931.6144-1-qais.yousef@arm.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 6d29be564df67cd38dd045973f50ddbb673dd162 Author: Alex Williamson Date: Wed Apr 8 11:45:28 2020 -0600 vfio-pci: Mask cap zero [ Upstream commit bc138db1b96264b9c1779cf18d5a3b186aa90066 ] The PCI Code and ID Assignment Specification changed capability ID 0 from reserved to a NULL capability in the v1.1 revision. The NULL capability is defined to include only the 16-bit capability header, ie. only the ID and next pointer. Unfortunately vfio-pci creates a map of config space, where ID 0 is used to reserve the standard type 0 header. Finding an actual capability with this ID therefore results in a bogus range marked in that map and conflicts with subsequent capabilities. As this seems to be a dummy capability anyway and we already support dropping capabilities, let's hide this one rather than delving into the potentially subtle dependencies within our map. Seen on an NVIDIA Tesla T4. Reviewed-by: Cornelia Huck Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 4eef09f864507df9c412331159f2e6e0281c628f Author: Jean-Philippe Brucker Date: Wed May 13 13:02:57 2020 +0200 iommu/arm-smmu-v3: Don't reserve implementation defined register space [ Upstream commit 52f3fab0067d6fa9e99c1b7f63265dd48ca76046 ] Some SMMUv3 implementation embed the Perf Monitor Group Registers (PMCG) inside the first 64kB region of the SMMU. Since PMCG are managed by a separate driver, this layout causes resource reservation conflicts during boot. To avoid this conflict, don't reserve the MMIO regions that are implementation defined. Although devm_ioremap_resource() still works on full pages under the hood, this way we benefit from resource conflict checks. Fixes: 7d839b4b9e00 ("perf/smmuv3: Add arm64 smmuv3 pmu driver") Signed-off-by: Jean-Philippe Brucker Reviewed-by: Robin Murphy Link: https://lore.kernel.org/r/20200513110255.597203-1-jean-philippe@linaro.org Signed-off-by: Will Deacon Signed-off-by: Sasha Levin commit db51ebc09cc4ffb353c533e3b1979aab67128363 Author: Geoff Levand Date: Sat May 9 18:58:32 2020 +0000 powerpc/ps3: Fix kexec shutdown hang [ Upstream commit 126554465d93b10662742128918a5fc338cda4aa ] The ps3_mm_region_destroy() and ps3_mm_vas_destroy() routines are called very late in the shutdown via kexec's mmu_cleanup_all routine. By the time mmu_cleanup_all runs it is too late to use udbg_printf, and calling it will cause PS3 systems to hang. Remove all debugging statements from ps3_mm_region_destroy() and ps3_mm_vas_destroy() and replace any error reporting with calls to lv1_panic. With this change builds with 'DEBUG' defined will not cause kexec reboots to hang, and builds with 'DEBUG' defined or not will end in lv1_panic if an error is encountered. Signed-off-by: Geoff Levand Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/7325c4af2b4c989c19d6a26b90b1fec9c0615ddf.1589049250.git.geoff@infradead.org Signed-off-by: Sasha Levin commit 8f484bf25475d4ce18e87d256511e7ff11dc2c2e Author: Sanket Parmar Date: Mon May 18 14:14:13 2020 +0200 phy: cadence: sierra: Fix for USB3 U1/U2 state [ Upstream commit 2bcf14ca1a2f3202954f812f380c7fa8127fbd7f ] Updated values of USB3 related Sierra PHY registers. This change fixes USB3 device disconnect issue observed while enternig U1/U2 state. Signed-off-by: Sanket Parmar Link: https://lore.kernel.org/r/1589804053-14302-1-git-send-email-sparmar@cadence.com Reviewed-by: Roger Quadros Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit d690fd83f009eca7e2ee9e98876c834933bb0b65 Author: Bharat Gooty Date: Wed May 13 23:09:47 2020 +0530 drivers: phy: sr-usb: do not use internal fsm for USB2 phy init [ Upstream commit 6f0577d1411337a0d97d545abe4a784e9e611516 ] During different reboot cycles, USB PHY PLL may not always lock during initialization and therefore can cause USB to be not usable. Hence do not use internal FSM programming sequence for the USB PHY initialization. Fixes: 4dcddbb38b64 ("phy: sr-usb: Add Stingray USB PHY driver") Signed-off-by: Bharat Gooty Signed-off-by: Rayagonda Kokatanur Link: https://lore.kernel.org/r/20200513173947.10919-1-rayagonda.kokatanur@broadcom.com Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit 18ecb9e7f75d3f7c4cc1386e6dbe0c00d3670485 Author: Pali Rohár Date: Thu Apr 30 10:06:18 2020 +0200 PCI: aardvark: Issue PERST via GPIO [ Upstream commit 5169a9851daaa2782a7bd2bb83d5b1bd224b2879 ] Add support for issuing PERST via GPIO specified in 'reset-gpios' property (as described in PCI device tree bindings). Some buggy cards (e.g. Compex WLE900VX or WLE1216) are not detected after reboot when PERST is not issued during driver initialization. If bootloader already enabled link training then issuing PERST has no effect for some buggy cards (e.g. Compex WLE900VX) and these cards are not detected. We therefore clear the LINK_TRAINING_EN register before. It was observed that Compex WLE900VX card needs to be in PERST reset for at least 10ms if bootloader enabled link training. Tested on Turris MOX. Link: https://lore.kernel.org/r/20200430080625.26070-6-pali@kernel.org Tested-by: Tomasz Maciej Nowak Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Acked-by: Thomas Petazzoni Signed-off-by: Sasha Levin commit 313ce530eb0462e0ffe6032aa8a087eca875b369 Author: Marek Behún Date: Thu Apr 30 10:06:17 2020 +0200 PCI: aardvark: Improve link training [ Upstream commit 43fc679ced18006b12d918d7a8a4af392b7fbfe7 ] Currently the aardvark driver trains link in PCIe gen2 mode. This may cause some buggy gen1 cards (such as Compex WLE900VX) to be unstable or even not detected. Moreover when ASPM code tries to retrain link second time, these cards may stop responding and link goes down. If gen1 is used this does not happen. Unconditionally forcing gen1 is not a good solution since it may have performance impact on gen2 cards. To overcome this, read 'max-link-speed' property (as defined in PCI device tree bindings) and use this as max gen mode. Then iteratively try link training at this mode or lower until successful. After successful link training choose final controller gen based on Negotiated Link Speed from Link Status register, which should match card speed. Link: https://lore.kernel.org/r/20200430080625.26070-5-pali@kernel.org Tested-by: Tomasz Maciej Nowak Signed-off-by: Pali Rohár Signed-off-by: Marek Behún Signed-off-by: Lorenzo Pieralisi Reviewed-by: Rob Herring Acked-by: Thomas Petazzoni Signed-off-by: Sasha Levin commit 9ea0db12bd518a87b0a66962a4863abee0833631 Author: Pali Rohár Date: Thu Apr 30 10:06:14 2020 +0200 PCI: aardvark: Train link immediately after enabling training [ Upstream commit 6964494582f56a3882c2c53b0edbfe99eb32b2e1 ] Adding even 100ms (PCI_PM_D3COLD_WAIT) delay between enabling link training and starting link training causes detection issues with some buggy cards (such as Compex WLE900VX). Move the code which enables link training immediately before the one which starts link traning. This fixes detection issues of Compex WLE900VX card on Turris MOX after cold boot. Link: https://lore.kernel.org/r/20200430080625.26070-2-pali@kernel.org Fixes: f4c7d053d7f7 ("PCI: aardvark: Wait for endpoint to be ready...") Tested-by: Tomasz Maciej Nowak Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Acked-by: Rob Herring Acked-by: Thomas Petazzoni Signed-off-by: Sasha Levin commit 76ad7c3d5abdca1b737eac522aaff7df38b1dcb7 Author: Nicholas Piggin Date: Fri May 8 14:33:58 2020 +1000 powerpc/pseries/ras: Fix FWNMI_VALID off by one [ Upstream commit deb70f7a35a22dffa55b2c3aac71bc6fb0f486ce ] This was discovered developing qemu fwnmi sreset support. This off-by-one bug means the last 16 bytes of the rtas area can not be used for a 16 byte save area. It's not a serious bug, and QEMU implementation has to retain a workaround for old kernels, but it's good to tighten it. Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Acked-by: Mahesh Salgaonkar Link: https://lore.kernel.org/r/20200508043408.886394-7-npiggin@gmail.com Signed-off-by: Sasha Levin commit 75d0e73cb949d34fd4656edeb6b97ca669de2db9 Author: Nicholas Piggin Date: Fri May 8 14:33:56 2020 +1000 powerpc/64s/exceptions: Machine check reconcile irq state [ Upstream commit f0fd9dd3c213c947dfb5bc2cad3ef5e30d3258ec ] pseries fwnmi machine check code pops the soft-irq checks in rtas_call (after the next patch to remove rtas_token from this call path). Rather than play whack a mole with these and forever having fragile code, it seems better to have the early machine check handler perform the same kind of reconcile as the other NMI interrupts. WARNING: CPU: 0 PID: 493 at arch/powerpc/kernel/irq.c:343 CPU: 0 PID: 493 Comm: a Tainted: G W NIP: c00000000001ed2c LR: c000000000042c40 CTR: 0000000000000000 REGS: c0000001fffd38b0 TRAP: 0700 Tainted: G W MSR: 8000000000021003 CR: 28000488 XER: 00000000 CFAR: c00000000001ec90 IRQMASK: 0 GPR00: c000000000043820 c0000001fffd3b40 c0000000012ba300 0000000000000000 GPR04: 0000000048000488 0000000000000000 0000000000000000 00000000deadbeef GPR08: 0000000000000080 0000000000000000 0000000000000000 0000000000001001 GPR12: 0000000000000000 c0000000014a0000 0000000000000000 0000000000000000 GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR20: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR24: 0000000000000000 0000000000000000 0000000000000000 0000000000000000 GPR28: 0000000000000000 0000000000000001 c000000001360810 0000000000000000 NIP [c00000000001ed2c] arch_local_irq_restore.part.0+0xac/0x100 LR [c000000000042c40] unlock_rtas+0x30/0x90 Call Trace: [c0000001fffd3b40] [c000000001360810] 0xc000000001360810 (unreliable) [c0000001fffd3b60] [c000000000043820] rtas_call+0x1c0/0x280 [c0000001fffd3bb0] [c0000000000dc328] fwnmi_release_errinfo+0x38/0x70 [c0000001fffd3c10] [c0000000000dcd8c] pseries_machine_check_realmode+0x1dc/0x540 [c0000001fffd3cd0] [c00000000003fe04] machine_check_early+0x54/0x70 [c0000001fffd3d00] [c000000000008384] machine_check_early_common+0x134/0x1f0 --- interrupt: 200 at 0x13f1307c8 LR = 0x7fff888b8528 Instruction dump: 60000000 7d2000a6 71298000 41820068 39200002 7d210164 4bffff9c 60000000 60000000 7d2000a6 71298000 4c820020 <0fe00000> 4e800020 60000000 60000000 Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200508043408.886394-5-npiggin@gmail.com Signed-off-by: Sasha Levin commit 8d3e40df7cef71615a51d083977ad010a0154413 Author: Nicholas Piggin Date: Fri May 8 14:33:53 2020 +1000 powerpc/64s/exception: Fix machine check no-loss idle wakeup [ Upstream commit 8a5054d8cbbe03c68dcb0957c291c942132e4101 ] The architecture allows for machine check exceptions to cause idle wakeups which resume at the 0x200 address which has to return via the idle wakeup code, but the early machine check handler is run first. The case of a no state-loss sleep is broken because the early handler uses non-volatile register r1 , which is needed for the wakeup protocol, but it is not restored. Fix this by loading r1 from the MCE exception frame before returning to the idle wakeup code. Also update the comment which has become stale since the idle rewrite in C. This crash was found and fix confirmed with a machine check injection test in qemu powernv model (which is not upstream in qemu yet). Fixes: 10d91611f426d ("powerpc/64s: Reimplement book3s idle code in C") Signed-off-by: Nicholas Piggin Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200508043408.886394-2-npiggin@gmail.com Signed-off-by: Sasha Levin commit cabecf2cb63c9cb7fe0fbaa09a4c026ce5dfa350 Author: Pierre-Louis Bossart Date: Fri May 15 16:15:30 2020 -0500 ASoC: codecs: rt*-sdw: fix memory leak in set_sdw_stream() [ Upstream commit 07b542fe831cbefce163ad1b3aa7292c8a6332b8 ] Now that the sdw_stream is allocated in machine driver, set_sdw_stream() is also called with a NULL argument during the dailink shutdown. In this case, the drivers should not allocate any memory, and just return. Detected with KASAN/kmemleak. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Reviewed-by: Rander Wang Cc: Oder Chiou Cc: Shuming Fan Cc: Jack Yu Link: https://lore.kernel.org/r/20200515211531.11416-3-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c2d6e2d1a3db7f27d7f769afd2d01cd3d5605b45 Author: Feng Tang Date: Fri Apr 17 12:48:28 2020 +0800 ipmi: use vzalloc instead of kmalloc for user creation [ Upstream commit 7c47a219b95d0e06b5ef5fcc7bad807895015eac ] We met mulitple times of failure of staring bmc-watchdog, due to the runtime memory allocation failure of order 4. bmc-watchdog: page allocation failure: order:4, mode:0x40cc0(GFP_KERNEL|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0-1 CPU: 1 PID: 2571 Comm: bmc-watchdog Not tainted 5.5.0-00045-g7d6bb61d6188c #1 Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.00.01.0015.110720180833 11/07/2018 Call Trace: dump_stack+0x66/0x8b warn_alloc+0xfe/0x160 __alloc_pages_slowpath+0xd3e/0xd80 __alloc_pages_nodemask+0x2f0/0x340 kmalloc_order+0x18/0x70 kmalloc_order_trace+0x1d/0xb0 ipmi_create_user+0x55/0x2c0 [ipmi_msghandler] ipmi_open+0x72/0x110 [ipmi_devintf] chrdev_open+0xcb/0x1e0 do_dentry_open+0x1ce/0x380 path_openat+0x305/0x14f0 do_filp_open+0x9b/0x110 do_sys_open+0x1bd/0x250 do_syscall_64+0x5b/0x1f0 entry_SYSCALL_64_after_hwframe+0x44/0xa9 Using vzalloc/vfree for creating ipmi_user heals the problem Thanks to Stephen Rothwell for finding the vmalloc.h inclusion issue. Signed-off-by: Feng Tang Signed-off-by: Corey Minyard Signed-off-by: Sasha Levin commit 10ca974a2b034d3e2544659ebe503c42e6a120cf Author: Lars Povlsen Date: Wed May 13 14:55:19 2020 +0200 pinctrl: ocelot: Always register GPIO driver [ Upstream commit 550713e33f4338c8596776828a936fd1e3bf35de ] This fixes the situation where the GPIO controller is not used as an interrupt controller as well. Previously, the driver would silently fail to register even the GPIO's. With this change, the driver will only register as an interrupt controller if a parent interrupt is provided. Reviewed-by: Alexandre Belloni Signed-off-by: Lars Povlsen Link: https://lore.kernel.org/r/20200513125532.24585-2-lars.povlsen@microchip.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 017ffbe45e443879713f00e4c470a6286a482e0f Author: Marek Behún Date: Thu Apr 30 10:06:23 2020 +0200 arm64: dts: marvell: armada-37xx: Set pcie_reset_pin to gpio function [ Upstream commit 715878016984b2617f6c1f177c50039e12e7bd5b ] We found out that we are unable to control the PERST# signal via the default pin dedicated to be PERST# pin (GPIO2[3] pin) on A3700 SOC when this pin is in EP_PCIE1_Resetn mode. There is a register in the PCIe register space called PERSTN_GPIO_EN (D0088004[3]), but changing the value of this register does not change the pin output when measuring with voltmeter. We do not know if this is a bug in the SOC, or if it works only when PCIe controller is in a certain state. Commit f4c7d053d7f7 ("PCI: aardvark: Wait for endpoint to be ready before training link") says that when this pin changes pinctrl mode from EP_PCIE1_Resetn to GPIO, the PERST# signal is asserted for a brief moment. So currently the situation is that on A3700 boards the PERST# signal is asserted in U-Boot (because the code in U-Boot issues reset via this pin via GPIO mode), and then in Linux by the obscure and undocumented mechanism described by the above mentioned commit. We want to issue PERST# signal in a known way, therefore this patch changes the pcie_reset_pin function from "pcie" to "gpio" and adds the reset-gpios property to the PCIe node in device tree files of EspressoBin and Armada 3720 Dev Board (Turris Mox device tree already has this property and uDPU does not have a PCIe port). Signed-off-by: Marek Behún Cc: Remi Pommarel Tested-by: Tomasz Maciej Nowak Acked-by: Thomas Petazzoni Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 044aaaa8b1b15adb397ce423a6d97920a46b3893 Author: Oded Gabbay Date: Fri Mar 27 16:38:37 2020 +0300 habanalabs: increase timeout during reset [ Upstream commit 7a65ee046b2238e053f6ebb610e1a082cfc49490 ] When doing training, the DL framework (e.g. tensorflow) performs hundreds of thousands of memory allocations and mappings. In case the driver needs to perform hard-reset during training, the driver kills the application and unmaps all those memory allocations. Unfortunately, because of that large amount of mappings, the driver isn't able to do that in the current timeout (5 seconds). Therefore, increase the timeout significantly to 30 seconds to avoid situation where the driver resets the device with active mappings, which sometime can cause a kernel bug. BTW, it doesn't mean we will spend all the 30 seconds because the reset thread checks every one second if the unmap operation is done. Reviewed-by: Omer Shpigelman Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit afaff825e3a436f9d1e3986530133b1c91b54cd1 Author: Mika Westerberg Date: Thu May 14 16:30:43 2020 +0300 PCI/PM: Assume ports without DLL Link Active train links in 100 ms [ Upstream commit ec411e02b7a2e785a4ed9ed283207cd14f48699d ] Kai-Heng Feng reported that it takes a long time (> 1 s) to resume Thunderbolt-connected devices from both runtime suspend and system sleep (s2idle). This was because some Downstream Ports that support > 5 GT/s do not also support Data Link Layer Link Active reporting. Per PCIe r5.0 sec 6.6.1: With a Downstream Port that supports Link speeds greater than 5.0 GT/s, software must wait a minimum of 100 ms after Link training completes before sending a Configuration Request to the device immediately below that Port. Software can determine when Link training completes by polling the Data Link Layer Link Active bit or by setting up an associated interrupt (see Section 6.7.3.3). Sec 7.5.3.6 requires such Ports to support DLL Link Active reporting, but at least the Intel JHL6240 Thunderbolt 3 Bridge [8086:15c0] and the Intel JHL7540 Thunderbolt 3 Bridge [8086:15ea] do not. Previously we tried to wait for Link training to complete, but since there was no DLL Link Active reporting, all we could do was wait the worst-case 1000 ms, then another 100 ms. Instead of using the supported speeds to determine whether to wait for Link training, check whether the port supports DLL Link Active reporting. The Ports in question do not, so we'll wait only the 100 ms required for Ports that support Link speeds <= 5 GT/s. This of course assumes these Ports always train the Link within 100 ms even if they are operating at > 5 GT/s, which is not required by the spec. [bhelgaas: commit log, comment] Link: https://bugzilla.kernel.org/show_bug.cgi?id=206837 Link: https://lore.kernel.org/r/20200514133043.27429-1-mika.westerberg@linux.intel.com Reported-by: Kai-Heng Feng Tested-by: Kai-Heng Feng Signed-off-by: Mika Westerberg Signed-off-by: Bjorn Helgaas Signed-off-by: Sasha Levin commit be0ed15d88c65de0e28ff37a3b242e65a782fd98 Author: Cristian Klein Date: Fri May 8 17:26:04 2020 +0200 HID: Add quirks for Trust Panora Graphic Tablet [ Upstream commit fb68ada81e65d593b51544fa43c284322107a742 ] The Trust Panora Graphic Tablet has two interfaces. Interface zero reports pen movement, pen pressure and pen buttons. Interface one reports tablet buttons and tablet scroll. Both use the mouse protocol. Without these quirks, libinput gets confused about what device it talks to. For completeness, here is the usbhid-dump: ``` $ sudo usbhid-dump -d 145f:0212 003:013:001:DESCRIPTOR 1588949402.559961 05 0D 09 01 A1 01 85 07 A1 02 09 00 75 08 95 07 81 02 C0 C0 09 0E A1 01 85 05 09 23 A1 02 09 52 09 53 25 0A 75 08 95 02 B1 02 C0 C0 05 0C 09 36 A1 00 85 06 05 09 19 01 29 20 15 00 25 01 95 20 75 01 81 02 C0 003:013:000:DESCRIPTOR 1588949402.563942 05 01 09 02 A1 01 85 08 09 01 A1 00 05 09 19 01 29 03 15 00 25 01 95 03 75 01 81 02 95 05 81 01 05 01 09 30 09 31 09 38 09 00 15 81 25 7F 75 08 95 04 81 06 C0 C0 05 01 09 02 A1 01 85 09 09 01 A1 00 05 09 19 01 29 03 15 00 25 01 95 03 75 01 81 02 95 05 81 01 05 01 09 30 09 31 26 FF 7F 95 02 75 10 81 02 05 0D 09 30 26 FF 03 95 01 75 10 81 02 C0 C0 05 01 09 00 A1 01 85 04 A1 00 26 FF 00 09 00 75 08 95 07 B1 02 C0 C0 ``` Signed-off-by: Cristian Klein Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 2a50cd45bdda92452ee3b7c5a443075e11896d22 Author: Erwin Burema Date: Sun May 10 20:29:11 2020 +0200 ALSA: usb-audio: Add duplex sound support for USB devices using implicit feedback [ Upstream commit 10ce77e4817fef99e1166be7e6685a80c63bf77f ] For USB sound devices using implicit feedback the endpoint used for this feedback should be able to be opened twice, once for required feedback and second time for audio data. This way these devices can be put in duplex audio mode. Since this only works if the settings of the endpoint don't change a check is included for this. This fixes bug 207023 ("MOTU M2 regression on duplex audio") and should also fix bug 103751 ("M-Audio Fast Track Ultra usb audio device will not operate full-duplex") Fixes: c249177944b6 ("ALSA: usb-audio: add implicit fb quirk for MOTU M Series") Signed-off-by: Erwin Burema BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=207023 BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=103751 Link: https://lore.kernel.org/r/2410739.SCZni40SNb@alpha-wolf Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 7796fdd990c2373daebbf62d210f1a3966fcaafd Author: Thomas Ebeling Date: Fri May 15 13:46:05 2020 +0200 ALSA: usb-audio: fixing upper volume limit for RME Babyface Pro routing crosspoints [ Upstream commit 47b4f5f5b65680fbef7a7a9a4796b35f38a6e43e ] In my initial patch, these were set too low. Fixes: 3e8f3bd04716 ("ALSA: usb-audio: RME Babyface Pro mixer patch") Signed-off-by: Thomas Ebeling Link: https://lore.kernel.org/r/20200515114556.vtspnonzvp4xp44m@bollie.ca9.eu Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit e225cca05a020dfc7f60148ec294d39f8b993e38 Author: Jérôme Pouiller Date: Fri May 15 10:33:10 2020 +0200 staging: wfx: fix value of scan timeout [ Upstream commit 6598b12d6635e8e3060863b84c04e472546ee126 ] Before to start the scan request, the firmware signals (with a null frame) to the AP it won't be able to receive data. This frame can be long to send: up to 512TU. The current calculus of the scan timeout does not take into account this delay. Signed-off-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20200515083325.378539-5-Jerome.Pouiller@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 363e8bfc96b4e9d9e0a885408cecaf23df468523 Author: Gregory CLEMENT Date: Tue May 12 13:53:23 2020 +0200 tty: n_gsm: Fix waking up upper tty layer when room available [ Upstream commit 01dbb362f0a114fbce19c8abe4cd6f4710e934d5 ] Warn the upper layer when n_gms is ready to receive data again. Without this the associated virtual tty remains blocked indefinitely. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Gregory CLEMENT Link: https://lore.kernel.org/r/20200512115323.1447922-4-gregory.clement@bootlin.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c43f5761916560580397d9bc7902057835734306 Author: Gregory CLEMENT Date: Tue May 12 13:53:22 2020 +0200 tty: n_gsm: Fix SOF skipping [ Upstream commit 84d6f81c1fb58b56eba81ff0a36cf31946064b40 ] For at least some modems like the TELIT LE910, skipping SOF makes transfers blocking indefinitely after a short amount of data transferred. Given the small improvement provided by skipping the SOF (just one byte on about 100 bytes), it seems better to completely remove this "feature" than make it optional. Fixes: e1eaea46bb40 ("tty: n_gsm line discipline") Signed-off-by: Gregory CLEMENT Link: https://lore.kernel.org/r/20200512115323.1447922-3-gregory.clement@bootlin.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cad69308e40e7c5d833e1e2114d3836732a22525 Author: Michael Ellerman Date: Tue Apr 28 22:31:30 2020 +1000 powerpc/64: Don't initialise init_task->thread.regs [ Upstream commit 7ffa8b7dc11752827329e4e84a574ea6aaf24716 ] Aneesh increased the size of struct pt_regs by 16 bytes and started seeing this WARN_ON: smp: Bringing up secondary CPUs ... ------------[ cut here ]------------ WARNING: CPU: 0 PID: 0 at arch/powerpc/kernel/process.c:455 giveup_all+0xb4/0x110 Modules linked in: CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.7.0-rc2-gcc-8.2.0-1.g8f6a41f-default+ #318 NIP: c00000000001a2b4 LR: c00000000001a29c CTR: c0000000031d0000 REGS: c0000000026d3980 TRAP: 0700 Not tainted (5.7.0-rc2-gcc-8.2.0-1.g8f6a41f-default+) MSR: 800000000282b033 CR: 48048224 XER: 00000000 CFAR: c000000000019cc8 IRQMASK: 1 GPR00: c00000000001a264 c0000000026d3c20 c0000000026d7200 800000000280b033 GPR04: 0000000000000001 0000000000000000 0000000000000077 30206d7372203164 GPR08: 0000000000002000 0000000002002000 800000000280b033 3230303030303030 GPR12: 0000000000008800 c0000000031d0000 0000000000800050 0000000002000066 GPR16: 000000000309a1a0 000000000309a4b0 000000000309a2d8 000000000309a890 GPR20: 00000000030d0098 c00000000264da40 00000000fd620000 c0000000ff798080 GPR24: c00000000264edf0 c0000001007469f0 00000000fd620000 c0000000020e5e90 GPR28: c00000000264edf0 c00000000264d200 000000001db60000 c00000000264d200 NIP [c00000000001a2b4] giveup_all+0xb4/0x110 LR [c00000000001a29c] giveup_all+0x9c/0x110 Call Trace: [c0000000026d3c20] [c00000000001a264] giveup_all+0x64/0x110 (unreliable) [c0000000026d3c90] [c00000000001ae34] __switch_to+0x104/0x480 [c0000000026d3cf0] [c000000000e0b8a0] __schedule+0x320/0x970 [c0000000026d3dd0] [c000000000e0c518] schedule_idle+0x38/0x70 [c0000000026d3df0] [c00000000019c7c8] do_idle+0x248/0x3f0 [c0000000026d3e70] [c00000000019cbb8] cpu_startup_entry+0x38/0x40 [c0000000026d3ea0] [c000000000011bb0] rest_init+0xe0/0xf8 [c0000000026d3ed0] [c000000002004820] start_kernel+0x990/0x9e0 [c0000000026d3f90] [c00000000000c49c] start_here_common+0x1c/0x400 Which was unexpected. The warning is checking the thread.regs->msr value of the task we are switching from: usermsr = tsk->thread.regs->msr; ... WARN_ON((usermsr & MSR_VSX) && !((usermsr & MSR_FP) && (usermsr & MSR_VEC))); ie. if MSR_VSX is set then both of MSR_FP and MSR_VEC are also set. Dumping tsk->thread.regs->msr we see that it's: 0x1db60000 Which is not a normal looking MSR, in fact the only valid bit is MSR_VSX, all the other bits are reserved in the current definition of the MSR. We can see from the oops that it was swapper/0 that we were switching from when we hit the warning, ie. init_task. So its thread.regs points to the base (high addresses) in init_stack. Dumping the content of init_task->thread.regs, with the members of pt_regs annotated (the 16 bytes larger version), we see: 0000000000000000 c000000002780080 gpr[0] gpr[1] 0000000000000000 c000000002666008 gpr[2] gpr[3] c0000000026d3ed0 0000000000000078 gpr[4] gpr[5] c000000000011b68 c000000002780080 gpr[6] gpr[7] 0000000000000000 0000000000000000 gpr[8] gpr[9] c0000000026d3f90 0000800000002200 gpr[10] gpr[11] c000000002004820 c0000000026d7200 gpr[12] gpr[13] 000000001db60000 c0000000010aabe8 gpr[14] gpr[15] c0000000010aabe8 c0000000010aabe8 gpr[16] gpr[17] c00000000294d598 0000000000000000 gpr[18] gpr[19] 0000000000000000 0000000000001ff8 gpr[20] gpr[21] 0000000000000000 c00000000206d608 gpr[22] gpr[23] c00000000278e0cc 0000000000000000 gpr[24] gpr[25] 000000002fff0000 c000000000000000 gpr[26] gpr[27] 0000000002000000 0000000000000028 gpr[28] gpr[29] 000000001db60000 0000000004750000 gpr[30] gpr[31] 0000000002000000 000000001db60000 nip msr 0000000000000000 0000000000000000 orig_r3 ctr c00000000000c49c 0000000000000000 link xer 0000000000000000 0000000000000000 ccr softe 0000000000000000 0000000000000000 trap dar 0000000000000000 0000000000000000 dsisr result 0000000000000000 0000000000000000 ppr kuap 0000000000000000 0000000000000000 pad[2] pad[3] This looks suspiciously like stack frames, not a pt_regs. If we look closely we can see return addresses from the stack trace above, c000000002004820 (start_kernel) and c00000000000c49c (start_here_common). init_task->thread.regs is setup at build time in processor.h: #define INIT_THREAD { \ .ksp = INIT_SP, \ .regs = (struct pt_regs *)INIT_SP - 1, /* XXX bogus, I think */ \ The early boot code where we setup the initial stack is: LOAD_REG_ADDR(r3,init_thread_union) /* set up a stack pointer */ LOAD_REG_IMMEDIATE(r1,THREAD_SIZE) add r1,r3,r1 li r0,0 stdu r0,-STACK_FRAME_OVERHEAD(r1) Which creates a stack frame of size 112 bytes (STACK_FRAME_OVERHEAD). Which is far too small to contain a pt_regs. So the result is init_task->thread.regs is pointing at some stack frames on the init stack, not at a pt_regs. We have gotten away with this for so long because with pt_regs at its current size the MSR happens to point into the first frame, at a location that is not written to by the early asm. With the 16 byte expansion the MSR falls into the second frame, which is used by the compiler, and collides with a saved register that tends to be non-zero. As far as I can see this has been wrong since the original merge of 64-bit ppc support, back in 2002. Conceptually swapper should have no regs, it never entered from userspace, and in fact that's what we do on 32-bit. It's also presumably what the "bogus" comment is referring to. So I think the right fix is to just not-initialise regs at all. I'm slightly worried this will break some code that isn't prepared for a NULL regs, but we'll have to see. Remove the comment in head_64.S which refers to us setting up the regs (even though we never did), and is otherwise not really accurate any more. Reported-by: Aneesh Kumar K.V Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200428123130.73078-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit fd2036f8053d1b8294d8bf5d9a91b2130cb7120e Author: Rob Herring Date: Wed May 13 17:38:58 2020 -0500 PCI: Fix pci_register_host_bridge() device_register() error handling [ Upstream commit 1b54ae8327a4d630111c8d88ba7906483ec6010b ] If device_register() has an error, we should bail out of pci_register_host_bridge() rather than continuing on. Fixes: 37d6a0a6f470 ("PCI: Add pci_register_host_bridge() interface") Link: https://lore.kernel.org/r/20200513223859.11295-1-robh@kernel.org Signed-off-by: Rob Herring Signed-off-by: Bjorn Helgaas Reviewed-by: Lorenzo Pieralisi Reviewed-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 91aee019f9ecbabdb8ee623785b9fc48b587073c Author: Tero Kristo Date: Wed Apr 29 16:13:39 2020 +0300 clk: ti: composite: fix memory leak [ Upstream commit c7c1cbbc9217ebb5601b88d138d4a5358548de9d ] The parent_names is never released for a component clock definition, causing some memory leak. Fix by releasing it once it is no longer needed. Reported-by: Tomi Valkeinen Signed-off-by: Tero Kristo Link: https://lkml.kernel.org/r/20200429131341.4697-2-t-kristo@ti.com Acked-by: Tony Lindgren Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 2676aabee80c846f728ec5d4bb8211dd058c2e68 Author: Bjorn Andersson Date: Thu Oct 17 22:58:41 2019 -0700 arm64: dts: qcom: c630: Add WiFi node [ Upstream commit 3fb298d0b2f2a1d47d53806d4ddf8f4ae83353cc ] Specify regulators and enable the &wifi node. The firmware uses the 8 bit version of the host capability message, so specify this quirk. Reviewed-by: Robert Foss Reviewed-by: Vinod Koul Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20191018055841.3729591-1-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 6fe8ed270763a6a2e350bf37eee0f3857482ed48 Author: Bjorn Andersson Date: Fri Apr 17 00:07:12 2020 -0700 arm64: dts: qcom: db820c: Fix invalid pm8994 supplies [ Upstream commit 1cacdf5d3bb9644ac7b9339c611ac5b9dd90d09d ] It's uncertain where the "vreg_s8a_l3a_input" comes from, but the supply for VDD_L3_L11 on PM8994 should be VREG_S3A_1P3, so correct this - and drop the vreg_s8a_l3a_input. Reviewed-by: Vinod Koul Fixes: 83d9ed4342a3 ("arm64: dts: qcom: db820c: Use regulator names from schematics") Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20200417070712.1376355-1-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 7737ce3e0949aa0c505885184c361d4915014c98 Author: Wei Yongjun Date: Wed May 6 13:56:25 2020 +0000 USB: ohci-sm501: fix error return code in ohci_hcd_sm501_drv_probe() [ Upstream commit b919e077cccfbb77beb98809568b2fb0b4d113ec ] Fix to return a negative error code from the error handling case instead of 0, as done elsewhere in this function. Fixes: 7d9e6f5aebe8 ("usb: host: ohci-sm501: init genalloc for local memory") Signed-off-by: Wei Yongjun Acked-by: Alan Stern Link: https://lore.kernel.org/r/20200506135625.106910-1-weiyongjun1@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit cd96215fb3ac339e4a3b0903187af0c55ebf32f5 Author: Wei Yongjun Date: Thu May 7 05:41:09 2020 +0000 phy: ti: j721e-wiz: Fix some error return code in wiz_probe() [ Upstream commit e2ae8bca494481a9f38fcd1d52943ac04e654745 ] Fix to return negative error code from some error handling cases instead of 0, as done elsewhere in this function. Fixes: 091876cc355d ("phy: ti: j721e-wiz: Add support for WIZ module present in TI J721E SoC") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Acked-by: Roger Quadros Link: https://lore.kernel.org/r/20200507054109.110849-1-weiyongjun1@huawei.com Signed-off-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit 0f948abff12d957f9c950556df30a6959e01de62 Author: Arnd Bergmann Date: Thu May 7 23:34:28 2020 +0200 dlm: remove BUG() before panic() [ Upstream commit fe204591cc9480347af7d2d6029b24a62e449486 ] Building a kernel with clang sometimes fails with an objtool error in dlm: fs/dlm/lock.o: warning: objtool: revert_lock_pc()+0xbd: can't find jump dest instruction at .text+0xd7fc The problem is that BUG() never returns and the compiler knows that anything after it is unreachable, however the panic still emits some code that does not get fully eliminated. Having both BUG() and panic() is really pointless as the BUG() kills the current process and the subsequent panic() never hits. In most cases, we probably don't really want either and should replace the DLM_ASSERT() statements with WARN_ON(), as has been done for some of them. Remove the BUG() here so the user at least sees the panic message and we can reliably build randconfig kernels. Fixes: e7fd41792fc0 ("[DLM] The core of the DLM for GFS2/CLVM") Cc: Josh Poimboeuf Cc: clang-built-linux@googlegroups.com Signed-off-by: Arnd Bergmann Signed-off-by: David Teigland Signed-off-by: Sasha Levin commit 304f2b00164b827d0972116d1007a1eb3396f031 Author: Sibi Sankar Date: Wed Apr 15 20:21:10 2020 +0530 remoteproc: qcom_q6v5_mss: Drop accesses to MPSS PERPH register space [ Upstream commit a9fdc79d488623d36341f0f3d08f5aa1bedb9d53 ] 7C retail devices using MSA based boot will result in a fuse combination which will prevent accesses to MSS PERPH register space where the mpss clocks and halt-nav reside. So drop all accesses to the MPSS PERPH register space. Issuing HALT NAV request and turning on the mss clocks as part of SSR will no longer be required since the modem firmware will have the necessary fixes to ensure that there are no pending NAV DMA transactions. Tested-by: Evan Green Signed-off-by: Sibi Sankar Link: https://lore.kernel.org/r/20200415145110.20624-3-sibis@codeaurora.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 577a2b4b5c9345428be1864878f060775cd7bb1b Author: Dafna Hirschfeld Date: Wed May 6 12:09:03 2020 +0200 pinctrl: rockchip: fix memleak in rockchip_dt_node_to_map [ Upstream commit d7faa8ffb6be57bf8233a4b5a636d76b83c51ce7 ] In function rockchip_dt_node_to_map, a new_map variable is allocated by: new_map = devm_kcalloc(pctldev->dev, map_num, sizeof(*new_map), GFP_KERNEL); This uses devres and attaches new_map to the pinctrl driver. This cause a leak since new_map is not released when the probed driver is removed. Fix it by using kcalloc to allocate new_map and free it in `rockchip_dt_free_map` Signed-off-by: Dafna Hirschfeld Reviewed-by: Heiko Stuebner Link: https://lore.kernel.org/r/20200506100903.15420-1-dafna.hirschfeld@collabora.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit b7fcc8e32dc514ecbe0ec259cbe9800d53c0c0ab Author: Christophe JAILLET Date: Tue May 12 15:43:25 2020 +0200 ASoC: ti: omap-mcbsp: Fix an error handling path in 'asoc_mcbsp_probe()' [ Upstream commit 03990fd58d2b7c8f7d53e514ba9b8749fac260f9 ] If an error occurs after the call to 'omap_mcbsp_init()', the reference to 'mcbsp->fclk' must be decremented, as already done in the remove function. This can be achieved easily by using the devm_ variant of 'clk_get()' when the reference is taken in 'omap_mcbsp_init()' This fixes the leak in the probe and has the side effect to simplify both the error handling path of 'omap_mcbsp_init()' and the remove function. Signed-off-by: Christophe JAILLET Acked-by: Peter Ujfalusi Link: https://lore.kernel.org/r/20200512134325.252073-1-christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 038f34953d047b7e11aa6d3c0d7c721f41c725ea Author: Christophe JAILLET Date: Tue May 12 12:07:05 2020 +0200 ASoC: ux500: mop500: Fix some refcounted resources issues [ Upstream commit 4e8748fcaeec073e3ba794871ce86c545e4f961f ] There are 2 issues here: - if one of the 'of_parse_phandle' fails, calling 'mop500_of_node_put()' is a no-op because the 'mop500_dai_links' structure has not been initialized yet, so the referenced are not decremented - The reference stored in 'mop500_dai_links[i].codecs' is refcounted only once in the probe and must be decremented only once. Fixes: 39013bd60e79 ("ASoC: Ux500: Dispose of device nodes correctly") Signed-off-by: Christophe JAILLET Link: https://lore.kernel.org/r/20200512100705.246349-1-christophe.jaillet@wanadoo.fr Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7bba0e9bc3261c7bb356abf476f81be05a5ae1ec Author: Yongbo Zhang Date: Tue May 12 17:30:03 2020 +0800 SoC: rsnd: add interrupt support for SSI BUSIF buffer [ Upstream commit 66c705d07d784fb6b4622c6e47b6acae357472db ] SSI BUSIF buffer is possible to overflow or underflow, especially in a hypervisor environment. If there is no interrupt support, it will eventually lead to errors in pcm data. This patch adds overflow and underflow interrupt support for SSI BUSIF buffer. Reported-by: Chen Li Signed-off-by: Yongbo Zhang Tested-by: Chen Li Acked-by: Kuninori Morimoto Link: https://lore.kernel.org/r/20200512093003.28332-1-giraffesnn123@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 3bb0e768e4808dffad02f8981aaa5cf8a0e65061 Author: Masahiro Yamada Date: Sat Apr 25 15:06:40 2020 +0900 unicore32: do not evaluate compiler's library path when cleaning [ Upstream commit 081b4b54ff6c58be2ffcf09d42e5df8f031eacd0 ] Since commit a83e4ca26af8 ("kbuild: remove cc-option switch from -Wframe-larger-than="), 'make ARCH=unicore32 clean' emits error messages as follows: $ make ARCH=unicore32 clean gcc: error: missing argument to '-Wframe-larger-than=' gcc: error: missing argument to '-Wframe-larger-than=' We do not care compiler flags when cleaning. Use the '=' operator for lazy expansion because we do not use GNU_LIBC_A or GNU_LIBGCC_A when cleaning. Fixes: a83e4ca26af8 ("kbuild: remove cc-option switch from -Wframe-larger-than=") Signed-off-by: Masahiro Yamada Reviewed-by: Nick Desaulniers Signed-off-by: Sasha Levin commit b2c8373c3cf1785a49b2cf0aa56f14e9bf4b7923 Author: Masahiro Yamada Date: Sat Apr 18 03:04:55 2020 +0900 um: do not evaluate compiler's library path when cleaning [ Upstream commit 7e49afc03212010d0ee27532a75cfeb0125bd868 ] Since commit a83e4ca26af8 ("kbuild: remove cc-option switch from -Wframe-larger-than="), 'make ARCH=um clean' emits an error message as follows: $ make ARCH=um clean gcc: error: missing argument to '-Wframe-larger-than=' We do not care compiler flags when cleaning. Use the '=' operator for lazy expansion because we do not use LDFLAGS_pcap.o or LDFLAGS_vde.o when cleaning. While I was here, I removed the redundant -r option because it already exists in the recipe. Fixes: a83e4ca26af8 ("kbuild: remove cc-option switch from -Wframe-larger-than=") Signed-off-by: Masahiro Yamada Reviewed-by: Nathan Chancellor Tested-by: Nathan Chancellor [build] Signed-off-by: Sasha Levin commit 88868e552b1d677f026202efe8cb3f701121b0a3 Author: Chao Yu Date: Fri May 8 09:16:03 2020 +0800 f2fs: compress: fix zstd data corruption [ Upstream commit 1454c978efbb57b052670d50023f48c759d704ce ] During zstd compression, ZSTD_endStream() may return non-zero value because distination buffer is full, but there is still compressed data remained in intermediate buffer, it means that zstd algorithm can not save at last one block space, let's just writeback raw data instead of compressed one, this can fix data corruption when decompressing incomplete stored compression data. Fixes: 50cfa66f0de0 ("f2fs: compress: support zstd compress algorithm") Signed-off-by: Daeho Jeong Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit bec32a54a4de62b46466f4da1beb9ddd42db81b8 Author: Chao Yu Date: Thu Apr 23 17:57:33 2020 +0800 f2fs: fix potential use-after-free issue [ Upstream commit f3494345ce9999624b36109252a4bf5f00e51a46 ] In error path of f2fs_read_multi_pages(), it should let last referrer release decompress io context memory, otherwise, other referrer will cause use-after-free issue. Fixes: 4c8ff7095bef ("f2fs: support data compression") Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 84fb7a793ab63102492d12819a54bddaa1d69888 Author: YueHaibing Date: Sat May 9 19:21:35 2020 +0800 f2fs: Fix wrong stub helper update_sit_info [ Upstream commit 48abe91ac1ad27cd5a5709f983dcf58f2b9a6b70 ] update_sit_info should be f2fs_update_sit_info, otherwise build fails while no CONFIG_F2FS_STAT_FS. Fixes: fc7100ea2a52 ("f2fs: Add f2fs stats to sysfs") Signed-off-by: YueHaibing Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 5113fc1531ce797ff4865e7d0cd655e42aa6629e Author: Suganath Prabu S Date: Fri May 8 07:07:38 2020 -0400 scsi: mpt3sas: Fix double free warnings [ Upstream commit cbbfdb2a2416c9f0cde913cf09670097ac281282 ] Fix following warning from Smatch static analyser: drivers/scsi/mpt3sas/mpt3sas_base.c:5256 _base_allocate_memory_pools() warn: 'ioc->hpr_lookup' double freed drivers/scsi/mpt3sas/mpt3sas_base.c:5256 _base_allocate_memory_pools() warn: 'ioc->internal_lookup' double freed Link: https://lore.kernel.org/r/20200508110738.30732-1-suganath-prabu.subramani@broadcom.com Reported-by: Dan Carpenter Signed-off-by: Suganath Prabu S Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit fd75e7f71bc4e424155fc3785895a5174664c74e Author: Bodo Stroesser Date: Tue Apr 28 20:26:17 2020 +0200 scsi: target: loopback: Fix READ with data and sensebytes [ Upstream commit c68a56736c129f5dd1632856956f9c3e04bae200 ] We use tcm_loop with tape emulations running on tcmu. In case application reads a short tape block with a longer READ, or a long tape block with a short READ, according to SCC spec data has to be tranferred _and_ sensebytes with ILI set and information field containing the residual count. Similar problem also exists when using fixed block size in READ. Up to now tcm_loop is not prepared to handle sensebytes if input data is provided, as in tcm_loop_queue_data_in() it only sets SAM_STAT_GOOD and, if necessary, the residual count. To fix the bug, the same handling for sensebytes as present in tcm_loop_queue_status() must be done in tcm_loop_queue_data_in() also. After adding this handling, the two function now are nearly identical, so I created a single function with two wrappers. Link: https://lore.kernel.org/r/20200428182617.32726-1-bstroesser@ts.fujitsu.com Signed-off-by: Bodo Stroesser Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 8d63953cea3ef23bbe68d598b0c4f472bfdea974 Author: Loic Poulain Date: Tue Apr 21 14:00:24 2020 +0200 arm64: dts: msm8996: Fix CSI IRQ types [ Upstream commit 4a4a26317ec8aba575f6b85789a42639937bc1a4 ] Each IRQ_TYPE_NONE interrupt causes a warning at boot. Fix that by defining an appropriate type. Fixes: e0531312e78f ("arm64: dts: qcom: msm8996: Add CAMSS support") Signed-off-by: Loic Poulain Link: https://lore.kernel.org/r/1587470425-13726-1-git-send-email-loic.poulain@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit bdf48c0ae30766e61923d045f0a41ce1316a7f53 Author: Wei Yongjun Date: Sat May 9 08:42:37 2020 +0000 remoteproc/mediatek: fix invalid use of sizeof in scp_ipi_init() [ Upstream commit 8096f80a5c09b716be207eb042c4e40d6cdefbd2 ] sizeof() when applied to a pointer typed expression gives the size of the pointer, not that of the pointed data. Reviewed-by: Mathieu Poirier Fixes: 63c13d61eafe ("remoteproc/mediatek: add SCP support for mt8183") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20200509084237.36293-1-weiyongjun1@huawei.com Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 63aca0b1acb939f2cfa9e087a15f8ffa49236207 Author: Wei Yongjun Date: Sat May 9 09:33:37 2020 +0000 ASoC: SOF: core: fix error return code in sof_probe_continue() [ Upstream commit 7d8785bc7adbb4dc5ba8ee06994107637848ded8 ] Fix to return negative error code -ENOMEM from the IPC init error handling case instead of 0, as done elsewhere in this function. Fixes: c16211d6226d ("ASoC: SOF: Add Sound Open Firmware driver core") Reported-by: Hulk Robot Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20200509093337.78897-1-weiyongjun1@huawei.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f8fecfdd695a00a333a7fbb48e9641492b63f4b6 Author: Nicolas Saenz Julienne Date: Thu May 7 19:20:20 2020 +0200 PCI: brcmstb: Assert fundamental reset on initialization [ Upstream commit 22e21e51ce755399fd42055a3f668ee4af370881 ] While preparing the driver for upstream this detail was missed. If not asserted during the initialization process, devices connected on the bus will not be made aware of the internal reset happening. This, potentially resulting in unexpected behavior. Link: https://lore.kernel.org/r/20200507172020.18000-1-nsaenzjulienne@suse.de Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver") Signed-off-by: Nicolas Saenz Julienne Signed-off-by: Lorenzo Pieralisi Acked-by: Florian Fainelli Signed-off-by: Sasha Levin commit eade79161e9d71628eed58be72e065e18c31ef08 Author: Dmitry Osipenko Date: Sun Mar 29 18:15:44 2020 +0200 power: supply: smb347-charger: IRQSTAT_D is volatile [ Upstream commit c32ea07a30630ace950e07ffe7a18bdcc25898e1 ] Fix failure when USB cable is connected: smb347 2-006a: reading IRQSTAT_D failed Fixes: 1502cfe19bac ("smb347-charger: Fix battery status reporting logic for charger faults") Tested-by: David Heidelberg Signed-off-by: Dmitry Osipenko Signed-off-by: David Heidelberg Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit c0f32d707495957ef9cdce137f3a69508d8b3d5e Author: Christophe JAILLET Date: Sat May 9 10:23:23 2020 +0200 power: supply: lp8788: Fix an error handling path in 'lp8788_charger_probe()' [ Upstream commit 934ed3847a4ebc75b655659c4d2349ba4337941c ] In the probe function, in case of error, resources allocated in 'lp8788_setup_adc_channel()' must be released. This can be achieved easily by using the devm_ variant of 'iio_channel_get()'. This has the extra benefit to simplify the remove function and to axe the 'lp8788_release_adc_channel()' function which is now useless. Fixes: 98a276649358 ("power_supply: Add new lp8788 charger driver") Signed-off-by: Christophe JAILLET Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit a98f8a0edd6f50150eb43e6b3c5208fc705e950b Author: Takashi Sakamoto Date: Fri May 8 13:36:26 2020 +0900 ALSA: firewire-lib: fix invalid assignment to union data for directional parameter [ Upstream commit 8304cf77c92038cd1c50c27b69d30be695cc8003 ] Although the value of FDF is used just for outgoing stream, the assignment to union member is done for both directions of stream. At present this causes no issue because the value of same position is reassigned later for opposite stream. However, it's better to add if statement. Fixes: d3d10a4a1b19 ("ALSA: firewire-lib: use union for directional parameters") Signed-off-by: Takashi Sakamoto Link: https://lore.kernel.org/r/20200508043635.349339-2-o-takashi@sakamocchi.jp Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 48af7ce3128cc2d5cff9d6e92fe60b38a4adf3a3 Author: Viacheslav Dubeyko Date: Fri Apr 10 11:07:08 2020 +0300 scsi: qla2xxx: Fix warning after FC target reset [ Upstream commit f839544ccff60cbe534282aac68858fc3fb278ca ] Currently, FC target reset finishes with the warning message: [84010.596893] ------------[ cut here ]------------ [84010.596917] WARNING: CPU: 238 PID: 279973 at ../drivers/scsi/qla2xxx/qla_target.c:6644 qlt_enable_vha+0x1d0/0x260 [qla2xxx] [84010.596918] Modules linked in: vrf af_packet 8021q garp mrp stp llc netlink_diag target_tatlin_tblock(OEX) dm_ec(OEX) ttln_rdma(OEX) dm_frontend(OEX) nvme_rdma nvmet tcm_qla2xxx iscsi_target_mod target_core_mod at24 nvmem_core pnv_php ipmi_watchdog ipmi_ssif vmx_crypto gf128mul crct10dif_vpmsum qla2xxx rpcrdma nvme_fc powernv_flash(X) nvme_fabrics uio_pdrv_genirq mtd rtc_opal(X) ibmpowernv(X) opal_prd(X) uio scsi_transport_fc i2c_opal(X) ses enclosure ipmi_poweroff ast i2c_algo_bit ttm bmc_mcu(OEX) drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops drm drm_panel_orientation_quirks agpgart nfsd auth_rpcgss nfs_acl ipmi_powernv(X) lockd ipmi_devintf ipmi_msghandler grace dummy ext4 crc16 jbd2 mbcache sd_mod rdma_ucm ib_iser rdma_cm ib_umad iw_cm ib_ipoib libiscsi scsi_transport_iscsi ib_cm [84010.596975] configfs mlx5_ib ib_uverbs ib_core mlx5_core crc32c_vpmsum xhci_pci xhci_hcd mpt3sas(OEX) tg3 usbcore mlxfw tls raid_class libphy scsi_transport_sas devlink ptp pps_core nvme nvme_core sunrpc dm_mirror dm_region_hash dm_log sg dm_multipath dm_mod scsi_dh_rdac scsi_dh_emc scsi_dh_alua scsi_mod autofs4 [84010.597001] Supported: Yes, External [84010.597004] CPU: 238 PID: 279973 Comm: bash Tainted: G OE 4.12.14-197.29-default #1 SLE15-SP1 [84010.597006] task: c000000a104c0000 task.stack: c000000b52188000 [84010.597007] NIP: d00000001ffd7f78 LR: d00000001ffd7f6c CTR: c0000000001676c0 [84010.597008] REGS: c000000b5218b910 TRAP: 0700 Tainted: G OE (4.12.14-197.29-default) [84010.597008] MSR: 900000010282b033 [84010.597015] CR: 48242424 XER: 00000000 [84010.597016] CFAR: d00000001ff45d08 SOFTE: 1 GPR00: d00000001ffd7f6c c000000b5218bb90 d00000002001b228 0000000000000102 GPR04: 0000000000000001 0000000000000001 00013d91ed0a5e2d 0000000000000000 GPR08: c000000007793300 0000000000000000 0000000000000000 c000000a086e7818 GPR12: 0000000000002200 c000000007793300 0000000000000000 000000012bc937c0 GPR16: 000000012bbf7ed0 0000000000000000 000000012bc3dd10 0000000000000000 GPR20: 000000012bc4db28 0000010036442810 000000012bc97828 000000012bc96c70 GPR24: 00000100365b1550 0000000000000000 00000100363f3d80 c000000be20d3080 GPR28: c000000bda7eae00 c000000be20db7e8 c000000be20d3778 c000000be20db7e8 [84010.597042] NIP [d00000001ffd7f78] qlt_enable_vha+0x1d0/0x260 [qla2xxx] [84010.597051] LR [d00000001ffd7f6c] qlt_enable_vha+0x1c4/0x260 [qla2xxx] [84010.597051] Call Trace: [84010.597061] [c000000b5218bb90] [d00000001ffd7f6c] qlt_enable_vha+0x1c4/0x260 [qla2xxx] (unreliable) [84010.597064] [c000000b5218bc20] [d000000009820b6c] tcm_qla2xxx_tpg_enable_store+0xc4/0x130 [tcm_qla2xxx] [84010.597067] [c000000b5218bcb0] [d0000000185d0e68] configfs_write_file+0xd0/0x190 [configfs] [84010.597072] [c000000b5218bd00] [c0000000003d0edc] __vfs_write+0x3c/0x1e0 [84010.597074] [c000000b5218bd90] [c0000000003d2ea8] vfs_write+0xd8/0x220 [84010.597076] [c000000b5218bde0] [c0000000003d4ddc] SyS_write+0x6c/0x110 [84010.597079] [c000000b5218be30] [c00000000000b188] system_call+0x3c/0x130 [84010.597080] Instruction dump: [84010.597082] 7d0050a8 7d084b78 7d0051ad 40c2fff4 7fa3eb78 4bf73965 60000000 7fa3eb78 [84010.597086] 4bf6dcd9 60000000 2fa30000 419eff40 <0fe00000> 4bffff38 e95f0058 a12a0180 [84010.597090] ---[ end trace e32abaf6e6fee826 ]--- To reproduce: echo 0x7fffffff > /sys/module/qla2xxx/parameters/logging modprobe target_core_mod modprobe tcm_qla2xxx mkdir /sys/kernel/config/target/qla2xxx mkdir /sys/kernel/config/target/qla2xxx/ mkdir /sys/kernel/config/target/qla2xxx//tpgt_1 echo 1 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable echo 0 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable echo 1 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable SYSTEM START kernel: pid 327:drivers/scsi/qla2xxx/qla_init.c:2174 qla2x00_initialize_adapter(): vha->flags.online 0x0 <...> kernel: pid 327:drivers/scsi/qla2xxx/qla_os.c:3444 qla2x00_probe_one(): vha->flags.online 0x1 echo 1 > /sys/kernel/config/target/qla2xxx/21:00:00:24:ff:86:a6:2a/tpgt_1/enable kernel: pid 348:drivers/scsi/qla2xxx/qla_init.c:6641 qla2x00_abort_isp_cleanup(): vha->flags.online 0x0, ISP_ABORT_NEEDED 0x0 <...> kernel: pid 348:drivers/scsi/qla2xxx/qla_init.c:6998 qla2x00_restart_isp(): vha->flags.online 0x0 echo 0 > /sys/kernel/config/target/qla2xxx/21:00:00:24:ff:86:a6:2a/tpgt_1/enable kernel: pid 348:drivers/scsi/qla2xxx/qla_init.c:6641 qla2x00_abort_isp_cleanup(): vha->flags.online 0x0, ISP_ABORT_NEEDED 0x0 <...> kernel: pid 1404:drivers/scsi/qla2xxx/qla_os.c:1107 qla2x00_wait_for_hba_online(): base_vha->flags.online 0x0 echo 1 > /sys/kernel/config/target/qla2xxx/21:00:00:24:ff:86:a6:2a/tpgt_1/enable kernel: pid 1404:drivers/scsi/qla2xxx/qla_os.c:1107 qla2x00_wait_for_hba_online(): base_vha->flags.online 0x0 kernel: -----------[ cut here ]----------- kernel: WARNING: CPU: 1 PID: 1404 at drivers/scsi/qla2xxx/qla_target.c:6654 qlt_enable_vha+0x1e0/0x280 [qla2xxx] The issue happens because no real ISP reset is executed. The qla2x00_abort_isp(scsi_qla_host_t *vha) function expects that vha->flags.online will be not zero for ISP reset procedure. This patch sets vha->flags.online to 1 before calling ->abort_isp() for starting the ISP reset. Link: https://lore.kernel.org/r/1d7b21bf9f7676643239eb3d60eaca7cfa505cf0.camel@yadro.com Reviewed-by: Roman Bolshakov Signed-off-by: Viacheslav Dubeyko Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit d4c7acca9d36e8bff222537c70a471b9552f3432 Author: Kai-Heng Feng Date: Wed May 6 01:34:21 2020 +0800 PCI/ASPM: Allow ASPM on links to PCIe-to-PCI/PCI-X Bridges [ Upstream commit 66ff14e59e8a30690755b08bc3042359703fb07a ] 7d715a6c1ae5 ("PCI: add PCI Express ASPM support") added the ability for Linux to enable ASPM, but for some undocumented reason, it didn't enable ASPM on links where the downstream component is a PCIe-to-PCI/PCI-X Bridge. Remove this exclusion so we can enable ASPM on these links. The Dell OptiPlex 7080 mentioned in the bugzilla has a TI XIO2001 PCIe-to-PCI Bridge. Enabling ASPM on the link leading to it allows the Intel SoC to enter deeper Package C-states, which is a significant power savings. [bhelgaas: commit log] Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=207571 Link: https://lore.kernel.org/r/20200505173423.26968-1-kai.heng.feng@canonical.com Signed-off-by: Kai-Heng Feng Signed-off-by: Bjorn Helgaas Reviewed-by: Mika Westerberg Signed-off-by: Sasha Levin commit 1c57a13369c1ea5a781156d77b8b8797e7dac076 Author: Andrew Murray Date: Fri Oct 4 14:29:41 2019 +0100 PCI: rcar: Fix incorrect programming of OB windows [ Upstream commit 2b9f217433e31d125fb697ca7974d3de3ecc3e92 ] The outbound windows (PCIEPAUR(x), PCIEPALR(x)) describe a mapping between a CPU address (which is determined by the window number 'x') and a programmed PCI address - Thus allowing the controller to translate CPU accesses into PCI accesses. However the existing code incorrectly writes the CPU address - lets fix this by writing the PCI address instead. For memory transactions, existing DT users describe a 1:1 identity mapping and thus this change should have no effect. However the same isn't true for I/O. Link: https://lore.kernel.org/r/20191004132941.6660-1-andrew.murray@arm.com Fixes: c25da4778803 ("PCI: rcar: Add Renesas R-Car PCIe driver") Tested-by: Marek Vasut Signed-off-by: Andrew Murray Signed-off-by: Lorenzo Pieralisi Reviewed-by: Marek Vasut Signed-off-by: Sasha Levin commit c2e22eb0d96818d917fb57bbf0306e351e23f773 Author: Kuppuswamy Sathyanarayanan Date: Wed Apr 8 14:40:03 2020 -0700 drivers: base: Fix NULL pointer exception in __platform_driver_probe() if a driver developer is foolish [ Upstream commit 388bcc6ecc609fca1b4920de7dc3806c98ec535e ] If platform bus driver registration is failed then, accessing platform bus spin lock (&drv->driver.bus->p->klist_drivers.k_lock) in __platform_driver_probe() without verifying the return value __platform_driver_register() can lead to NULL pointer exception. So check the return value before attempting the spin lock. One such example is below: For a custom usecase, I have intentionally failed the platform bus registration and I expected all the platform device/driver registrations to fail gracefully. But I came across this panic issue. [ 1.331067] BUG: kernel NULL pointer dereference, address: 00000000000000c8 [ 1.331118] #PF: supervisor write access in kernel mode [ 1.331163] #PF: error_code(0x0002) - not-present page [ 1.331208] PGD 0 P4D 0 [ 1.331233] Oops: 0002 [#1] PREEMPT SMP [ 1.331268] CPU: 3 PID: 1 Comm: swapper/0 Tainted: G W 5.6.0-00049-g670d35fb0144 #165 [ 1.331341] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015 [ 1.331406] RIP: 0010:_raw_spin_lock+0x15/0x30 [ 1.331588] RSP: 0000:ffffc9000001be70 EFLAGS: 00010246 [ 1.331632] RAX: 0000000000000000 RBX: 00000000000000c8 RCX: 0000000000000001 [ 1.331696] RDX: 0000000000000001 RSI: 0000000000000092 RDI: 0000000000000000 [ 1.331754] RBP: 00000000ffffffed R08: 0000000000000501 R09: 0000000000000001 [ 1.331817] R10: ffff88817abcc520 R11: 0000000000000670 R12: 00000000ffffffed [ 1.331881] R13: ffffffff82dbc268 R14: ffffffff832f070a R15: 0000000000000000 [ 1.331945] FS: 0000000000000000(0000) GS:ffff88817bd80000(0000) knlGS:0000000000000000 [ 1.332008] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 1.332062] CR2: 00000000000000c8 CR3: 000000000681e001 CR4: 00000000003606e0 [ 1.332126] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 1.332189] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 1.332252] Call Trace: [ 1.332281] __platform_driver_probe+0x92/0xee [ 1.332323] ? rtc_dev_init+0x2b/0x2b [ 1.332358] cmos_init+0x37/0x67 [ 1.332396] do_one_initcall+0x7d/0x168 [ 1.332428] kernel_init_freeable+0x16c/0x1c9 [ 1.332473] ? rest_init+0xc0/0xc0 [ 1.332508] kernel_init+0x5/0x100 [ 1.332543] ret_from_fork+0x1f/0x30 [ 1.332579] CR2: 00000000000000c8 [ 1.332616] ---[ end trace 3bd87f12e9010b87 ]--- [ 1.333549] note: swapper/0[1] exited with preempt_count 1 [ 1.333592] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 [ 1.333736] Kernel Offset: disabled Note, this can only be triggered if a driver errors out from this call, which should never happen. If it does, the driver needs to be fixed. Signed-off-by: Kuppuswamy Sathyanarayanan Link: https://lore.kernel.org/r/20200408214003.3356-1-sathyanarayanan.kuppuswamy@linux.intel.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 9a206a534f82a666b8994fb2246d54e9575de6de Author: Russell King Date: Mon Apr 27 19:49:22 2020 +0100 i2c: pxa: fix i2c_pxa_scream_blue_murder() debug output [ Upstream commit 88b73ee7ca4c90baf136ed5a8377fc5a9b73ac08 ] The IRQ log output is supposed to appear on a single line. However, commit 3a2dc1677b60 ("i2c: pxa: Update debug function to dump more info on error") resulted in it being printed one-entry-per-line, which is excessively long. Fixing this is not a trivial matter; using pr_cont() doesn't work as the previous dev_dbg() may not have been compiled in, or may be dynamic. Since the rest of this function output is at error level, and is also debug output, promote this to error level as well to avoid this problem. Reduce the number of always zero prefix digits to save screen real- estate. Signed-off-by: Russell King Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit ce6a727276c55c486fe65e1f41ed8afcdacec75d Author: Christophe JAILLET Date: Sat Apr 18 10:16:37 2020 +0200 PCI: v3-semi: Fix a memory leak in v3_pci_probe() error handling paths [ Upstream commit bca718988b9008d0d5f504e2d318178fc84958c1 ] If we fails somewhere in 'v3_pci_probe()', we need to free 'host'. Use the managed version of 'pci_alloc_host_bridge()' to do that easily. The use of managed resources is already widely used in this driver. Link: https://lore.kernel.org/r/20200418081637.1585-1-christophe.jaillet@wanadoo.fr Fixes: 68a15eb7bd0c ("PCI: v3-semi: Add V3 Semiconductor PCI host driver") Signed-off-by: Christophe JAILLET [lorenzo.pieralisi@arm.com: commit log] Signed-off-by: Lorenzo Pieralisi Acked-by: Linus Walleij Signed-off-by: Sasha Levin commit f799194b3c3f196480667ad3443a0b04ea29fd11 Author: Arnd Bergmann Date: Wed Apr 29 16:21:09 2020 +0200 staging: wfx: avoid compiler warning on empty array [ Upstream commit 2eeefd3787fdc6319124945d453774be95b97897 ] When CONFIG_OF is disabled, gcc-9 produces a warning about the wfx_sdio_of_match[] array having a declaration without a dimension: drivers/staging/wfx/bus_sdio.c:159:34: error: array 'wfx_sdio_of_match' assumed to have one element [-Werror] 159 | static const struct of_device_id wfx_sdio_of_match[]; | ^~~~~~~~~~~~~~~~~ Move the proper declaration up and out of the #ifdef instead. Fixes: a7a91ca5a23d ("staging: wfx: add infrastructure for new driver") Signed-off-by: Arnd Bergmann Cc: Jerome Pouiller Link: https://lore.kernel.org/r/20200429142119.1735196-1-arnd@arndb.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit fdf71c0e8291e3a24736d422107b896a77fe0e96 Author: Matej Dujava Date: Thu Apr 30 22:09:24 2020 +0200 staging: sm750fb: add missing case while setting FB_VISUAL [ Upstream commit fa90133377f4a7f15a937df6ad55133bb57c5665 ] Switch statement does not contain all cases: 8, 16, 24, 32. This patch will add missing one (24) Fixes: 81dee67e215b ("staging: sm750fb: add sm750 to staging") Signed-off-by: Matej Dujava Link: https://lore.kernel.org/r/1588277366-19354-2-git-send-email-mdujava@kocurkovo.cz Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 1d683cfbddaf15d5b0429c5f04a1a3bb5d03f4e2 Author: Oscar Carter Date: Mon May 4 17:09:11 2020 +0200 staging: wilc1000: Increase the size of wid_list array [ Upstream commit a4338ed2e1cf724563956ec5f91deeaabfedbe23 ] Increase by one the size of wid_list array as index variable can reach a value of 5. If this happens, an out-of-bounds access is performed. Also, use a #define instead of a hard-coded literal for the new array size. Addresses-Coverity-ID: 1451981 ("Out-of-bounds access") Fixes: f5a3cb90b802d ("staging: wilc1000: add passive scan support") Acked-by: Ajay Singh Signed-off-by: Oscar Carter Link: https://lore.kernel.org/r/20200504150911.4470-1-oscar.carter@gmx.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 50affa2a092dc7d26ab75d901fe6b137d3f41424 Author: Thinh Nguyen Date: Sun Mar 29 16:12:57 2020 -0700 usb: dwc3: gadget: Properly handle failed kick_transfer [ Upstream commit 8d99087c2db863c5fa3a4a1f3cb82b3a493705ca ] If dwc3 fails to issue START_TRANSFER/UPDATE_TRANSFER command, then we should properly end an active transfer and give back all the started requests. However if it's for an isoc endpoint, the failure maybe due to bus-expiry status. In this case, don't give back the requests and wait for the next retry. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 26b36d7977327029985202743d2f79a54d0059be Author: Neil Armstrong Date: Thu Mar 26 14:44:57 2020 +0100 usb: dwc3: meson-g12a: check return of dwc3_meson_g12a_usb_init [ Upstream commit 8f5bc1ec770c2bdc8c604ba4119a77d81d8f3529 ] The dwc3_meson_g12a_usb_init function can return an error, check it. Fixes: c99993376f72ca ("usb: dwc3: Add Amlogic G12A DWC3 glue") Reviewed-by: Martin Blumenstingl Signed-off-by: Neil Armstrong Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 36a63f824bed4a4e6df40f7c2f0f5e67e6ccf51a Author: Thinh Nguyen Date: Thu Mar 5 13:23:55 2020 -0800 usb: dwc3: gadget: Properly handle ClearFeature(halt) [ Upstream commit cb11ea56f37a36288cdd0a4799a983ee3aa437dd ] DWC3 must not issue CLEAR_STALL command to control endpoints. The controller automatically clears the STALL when it receives the SETUP token. Also, when the driver receives ClearFeature(halt_ep), DWC3 must stop any active transfer from the endpoint and give back all the requests to the function drivers. Fixes: 72246da40f37 ("usb: Introduce DesignWare USB3 DRD Driver") Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 9560b386f5ba1005b61da459d3b6d0f0dfee2727 Author: Arnd Bergmann Date: Tue Apr 28 23:53:29 2020 +0200 HID: intel-ish-hid: avoid bogus uninitialized-variable warning [ Upstream commit 0b66fb3e6b7a53688f8e20945ac78cd3d832c65f ] Older compilers like gcc-4.8 don't see that the variable is initialized when it is used: In file included from include/linux/compiler_types.h:68:0, from :0: drivers/hid/intel-ish-hid/ishtp-fw-loader.c: In function 'load_fw_from_host': include/linux/compiler-gcc.h:75:45: warning: 'fw_info.ldr_capability.max_dma_buf_size' may be used uninitialized in this function [-Wmaybe-uninitialized] #define __UNIQUE_ID(prefix) __PASTE(__PASTE(__UNIQUE_ID_, prefix), __COUNTER__) ^ drivers/hid/intel-ish-hid/ishtp-fw-loader.c:770:22: note: 'fw_info.ldr_capability.max_dma_buf_size' was declared here struct shim_fw_info fw_info; ^ Make sure to initialize it before returning an error from ish_query_loader_prop(). Fixes: 91b228107da3 ("HID: intel-ish-hid: ISH firmware loader client driver") Signed-off-by: Arnd Bergmann Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 38622d708e9a0383830175dbfdf0c6854274f8a5 Author: Andrew Jeffery Date: Sat Apr 11 11:44:58 2020 +0930 ARM: dts: aspeed: Change KCS nodes to v2 binding [ Upstream commit fa4c8ec6feaa3237f5d44cb8c6d0aa0dff6e1bcc ] Fixes the following warnings for both g5 and g6 SoCs: arch/arm/boot/dts/aspeed-g5.dtsi:376.19-381.8: Warning (unit_address_vs_reg): /ahb/apb/lpc@1e789000/lpc-bmc@0/kcs1@0: node has a unit name, but no reg property Signed-off-by: Andrew Jeffery Signed-off-by: Joel Stanley Signed-off-by: Sasha Levin commit b7a88bda2dd995960722cde04e4c3ff1c88b7bab Author: Eddie James Date: Thu Mar 26 09:17:21 2020 -0500 ARM: dts: aspeed: ast2600: Set arch timer always-on [ Upstream commit c998f40f2ae6a48e93206e2c1ea0691479989611 ] According to ASPEED, FTTMR010 is not intended to be used in the AST2600. The arch timer should be used, but Linux doesn't enable high-res timers without being assured that the arch timer is always on, so set that property in the devicetree. The FTTMR010 device is described by set to disabled. This fixes highres timer support for AST2600. Fixes: 2ca5646b5c2f ("ARM: dts: aspeed: Add AST2600 and EVB") Signed-off-by: Eddie James Reviewed-by: Joel Stanley Signed-off-by: Joel Stanley Signed-off-by: Sasha Levin commit 51cfd876ddb0ccc2645f0f35c91a7dfe314dd760 Author: Pierre-Louis Bossart Date: Mon Apr 20 02:51:15 2020 +0800 soundwire: slave: don't init debugfs on device registration error [ Upstream commit 8893ab5e8ee5d7c12e0fc1dca4a309475064473d ] The error handling flow seems incorrect, there is no reason to try and add debugfs support if the device registration did not succeed. Return on error. Signed-off-by: Pierre-Louis Bossart Signed-off-by: Bard Liao Reviewed-by: Ranjani Sridharan Reviewed-by: Guennadi Liakhovetski Link: https://lore.kernel.org/r/20200419185117.4233-2-yung-chuan.liao@linux.intel.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit 23be2c6ff86e25f780bbd82ded0a64bc34b874f6 Author: Yong Zhi Date: Fri May 1 18:44:21 2020 -0500 ASoC: max98373: reorder max98373_reset() in resume [ Upstream commit 1a446873d7dd3a450f685928ce7f1907bde4583d ] During S3 test, the following error was observed: [ 726.174237] i2c_designware i2c_designware.0: platform_pm_resume+0x0/0x3d returned 0 after 0 usecs [ 726.184187] max98373 i2c-MX98373:00: calling max98373_resume+0x0/0x30 [snd_soc_max98373] @ 12698, parent: i2c-11 [ 726.195589] max98373 i2c-MX98373:00: Reset command failed. (ret:-16) When calling regmap_update_bits(), since map->reg_update_bits is NULL, _regmap_read() is entered with the following logic: if (!map->cache_bypass) { ret = regcache_read(map, reg, val); if (ret == 0) return 0; } if (map->cache_only) return -EBUSY; regcache_read() hits -EINVAL because MAX98373_R2000_SW_RESET is volatile, as map->cache_only is set by codec suspend, thus -EBUSY is returned. Fix by moving max98373_reset() after cache_only set to false in max98373_resume(). Signed-off-by: Yong Zhi Link: https://lore.kernel.org/r/1588376661-29799-1-git-send-email-yong.zhi@intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 78cdcca8cf02c42af5c7c9fcf9f2b8dd8e425123 Author: Martin Blumenstingl Date: Fri May 1 23:57:17 2020 +0200 clk: meson: meson8b: Don't rely on u-boot to init all GP_PLL registers [ Upstream commit a29ae8600d50ece1856b062a39ed296b8b952259 ] Not all u-boot versions initialize the HHI_GP_PLL_CNTL[2-5] registers. In that case all HHI_GPLL_PLL_CNTL[1-5] registers are 0x0 and when booting Linux the PLL fails to lock. The initialization sequence from u-boot is: - put the PLL into reset - write 0x59C88000 to HHI_GP_PLL_CNTL2 - write 0xCA463823 to HHI_GP_PLL_CNTL3 - write 0x0286A027 to HHI_GP_PLL_CNTL4 - write 0x00003000 to HHI_GP_PLL_CNTL5 - set M, N, OD and the enable bit - take the PLL out of reset - check if it has locked - disable the PLL In Linux we already initialize M, N, OD, the enable and the reset bits. Also the HHI_GP_PLL_CNTL[2-5] registers with these magic values (the exact meaning is unknown) so the PLL can lock when the vendor u-boot did not initialize these registers yet. Fixes: b882964b376f21 ("clk: meson: meson8b: add support for the GP_PLL clock on Meson8m2") Signed-off-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20200501215717.735393-1-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit e5228a0c8c5c78a3013569621e1255c7c0d9306b Author: Kai-Heng Feng Date: Thu Apr 30 17:11:39 2020 +0800 ASoC: SOF: Update correct LED status at the first time usage of update_mute_led() [ Upstream commit 49c22696348d6e7c8a2ecfd7e60fddfe188ded82 ] At the first time update_mute_led() gets called, if channels are already muted, the temp value equals to led_value as 0, skipping the following LED setting. So set led_value to -1 as an uninitialized state, to update the correct LED status at first time usage. Fixes: 5d43001ae436 ("ASoC: SOF: acpi led support for switch controls") Signed-off-by: Kai-Heng Feng Reviewed-by: Ranjani Sridharan Acked-by: Kai Vehmanen Link: https://lore.kernel.org/r/20200430091139.7003-1-kai.heng.feng@canonical.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 29301fa9a7bdf1b0b97a2f0b59bbc6865db26528 Author: Neil Armstrong Date: Thu Mar 26 17:59:58 2020 +0100 arm64: dts: meson: fix leds subnodes name [ Upstream commit 08dc0e5dd9aabd52cff9e94febe6b282d29deca4 ] Fix the leds subnode names to match (^led-[0-9a-f]$|led) It fixes: meson-g12b-a311d-khadas-vim3.dt.yaml: leds: 'red', 'white' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-g12b-s922x-khadas-vim3.dt.yaml: leds: 'red', 'white' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-g12b-odroid-n2.dt.yaml: leds: 'blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxbb-nanopi-k2.dt.yaml: leds: 'stat' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxbb-nexbox-a95x.dt.yaml: leds: 'blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxbb-odroidc2.dt.yaml: leds: 'blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxbb-vega-s95-pro.dt.yaml: leds: 'blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxbb-vega-s95-meta.dt.yaml: leds: 'blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxbb-vega-s95-telos.dt.yaml: leds: 'blue' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxbb-wetek-hub.dt.yaml: leds: 'system' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxbb-wetek-play2.dt.yaml: leds: 'ethernet', 'system', 'wifi' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxl-s905x-libretech-cc.dt.yaml: leds: 'blue', 'system' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxl-s905d-libretech-pc.dt.yaml: leds: 'blue', 'green' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxm-rbox-pro.dt.yaml: leds: 'blue', 'red' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-gxm-s912-libretech-pc.dt.yaml: leds: 'blue', 'green' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-sm1-sei610.dt.yaml: leds: 'bluetooth' does not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' meson-sm1-khadas-vim3l.dt.yaml: leds: 'red', 'white' do not match any of the regexes: '(^led-[0-9a-f]$|led)', 'pinctrl-[0-9]+' Signed-off-by: Neil Armstrong Signed-off-by: Kevin Hilman Link: https://lore.kernel.org/r/20200326165958.19274-6-narmstrong@baylibre.com Signed-off-by: Sasha Levin commit ad4ede83b784604ec9c7683498d5ca04b99d5e2c Author: Neil Armstrong Date: Thu Mar 26 17:59:56 2020 +0100 arm64: dts: meson-g12b-ugoos-am6: fix board compatible [ Upstream commit 5c28dcbb3a1be167c07784b5f710ec602a57bea2 ] Add missing amlogic,s922x in the board compatible list. It fixes: meson-g12b-ugoos-am6.dt.yaml: /: compatible: ['ugoos,am6', 'amlogic,g12b'] is not valid under any of the given schemas Signed-off-by: Neil Armstrong Signed-off-by: Kevin Hilman Link: https://lore.kernel.org/r/20200326165958.19274-4-narmstrong@baylibre.com Signed-off-by: Sasha Levin commit b9b43a3a24868dfdea86a963c196920c53f9364c Author: Arnd Bergmann Date: Tue Apr 28 23:46:14 2020 +0200 ASoC: rt5682: fix I2C/Soundwire dependencies [ Upstream commit fd443a20c2f0950f3c31765a08f7dd49b3bc69cb ] If one of the two is a loadable module, the combined driver must not be built-in: aarch64-linux-ld: sound/soc/codecs/rt5682.o: in function `rt5682_sdw_hw_free': rt5682.c:(.text+0xb34): undefined reference to `sdw_stream_remove_slave' aarch64-linux-ld: sound/soc/codecs/rt5682.o: in function `rt5682_sdw_hw_params': rt5682.c:(.text+0xe78): undefined reference to `sdw_stream_add_slave' In particular, the soundwire driver must not be built-in if CONFIG_I2C=m. Fixes: 5549ea647997 ("ASoC: rt5682: fix unmet dependencies") Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20200428214642.3925004-1-arnd@arndb.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 0154d54061efd14093649147b8d941f7d83d6957 Author: Sudip Mukherjee Date: Fri Apr 24 17:19:44 2020 +0100 thermal/drivers/ti-soc-thermal: Avoid dereferencing ERR_PTR [ Upstream commit 7440f518dad9d861d76c64956641eeddd3586f75 ] On error the function ti_bandgap_get_sensor_data() returns the error code in ERR_PTR() but we only checked if the return value is NULL or not. And, so we can dereference an error code inside ERR_PTR. While at it, convert a check to IS_ERR_OR_NULL. Signed-off-by: Sudip Mukherjee Reviewed-by: Amit Kucheria Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/20200424161944.6044-1-sudipm.mukherjee@gmail.com Signed-off-by: Sasha Levin commit 46448b16f046c252fd226c76ee45f5bb1d914ff7 Author: Arnd Bergmann Date: Tue Apr 28 23:47:31 2020 +0200 ASoC: component: suppress uninitialized-variable warning [ Upstream commit be16a0f0dc8fab8e25d9cdbeb4f8f28afc9186d2 ] Old versions of gcc (tested on gcc-4.8) produce a warning for correct code: sound/soc/soc-compress.c: In function 'soc_compr_open': sound/soc/soc-compress.c:75:28: error: 'component' is used uninitialized in this function [-Werror=uninitialized] struct snd_soc_component *component, *save = NULL; Change the for_each_rtd_components() macro to ensure 'component' gets initialized to a value the compiler does not complain about. Signed-off-by: Arnd Bergmann Link: https://lore.kernel.org/r/20200428214754.3925368-1-arnd@arndb.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 081aa3e99e000d3b5ac27e7af11d6d73a6dae51d Author: Uwe Kleine-König Date: Mon Apr 20 20:27:51 2020 +0300 gpio: pca953x: fix handling of automatic address incrementing [ Upstream commit bcf41dc480b179bfb669a232080a2e26dc7294b4 ] Some of the chips supported by the pca953x driver need the most significant bit in the address word set to automatically increment the address pointer on subsequent reads and writes (example: PCA9505). With this bit unset the same register is read multiple times on a multi-byte read sequence. Other chips must not have this bit set and autoincrement always (example: PCA9555). Up to now this AI bit was interpreted to be part of the address, which resulted in inconsistent regmap caching when a register was written with AI set and then read without it. This happened for the PCA9505 in pca953x_gpio_set_multiple() where pca953x_read_regs() bulk read from the cache for registers 0x8-0xc and then wrote to registers 0x88-0x8c. (Side note: reading 5 values from offset 0x8 yiels OP0 5 times because AI must be set to get OP0-OP4, which is another bug that is resolved here as a by-product.) The same problem happens when calls to gpio_set_value() and gpio_set_array_value() were mixed. With this patch the AI bit is always set for chips that support it. This works as there are no code locations that make use of the behaviour with AI unset (for the chips that support it). Note that the call to pca953x_setup_gpio() had to be done a bit earlier to make the NBANK macro work. The history of this bug is a bit complicated. Commit b32cecb46bdc ("gpio: pca953x: Extract the register address mangling to single function") changed which chips and functions are affected. Commit 3b00691cc46a ("gpio: pca953x: hack to fix 24 bit gpio expanders") used some duct tape to make the driver at least appear to work. Commit 49427232764d ("gpio: pca953x: Perform basic regmap conversion") introduced the caching. Commit b4818afeacbd ("gpio: pca953x: Add set_multiple to allow multiple bits to be set in one write.") introduced the .set_multiple() callback which didn't work for chips that need the AI bit which was fixed later for some chips in 8958262af3fb ("gpio: pca953x: Repair multi-byte IO address increment on PCA9575"). So I'm sorry, I don't know which commit I should pick for a Fixes: line. Tested-by: Marcel Gudert Signed-off-by: Uwe Kleine-König Tested-by: Andy Shevchenko Reviewed-by: Andy Shevchenko Signed-off-by: Andy Shevchenko Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 10106d9e51de6abeffe7c3a2f75d052d75768aeb Author: Martin Blumenstingl Date: Fri Apr 17 20:41:26 2020 +0200 clk: meson: meson8b: Fix the vclk_div{1, 2, 4, 6, 12}_en gate bits [ Upstream commit 8bb629cfb28f4dad9d47f69249366e50ae5edc25 ] The DIV{1,2,4,6,12}_EN bits are actually located in HHI_VID_CLK_CNTL register: - HHI_VID_CLK_CNTL[0] = DIV1_EN - HHI_VID_CLK_CNTL[1] = DIV2_EN - HHI_VID_CLK_CNTL[2] = DIV4_EN - HHI_VID_CLK_CNTL[3] = DIV6_EN - HHI_VID_CLK_CNTL[4] = DIV12_EN Update the bits accordingly so we will enable the bits in the correct register once we switch these clocks to be mutable. Fixes: 6cb57c678bb70e ("clk: meson: meson8b: add the read-only video clock trees") Signed-off-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20200417184127.1319871-4-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit 0af8f4c0ae56ae9c83adecbac9b0a1db606c0327 Author: Martin Blumenstingl Date: Fri Apr 17 20:41:25 2020 +0200 clk: meson: meson8b: Fix the polarity of the RESET_N lines [ Upstream commit 0d3051c790ed2ef6bd91b92b07220313f06b95b3 ] CLKC_RESET_VID_DIVIDER_CNTL_RESET_N_POST and CLKC_RESET_VID_DIVIDER_CNTL_RESET_N_PRE are active low. This means: - asserting them requires setting the register value to 0 - de-asserting them requires setting the register value to 1 Set the register value accordingly for these two reset lines by setting the inverted the register value compared to all other reset lines. Fixes: 189621726bc2f6 ("clk: meson: meson8b: register the built-in reset controller") Signed-off-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20200417184127.1319871-3-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit 7a6c60a17d5436da3163a1675bc01d72cb4e94e3 Author: Martin Blumenstingl Date: Fri Apr 17 20:41:24 2020 +0200 clk: meson: meson8b: Fix the first parent of vid_pll_in_sel [ Upstream commit da1978ac3d6cf278dedf5edbf350445a0fff2f08 ] Use hdmi_pll_lvds_out as parent of the vid_pll_in_sel clock. It's not easy to see that the vendor kernel does the same, but it actually does. meson_clk_pll_ops in mainline still cannot fully recalculate all rates from the HDMI PLL registers because some register bits (at the time of writing it's unknown which bits are used for this) double the HDMI PLL output rate (compared to simply considering M, N and FRAC) for some (but not all) PLL settings. Update the vid_pll_in_sel parent so our clock calculation works for simple clock settings like the CVBS output (where no rate doubling is going on). The PLL ops need to be fixed later on for more complex clock settings (all HDMI rates). Fixes: 6cb57c678bb70 ("clk: meson: meson8b: add the read-only video clock trees") Suggested-by: Neil Armstrong Signed-off-by: Martin Blumenstingl Signed-off-by: Jerome Brunet Link: https://lore.kernel.org/r/20200417184127.1319871-2-martin.blumenstingl@googlemail.com Signed-off-by: Sasha Levin commit 20aeada72fc3bf1e88d1f91c6e8d8a5837c2c6d7 Author: Nicolas Saenz Julienne Date: Mon Apr 20 14:01:02 2020 +0200 of: property: Do not link to disabled devices [ Upstream commit 7456427af9def0fec5508dd8b861556038ee96a8 ] When creating a consumer/supplier relationship between two devices, make sure the supplier node is actually active. Otherwise this will create a link relationship that will never be fulfilled. This, in the worst case scenario, will hang the system during boot. Note that, in practice, the fact that a device-tree represented consumer/supplier relationship isn't fulfilled will not prevent devices from successfully probing. Fixes: a3e1d1a7f5fc ("of: property: Add functional dependency link from DT bindings") Signed-off-by: Nicolas Saenz Julienne Reviewed-by: Saravana Kannan Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit e58c0f4bed26e7041d8fc475e063f58d64324297 Author: Nicolas Saenz Julienne Date: Mon Apr 20 14:01:01 2020 +0200 of: property: Fix create device links for all child-supplier dependencies [ Upstream commit ed3655729182a59b9bef1b564c6fc2dcbbbe954e ] Upon adding a new device from a DT node, we scan its properties and its children's properties in order to create a consumer/supplier relationship between the device and the property provider. That said, it's possible for some of the node's children to be disabled, which will create links that'll never be fulfilled. To get around this, use the for_each_available_child_of_node() function instead of for_each_available_node() when iterating over the node's children. Fixes: d4387cd11741 ("of: property: Create device links for all child-supplier depencencies") Signed-off-by: Nicolas Saenz Julienne Reviewed-by: Saravana Kannan Signed-off-by: Rob Herring Signed-off-by: Sasha Levin commit 95298fff3b1e716732d853e62ec911727bd529e3 Author: Wei Yongjun Date: Mon Apr 27 11:08:29 2020 +0000 gpio: mlxbf2: fix return value check in mlxbf2_gpio_get_lock_res() [ Upstream commit 66d8ad67aab3bc6f55e7de81565cd0d4875bd851 ] In case of error, the function devm_ioremap() returns NULL pointer not ERR_PTR(). The IS_ERR() test in the return value check should be replaced with NULL test. Signed-off-by: Wei Yongjun Link: https://lore.kernel.org/r/20200427110829.154785-1-weiyongjun1@huawei.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 94364e0304ff8f74db0c55d2769a6a5389730b0b Author: Srinivas Kandagatla Date: Fri Apr 17 10:36:18 2020 +0100 slimbus: ngd: get drvdata from correct device [ Upstream commit b58c663059b484f7ff547d076a34cf6d7a302e56 ] Get drvdata directly from parent instead of ngd dev, as ngd dev can probe defer and previously set drvdata will become null. Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20200417093618.7929-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a9513e60f9b5c1cac09fd8d204ad7849740910bd Author: Raghavendra Rao Ananta Date: Mon Apr 27 20:26:01 2020 -0700 tty: hvc: Fix data abort due to race in hvc_open [ Upstream commit e2bd1dcbe1aa34ff5570b3427c530e4332ecf0fe ] Potentially, hvc_open() can be called in parallel when two tasks calls open() on /dev/hvcX. In such a scenario, if the hp->ops->notifier_add() callback in the function fails, where it sets the tty->driver_data to NULL, the parallel hvc_open() can see this NULL and cause a memory abort. Hence, serialize hvc_open and check if tty->private_data is NULL before proceeding ahead. The issue can be easily reproduced by launching two tasks simultaneously that does nothing but open() and close() on /dev/hvcX. For example: $ ./simple_open_close /dev/hvc0 & ./simple_open_close /dev/hvc0 & Signed-off-by: Raghavendra Rao Ananta Link: https://lore.kernel.org/r/20200428032601.22127-1-rananta@codeaurora.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 859cae6f4da8070cdd1a84d0744d378902e34f19 Author: Jérôme Pouiller Date: Mon Apr 27 15:40:25 2020 +0200 staging: wfx: fix double init of tx_policy_upload_work [ Upstream commit 6ae0878b4800c7042d35c0fb4c6baabb62621ecc ] The work_struct tx_policy_upload_work was initialized twice. Fixes: 99879121bfbb ("staging: wfx: fix the cache of rate policies on interface reset") Signed-off-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20200427134031.323403-12-Jerome.Pouiller@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 79ae4a658a4a0a6f4a0562eb52973c2850202b99 Author: Jérôme Pouiller Date: Mon Apr 27 15:40:23 2020 +0200 staging: wfx: fix overflow in frame counters [ Upstream commit 87066173e34b0ca5d041d5519e6bb030b1958184 ] It has been reported that trying to send small packets of data could produce a "inconsistent notification" warning. It seems that in some circumstances, the number of frame queued in the driver could greatly increase and exceed UCHAR_MAX. So the field "buffered" from struct sta_priv can overflow. Just increase the size of "bueffered" to fix the problem. Fixes: 7d2d2bfdeb82 ("staging: wfx: relocate "buffered" information to sta_priv") Signed-off-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20200427134031.323403-10-Jerome.Pouiller@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 854a04f82c792a4eb72caba3b181e08095d3d47e Author: Julian Wiedmann Date: Thu Apr 9 09:59:39 2020 +0200 s390/qdio: put thinint indicator after early error [ Upstream commit 75e82bec6b2622c6f455b7a543fb5476a5d0eed7 ] qdio_establish() calls qdio_setup_thinint() via qdio_setup_irq(). If the subsequent qdio_establish_thinint() fails, we miss to put the DSCI again. Thus the DSCI isn't available for re-use. Given enough of such errors, we could end up with having only the shared DSCI available. Merge qdio_setup_thinint() into qdio_establish_thinint(), and deal with such an error internally. Fixes: 779e6e1c724d ("[S390] qdio: new qdio driver.") Signed-off-by: Julian Wiedmann Reviewed-by: Benjamin Block Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 42d6c5a750b2bd2501a9bdeaadd4010b09e3e0a3 Author: Julian Wiedmann Date: Thu Apr 9 09:55:05 2020 +0200 s390/qdio: tear down thinint indicator after early error [ Upstream commit 68a381746f20e5435206173e22d0a011ef78790e ] qdio_establish() calls qdio_establish_thinint(), but later has an error exit path that doesn't roll this call back. Fix it. Fixes: 779e6e1c724d ("[S390] qdio: new qdio driver.") Signed-off-by: Julian Wiedmann Reviewed-by: Benjamin Block Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit a4482984c41f5cc1d217aa189fe51bbbc0500f98 Author: Julian Wiedmann Date: Thu Apr 9 10:55:16 2020 +0200 s390/qdio: consistently restore the IRQ handler [ Upstream commit 7b942b4be971d49cb185ce4690d7fbf94636e88a ] For rolling back after an error, qdio_establish() calls qdio_shutdown(). If the error occurs early enough, then the qdio_irq's state still is QDIO_IRQ_STATE_INACTIVE and qdio_shutdown() does nothing. But at _any_ point where qdio_establish() bails out in this way, qdio_setup_irq() will have already replaced the IRQ handler. This then won't be restored after an early error, and the device can end up being returned to the device driver with qdio's IRQ handler still installed. Slightly reorder qdio_setup_irq() so we can be 100% sure that the IRQ handler was replaced. Then fix the bug in qdio_establish() by calling a helper that rolls back only the IRQ handler modification. Also use the new helper in qdio_shutdown() to keep things in sync, and slightly clean up the locking while doing so. This makes minor semantical changes, but holding setup_mutex gives us sufficient leeway to eg. pull qdio_shutdown_thinint() outside of the ccwdev lock's scope. Fixes: 779e6e1c724d ("[S390] qdio: new qdio driver.") Signed-off-by: Julian Wiedmann Reviewed-by: Benjamin Block Signed-off-by: Vasily Gorbik Signed-off-by: Sasha Levin commit 3b690b5447452c363cbab7daee1c69903b63afa0 Author: Takashi Iwai Date: Fri Apr 24 09:40:16 2020 +0200 ALSA: usb-audio: Fix racy list management in output queue [ Upstream commit 5b6cc38f3f3f37109ce72b60bda215a5f6892c0b ] The linked list entry from FIFO is peeked at queue_pending_output_urbs() but the actual element pop-out is performed outside the spinlock, and it's potentially racy. Do delete the link at the right place inside the spinlock. Fixes: 8fdff6a319e7 ("ALSA: snd-usb: implement new endpoint streaming model") Link: https://lore.kernel.org/r/20200424074016.14301-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit d288dc74f8cf95cb7ae0aaf245b7128627a49bf3 Author: Alexander Tsoy Date: Fri Apr 24 05:24:48 2020 +0300 ALSA: usb-audio: Improve frames size computation [ Upstream commit f0bd62b64016508938df9babe47f65c2c727d25c ] For computation of the the next frame size current value of fs/fps and accumulated fractional parts of fs/fps are used, where values are stored in Q16.16 format. This is quite natural for computing frame size for asynchronous endpoints driven by explicit feedback, since in this case fs/fps is a value provided by the feedback endpoint and it's already in the Q format. If an error is accumulated over time, the device can adjust fs/fps value to prevent buffer overruns/underruns. But for synchronous endpoints the accuracy provided by these computations is not enough. Due to accumulated error the driver periodically produces frames with incorrect size (+/- 1 audio sample). This patch fixes this issue by implementing a different algorithm for frame size computation. It is based on accumulating of the remainders from division fs/fps and it doesn't accumulate errors over time. This new method is enabled for synchronous and adaptive playback endpoints. Signed-off-by: Alexander Tsoy Link: https://lore.kernel.org/r/20200424022449.14972-1-alexander@tsoy.me Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 85b103f674d40ec916a2f5b264fb22427ff9372e Author: Xiyu Yang Date: Thu Apr 23 13:15:40 2020 +0800 staging: gasket: Fix mapping refcnt leak when register/store fails [ Upstream commit e3436ce60cf5f5eaedda2b8c622f69feb97595e2 ] gasket_sysfs_register_store() invokes get_mapping(), which returns a reference of the specified gasket_sysfs_mapping object to "mapping" with increased refcnt. When gasket_sysfs_register_store() returns, local variable "mapping" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of gasket_sysfs_register_store(). When gasket_dev is NULL, the function forgets to decrease the refcnt increased by get_mapping(), causing a refcnt leak. Fix this issue by calling put_mapping() when gasket_dev is NULL. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Link: https://lore.kernel.org/r/1587618941-13718-1-git-send-email-xiyuyang19@fudan.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 767032ffa2957d240ab53b17625fe6ab2a180b62 Author: Xiyu Yang Date: Thu Apr 23 13:14:55 2020 +0800 staging: gasket: Fix mapping refcnt leak when put attribute fails [ Upstream commit 57a66838e1494cd881b7f4e110ec685736e8e3ca ] gasket_sysfs_put_attr() invokes get_mapping(), which returns a reference of the specified gasket_sysfs_mapping object to "mapping" with increased refcnt. When gasket_sysfs_put_attr() returns, local variable "mapping" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one path of gasket_sysfs_put_attr(). When mapping attribute is unknown, the function forgets to decrease the refcnt increased by get_mapping(), causing a refcnt leak. Fix this issue by calling put_mapping() when put attribute fails due to unknown attribute. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Link: https://lore.kernel.org/r/1587618895-13660-1-git-send-email-xiyuyang19@fudan.edu.cn Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit f80cc7666b2bf9197d4521b9b737bec73aee010d Author: Bjorn Andersson Date: Tue Apr 14 22:47:03 2020 -0700 arm64: dts: qcom: sm8250: Fix PDC compatible and reg [ Upstream commit 240031967ac4c63713c6e0c3249d734e23c913aa ] The pdc node suffers from both too narrow compatible and insufficient cells in the reg, fix these. Fixes: 60378f1a171e ("arm64: dts: qcom: sm8250: Add sm8250 dts file") Tested-by: Vinod Koul Reviewed-by: Vinod Koul Link: https://lore.kernel.org/r/20200415054703.739507-1-bjorn.andersson@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 91194193523c4f7384daaf43fbe6b9cd3f4e7662 Author: Christoph Hellwig Date: Tue Apr 14 14:31:36 2020 +0200 firmware: qcom_scm: fix bogous abuse of dma-direct internals [ Upstream commit 459b1f86f1cba7de813fbc335df476c111feec22 ] As far as the device is concerned the dma address is the physical address. There is no need to convert it to a physical address, especially not using dma-direct internals that are not available to drivers and which will interact badly with IOMMUs. Last but not least the commit introducing it claimed to just fix a type issue, but actually changed behavior. Fixes: 6e37ccf78a532 ("firmware: qcom_scm: Use proper types for dma mappings") Reviewed-by: Bjorn Andersson Signed-off-by: Christoph Hellwig Link: https://lore.kernel.org/r/20200414123136.441454-1-hch@lst.de Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 2a697883387dbadb0cff7eaf3170b21055db2d95 Author: Jonathan Marek Date: Mon Apr 20 11:35:43 2020 -0400 arm64: dts: qcom: fix pm8150 gpio interrupts [ Upstream commit 61d2ca503d0b55d2849fd656ce51d8e1e9ba0b6c ] This was mistakenly copied from the downstream dts, however the upstream driver works differently. I only tested this with the pm8150_gpios node (used with volume button), but the 2 others should be the same. Fixes: e92b61c8e775 ("arm64: dts: qcom: pm8150l: Add base dts file") Fixes: 229d5bcad0d0 ("arm64: dts: qcom: pm8150b: Add base dts file") Fixes: 5101f22a5c37 ("arm64: dts: qcom: pm8150: Add base dts file") Reviewed-by: Bjorn Andersson Signed-off-by: Jonathan Marek Link: https://lore.kernel.org/r/20200420153543.14512-1-jonathan@marek.ca Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 12770809fc02b6f6e038234a4ae5947710d8154c Author: Vasily Averin Date: Mon Aug 19 09:53:50 2019 +0300 fuse: BUG_ON correction in fuse_dev_splice_write() [ Upstream commit 0e9fb6f17ad5b386b75451328975a07d7d953c6d ] commit 963545357202 ("fuse: reduce allocation size for splice_write") changed size of bufs array, so BUG_ON which checks the index of the array shold also be fixed. [SzM: turn BUG_ON into WARN_ON] Fixes: 963545357202 ("fuse: reduce allocation size for splice_write") Signed-off-by: Vasily Averin Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit e4d94478e2d786d0ad2b1fafd170d3d65d9105b6 Author: Vivek Goyal Date: Mon Apr 20 17:01:34 2020 +0200 virtiofs: schedule blocking async replies in separate worker [ Upstream commit bb737bbe48bea9854455cb61ea1dc06e92ce586c ] In virtiofs (unlike in regular fuse) processing of async replies is serialized. This can result in a deadlock in rare corner cases when there's a circular dependency between the completion of two or more async replies. Such a deadlock can be reproduced with xfstests:generic/503 if TEST_DIR == SCRATCH_MNT (which is a misconfiguration): - Process A is waiting for page lock in worker thread context and blocked (virtio_fs_requests_done_work()). - Process B is holding page lock and waiting for pending writes to finish (fuse_wait_on_page_writeback()). - Write requests are waiting in virtqueue and can't complete because worker thread is blocked on page lock (process A). Fix this by creating a unique work_struct for each async reply that can block (O_DIRECT read). Fixes: a62a8ef9d97d ("virtio-fs: add virtiofs filesystem") Signed-off-by: Vivek Goyal Signed-off-by: Miklos Szeredi Signed-off-by: Sasha Levin commit 8c1027c3ee0bbfcbe99a867228658b70a7c6fa40 Author: Jason Yan Date: Fri Apr 17 19:16:04 2020 +0800 pinctrl: rza1: Fix wrong array assignment of rza1l_swio_entries [ Upstream commit 4b4e8e93eccc2abc4209fe226ec89e7fbe9f3c61 ] The rza1l_swio_entries referred to the wrong array rza1h_swio_pins, which was intended to be rza1l_swio_pins. So let's fix it. This is detected by the following gcc warning: drivers/pinctrl/pinctrl-rza1.c:401:35: warning: ‘rza1l_swio_pins’ defined but not used [-Wunused-const-variable=] static const struct rza1_swio_pin rza1l_swio_pins[] = { ^~~~~~~~~~~~~~~ Fixes: 039bc58e73b77723 ("pinctrl: rza1: Add support for RZ/A1L") Reported-by: Hulk Robot Signed-off-by: Jason Yan Link: https://lore.kernel.org/r/20200417111604.19143-1-yanaijie@huawei.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 913a24388a8252bf5bf2aca6c29ec15115bf1496 Author: Alexandru Ardelean Date: Tue Mar 24 15:46:31 2020 +0200 iio: buffer-dmaengine: use %zu specifier for sprintf(align) [ Upstream commit 6eb3b8acfd079104571c207d4524743b6acc6550 ] The 'size_t' type behaves differently on 64-bit architectures, and causes compiler a warning of the sort "format '%u' expects argument of type 'unsigned int', but argument 3 has type 'size_t {aka long unsigned int}'". This change adds the correct specifier for the 'align' field. Fixes: 4538c18568099 ("iio: buffer-dmaengine: Report buffer length requirements") Reported-by: kbuild test robot Signed-off-by: Alexandru Ardelean Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 0cc5b8ed5acd8372b3d79fbca4ab33c97b8d7089 Author: Chad Dupuis Date: Thu Apr 16 01:43:13 2020 -0700 scsi: qedf: Fix crash when MFW calls for protocol stats while function is still probing [ Upstream commit ad40f5256095c68dc17c991eb976261d5ea2daaa ] The MFW may make a call to qed and then to qedf for protocol statistics while the function is still probing. If this happens it's possible that some members of the struct qedf_ctx may not be fully initialized which can result in a NULL pointer dereference or general protection fault. To prevent this, add a new flag call QEDF_PROBING and set it when the __qedf_probe() function is active. Then in the qedf_get_protocol_tlv_data() function we can check if the function is still probing and return immediantely before any uninitialized structures can be touched. Link: https://lore.kernel.org/r/20200416084314.18851-9-skashyap@marvell.com Signed-off-by: Chad Dupuis Signed-off-by: Saurav Kashyap Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 888f9d73bfde50c370b32664f3e49635e167b88d Author: Andy Shevchenko Date: Wed Apr 15 17:15:21 2020 +0300 gpio: dwapb: Append MODULE_ALIAS for platform driver [ Upstream commit c58220cba2e03618659fa7d5dfae31f5ad4ae9d0 ] The commit 3d2613c4289f ("GPIO: gpio-dwapb: Enable platform driver binding to MFD driver") introduced a use of the platform driver but missed to add the following line to it: MODULE_ALIAS("platform:gpio-dwapb"); Add this to get driver loaded automatically if platform device is registered. Fixes: 3d2613c4289f ("GPIO: gpio-dwapb: Enable platform driver binding to MFD driver") Signed-off-by: Andy Shevchenko Tested-by: Serge Semin Reviewed-by: Serge Semin Link: https://lore.kernel.org/r/20200415141534.31240-2-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit b89676ac370c62b8be94f566d01e06794dd1f5f2 Author: Thomas Ebeling Date: Tue Apr 14 23:10:29 2020 +0200 ALSA: usb-audio: RME Babyface Pro mixer patch [ Upstream commit 3e8f3bd047163d30fb1ad32ca7e4628921555c09 ] Added mixer quirks to allow controlling the internal DSP of the RME Babyface Pro and its successor Babyface Pro FS. Signed-off-by: Thomas Ebeling Link: https://lore.kernel.org/r/20200414211019.qprg7whepg2y7nei@bollie.ca9.eu Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit eceffa4849432dd3fb3b5eb281bebe1ea8175040 Author: Yishai Hadas Date: Mon Apr 6 20:35:40 2020 +0300 RDMA/mlx5: Fix udata response upon SRQ creation [ Upstream commit cf26deff9036cd3270af562dbec545239e5c7f07 ] Fix udata response upon SRQ creation to use the UAPI structure (i.e. mlx5_ib_create_srq_resp). It did not zero the reserved field in userspace. Fixes: e126ba97dba9 ("mlx5: Add driver for Mellanox Connect-IB adapters") Link: https://lore.kernel.org/r/20200406173540.1466477-1-leon@kernel.org Signed-off-by: Yishai Hadas Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 083718e00df2e4af741d812116d1f3161e1db05b Author: Vincent Stehlé Date: Sat Apr 11 19:48:43 2020 +0200 ARM: dts: sun8i-h2-plus-bananapi-m2-zero: Fix led polarity [ Upstream commit 34b6826df7462c541752cf8b1de2691b26d78ae0 ] The PWR-LED on the bananapi m2 zero board is on when gpio PL10 is low. This has been verified on a board and in the schematics [1]. [1]: http://wiki.banana-pi.org/Banana_Pi_BPI-M2_ZERO#Documents Fixes: 8b8061fcbfae ("ARM: dts: sun8i: h2+: add support for Banana Pi M2 Zero board") Signed-off-by: Vincent Stehlé Cc: Icenowy Zheng Cc: Maxime Ripard Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 4b114a67ab0d12d66f9e2a864ec2131885f60d05 Author: Amit Kucheria Date: Mon Mar 30 15:36:26 2020 +0530 arm64: dts: qcom: msm8916: remove unit name for thermal trip points [ Upstream commit fe2aff0c574d206f34f1864d5a0b093694c27142 ] The thermal trip points have unit name but no reg property, so we can remove them. It also fixes the following warnings from 'make dtbs_check' after adding the thermal yaml bindings. arch/arm64/boot/dts/qcom/apq8016-sbc.dt.yaml: thermal-zones: gpu-thermal:trips: 'trip-point@0' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$', 'pinctrl-[0-9]+' arch/arm64/boot/dts/qcom/apq8016-sbc.dt.yaml: thermal-zones: camera-thermal:trips: 'trip-point@0' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$', 'pinctrl-[0-9]+' arch/arm64/boot/dts/qcom/apq8016-sbc.dt.yaml: thermal-zones: modem-thermal:trips: 'trip-point@0' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$', 'pinctrl-[0-9]+' arch/arm64/boot/dts/qcom/msm8916-mtp.dt.yaml: thermal-zones: gpu-thermal:trips: 'trip-point@0' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$', 'pinctrl-[0-9]+' arch/arm64/boot/dts/qcom/msm8916-mtp.dt.yaml: thermal-zones: camera-thermal:trips: 'trip-point@0' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$', 'pinctrl-[0-9]+' arch/arm64/boot/dts/qcom/msm8916-mtp.dt.yaml: thermal-zones: modem-thermal:trips: 'trip-point@0' does not match any of the regexes: '^[a-zA-Z][a-zA-Z0-9\\-_]{0,63}$', 'pinctrl-[0-9]+' Signed-off-by: Amit Kucheria Link: https://lore.kernel.org/r/2d3d045c18a2fb85b28cf304aa11ae6e6538d75e.1585562459.git.amit.kucheria@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit cb0eac511f2c4af8e36816060e0547493dd078a5 Author: Nilesh Javali Date: Tue Apr 7 23:43:30 2020 -0700 scsi: qedi: Do not flush offload work if ARP not resolved [ Upstream commit 927527aea0e2a9c1d336c7d33f77f1911481d008 ] For an unreachable target, offload_work is not initialized and the endpoint state is set to OFLDCONN_NONE. This results in a WARN_ON due to the check of the work function field being set to zero. ------------[ cut here ]------------ WARNING: CPU: 24 PID: 18587 at ../kernel/workqueue.c:3037 __flush_work+0x1c1/0x1d0 : Hardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 02/01/2020 RIP: 0010:__flush_work+0x1c1/0x1d0 Code: ba 6d 00 03 80 c9 f0 eb b6 48 c7 c7 20 ee 6c a4 e8 52 d3 04 00 0f 0b 31 c0 e9 d1 fe ff ff 48 c7 c7 20 ee 6c a4 e8 3d d3 04 00 <0f> 0b 31 c0 e9 bc fe ff ff e8 11 f3 f 00 31 f6 RSP: 0018:ffffac5a8cd47a80 EFLAGS: 00010282 RAX: 0000000000000024 RBX: ffff98d68c1fcaf0 RCX: 0000000000000000 RDX: 0000000000000000 RSI: ffff98ce9fd99898 RDI: ffff98ce9fd99898 RBP: ffff98d68c1fcbc0 R08: 00000000000006fa R09: 0000000000000001 R10: ffffac5a8cd47b50 R11: 0000000000000001 R12: 0000000000000000 R13: 000000000000489b R14: ffff98d68c1fc800 R15: ffff98d692132c00 FS: 00007f65f7f62280(0000) GS:ffff98ce9fd80000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007ffd2435e880 CR3: 0000000809334003 CR4: 00000000007606e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: ? class_create_release+0x40/0x40 ? klist_put+0x2c/0x80 qedi_ep_disconnect+0xdd/0x400 [qedi] iscsi_if_ep_disconnect.isra.20+0x59/0x70 [scsi_transport_iscsi] iscsi_if_rx+0x129b/0x1670 [scsi_transport_iscsi] ? __netlink_lookup+0xe7/0x160 netlink_unicast+0x21d/0x300 netlink_sendmsg+0x30f/0x430 sock_sendmsg+0x5b/0x60 ____sys_sendmsg+0x1e2/0x240 ? copy_msghdr_from_user+0xd9/0x160 ___sys_sendmsg+0x88/0xd0 ? ___sys_recvmsg+0xa2/0xe0 ? hrtimer_try_to_cancel+0x25/0x100 ? do_nanosleep+0x9c/0x170 ? __sys_sendmsg+0x5e/0xa0 __sys_sendmsg+0x5e/0xa0 do_syscall_64+0x60/0x1f0 entry_SYSCALL_64_after_hwframe+0x49/0xbe RIP: 0033:0x7f65f6f16107 Code: 64 89 02 48 c7 c0 ff ff ff ff eb b9 0f 1f 80 00 00 00 00 8b 05 aa d2 2b 00 48 63 d2 48 63 ff 85 c0 75 18 b8 2e 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 59 f3 c3 0f 1f 8 0 00 00 00 00 53 48 89 f3 48 RSP: 002b:00007ffd24367ca8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e RAX: ffffffffffffffda RBX: 000055a7aeaaf110 RCX: 00007f65f6f16107 RDX: 0000000000000000 RSI: 00007ffd24367cc0 RDI: 0000000000000003 RBP: 0000000000000070 R08: 0000000000000000 R09: 0000000000000000 R10: 000000000000075c R11: 0000000000000246 R12: 00007ffd24367cc0 R13: 000055a7ae560008 R14: 00007ffd24367db0 R15: 0000000000000000 ---[ end trace 54f499c05d41f8bb ]--- Only flush if the connection endpoint state if different from OFLDCONN_NONE. [mkp: clarified commit desc] Link: https://lore.kernel.org/r/20200408064332.19377-5-mrangankar@marvell.com Reviewed-by: Lee Duncan Signed-off-by: Nilesh Javali Signed-off-by: Manish Rangankar Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit bfac30fd2c660ff0aa458365163062898e74e9ba Author: Hsin-Yi Wang Date: Mon Feb 10 14:35:22 2020 +0800 arm64: dts: mt8173: fix unit name warnings [ Upstream commit 72b29215aced394d01ca25e432963b619daa0098 ] Fixing several unit name warnings: Warning (unit_address_vs_reg): /oscillator@0: node has a unit name, but no reg property Warning (unit_address_vs_reg): /oscillator@1: node has a unit name, but no reg property Warning (unit_address_vs_reg): /oscillator@2: node has a unit name, but no reg property Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/trips/trip-point@0: node has a unit name, but no reg property Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/trips/trip-point@1: node has a unit name, but no reg property Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/trips/cpu_crit@0: node has a unit name, but no reg property Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/cooling-maps/map@0: node has a unit name, but no reg property Warning (unit_address_vs_reg): /thermal-zones/cpu_thermal/cooling-maps/map@1: node has a unit name, but no reg property Warning (unit_address_vs_reg): /reserved-memory/vpu_dma_mem_region: node has a reg or ranges property, but no unit name Warning (simple_bus_reg): /soc/pinctrl@10005000: simple-bus unit address format error, expected "1000b000" Warning (simple_bus_reg): /soc/interrupt-controller@10220000: simple-bus unit address format error, expected "10221000" Signed-off-by: Hsin-Yi Wang Link: https://lore.kernel.org/r/20200210063523.133333-4-hsinyi@chromium.org [mb: drop fixes for '_' in property name] Signed-off-by: Matthias Brugger Signed-off-by: Sasha Levin commit c71a84a0449d42b8b1f6c33980de671a670a1a0d Author: Sergio Paracuellos Date: Mon Apr 13 07:59:42 2020 +0200 staging: mt7621-pci: fix PCIe interrupt mapping [ Upstream commit fab6710e4c51f4eb622f95a08322ab5fdbe3f295 ] MT7621 has three assigned interrupts for the pcie. This interrupts should properly being mapped taking into account which devices are finally connected in which bus according to link status. So the irq mappings should be as follows according to link status (three bits indicating which devices are link up): * For PCIe Bus 1 slot 0: - status = 0x2 || status = 0x6 => IRQ = pcie1_irq (24). - status = 0x4 => IRQ = pcie2_irq (25). - default => IRQ = pcie0_irq (23). * For PCIe Bus 2 slot 0: - status = 0x5 || status = 0x6 => IRQ = pcie2_irq (25). - default => IRQ = pcie1_irq (24). * For PCIe Bus 2 slot 1: - status = 0x5 || status = 0x6 => IRQ = pcie2_irq (25). - default => IRQ = pcie1_irq (24). * For PCIe Bus 3 any slot: - default => IRQ = pcie2_irq (25). Because of this, the function 'of_irq_parse_and_map_pci' cannot be used and we need to change device tree information from using the 'interrupt-map' and 'interrupt-map-mask' properties into an 'interrupts' property to be able to get irq information from the ports using the 'platform_get_irq' and storing an 'irq-map' into the pcie driver data node to properly map correct irq using a new 'mt7621_map_irq' function where this map will be read and the correct irq returned. Fixes: 46d093124df4 ("staging: mt7621-pci: improve interrupt mapping") Signed-off-by: Sergio Paracuellos Link: https://lore.kernel.org/r/20200413055942.2714-1-sergio.paracuellos@gmail.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit e1133d1506497fa3fddc9bab5338a754433c4ca9 Author: Chen Zhou Date: Wed Apr 1 11:00:17 2020 +0800 staging: greybus: fix a missing-check bug in gb_lights_light_config() [ Upstream commit 9bb086e5ba9495ac150fbbcc5c8c2bccc06261dd ] In gb_lights_light_config(), 'light->name' is allocated by kstrndup(). It returns NULL when fails, add check for it. Signed-off-by: Chen Zhou Acked-by: Rui Miguel Silva Link: https://lore.kernel.org/r/20200401030017.100274-1-chenzhou10@huawei.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 5edf39c0896a88aa15fce6ed120288ccc495beb7 Author: Andreas Färber Date: Mon Nov 11 03:00:26 2019 +0100 arm64: dts: realtek: rtd129x: Fix GIC CPU masks for RTD1293 [ Upstream commit 31888c8be1486daf2c34ba6c58129635e49d564a ] Convert from GIC_CPU_MASK_RAW() to GIC_CPU_MASK_SIMPLE(). In case of RTD1293 adjust the arch timer and VGIC interrupts' CPU masks to its smaller number of CPUs. Fixes: cf976f660ee8 ("arm64: dts: realtek: Add RTD1293 and Synology DS418j") Signed-off-by: Andreas Färber Signed-off-by: Sasha Levin commit 109656715499e718e5829447a1d0b600541ba322 Author: Nicolas Saenz Julienne Date: Tue Mar 3 18:32:16 2020 +0100 ARM: dts: bcm283x: Use firmware PM driver for V3D [ Upstream commit 3ac395a5b3f3b678663fbb58381fdae2b1b57588 ] The register based driver turned out to be unstable, specially on RPi3a+ but not limited to it. While a fix is being worked on, we roll back to using firmware based scheme. Fixes: e1dc2b2e1bef ("ARM: bcm283x: Switch V3D over to using the PM driver instead of firmware") Signed-off-by: Nicolas Saenz Julienne Tested-by: Stefan Wahren Link: https://lore.kernel.org/r/20200303173217.3987-1-nsaenzjulienne@suse.de Signed-off-by: Sasha Levin commit b6626b9bd31c4aaeb32da02edc38018d74fc6914 Author: Hans de Goede Date: Tue Mar 17 14:08:40 2020 +0100 x86/purgatory: Disable various profiling and sanitizing options [ Upstream commit e2ac07c06058ae2d58b45bbf2a2a352771d76fcb ] Since the purgatory is a special stand-alone binary, various profiling and sanitizing options must be disabled. Having these options enabled typically will cause dependencies on various special symbols exported by special libs / stubs used by these frameworks. Since the purgatory is special, it is not linked against these stubs causing missing symbols in the purgatory if these options are not disabled. Sync the set of disabled profiling and sanitizing options with that from drivers/firmware/efi/libstub/Makefile, adding -DDISABLE_BRANCH_PROFILING to the CFLAGS and setting: GCOV_PROFILE := n UBSAN_SANITIZE := n This fixes broken references to ftrace_likely_update() when CONFIG_TRACE_BRANCH_PROFILING is enabled and to __gcov_init() and __gcov_exit() when CONFIG_GCOV_KERNEL is enabled. Signed-off-by: Hans de Goede Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20200317130841.290418-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit e76f91930b8a61ab6323a56dcd6eecd6bf070b8c Author: John Johansen Date: Wed Sep 25 08:02:48 2019 -0700 apparmor: fix nnp subset test for unconfined [ Upstream commit 3ed4aaa94fc07db3cd0c91be95e3e1b9782a2710 ] The subset test is not taking into account the unconfined exception which will cause profile transitions in the stacked confinement case to fail when no_new_privs is applied. This fixes a regression introduced in the fix for https://bugs.launchpad.net/bugs/1839037 BugLink: https://bugs.launchpad.net/bugs/1844186 Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 5cc720f10234d456ad3273912415d928647c681d Author: Sabrina Dubroca Date: Wed Jun 10 12:19:43 2020 +0200 bpf: tcp: Recv() should return 0 when the peer socket is closed [ Upstream commit 2c7269b231194aae23fb90ab65842573a91acbc9 ] If the peer is closed, we will never get more data, so tcp_bpf_wait_data will get stuck forever. In case we passed MSG_DONTWAIT to recv(), we get EAGAIN but we should actually get 0. >From man 2 recv: RETURN VALUE When a stream socket peer has performed an orderly shutdown, the return value will be 0 (the traditional "end-of-file" return). This patch makes tcp_bpf_wait_data always return 1 when the peer socket has been shutdown. Either we have data available, and it would have returned 1 anyway, or there isn't, in which case we'll call tcp_recvmsg which does the right thing in this situation. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Sabrina Dubroca Signed-off-by: Alexei Starovoitov Acked-by: Jakub Sitnicki Link: https://lore.kernel.org/bpf/26038a28c21fea5d04d4bd4744c5686d3f2e5504.1591784177.git.sd@queasysnail.net Signed-off-by: Sasha Levin commit 7028ba6cfd0ae27bf172023f145115b1823ce540 Author: Thomas Falcon Date: Fri Jun 12 13:34:41 2020 -0500 ibmvnic: Flush existing work items before device removal [ Upstream commit 6954a9e4192b86d778fb52b525fd7b62d51b1147 ] Ensure that all scheduled work items have completed before continuing with device removal and after further event scheduling has been halted. This patch fixes a bug where a scheduled driver reset event is processed following device removal. Signed-off-by: Thomas Falcon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8944878343bba65e74768d2efcd312fac059b33b Author: Jonas Karlman Date: Wed May 27 00:25:15 2020 +0200 media: v4l2-ctrls: Unset correct HEVC loop filter flag [ Upstream commit 88441917dc6cd995cb993df603e264f5b88be50c ] Wrong loop filter flag is unset when tiles enabled flag is not set, this cause HEVC decoding issues with Rockchip Video Decoder. Fix this by unsetting the loop filter across tiles enabled flag instead of the pps loop filter across slices enabled flag when tiles are disabled. Fixes: 256fa3920874 ("media: v4l: Add definitions for HEVC stateless decoding") Signed-off-by: Jonas Karlman Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit b657fc29d0ef4f145dd1ef3573954af9244614e8 Author: Marek Szyprowski Date: Thu May 28 16:03:26 2020 +0200 media: s5p-mfc: Properly handle dma_parms for the allocated devices [ Upstream commit cc8c0363ddce6308168d8223378ca884c213f280 ] Commit 9495b7e92f71 ("driver core: platform: Initialize dma_parms for platform devices") in v5.7-rc5 added allocation of dma_parms structure to all platform devices. Then vb2_dma_contig_set_max_seg_size() have been changed not to allocate dma_parms structure and rely on the one allocated by the device core. Lets allocate the needed structure also for the devices created for the 2 MFC device memory ports. Reported-by: Tomi Valkeinen Suggested-by: Ulf Hansson Fixes: 9495b7e92f71 ("driver core: platform: Initialize dma_parms for platform devices") Signed-off-by: Marek Szyprowski Reviewed-by: Ulf Hansson Signed-off-by: Hans Verkuil Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin commit 2718045ece04c8172719dee65a321e1626c42f63 Author: Tyrel Datwyler Date: Wed Jun 3 15:36:32 2020 -0500 scsi: ibmvscsi: Don't send host info in adapter info MAD after LPM [ Upstream commit 4919b33b63c8b69d8dcf2b867431d0e3b6dc6d28 ] The adapter info MAD is used to send the client info and receive the host info as a response. A persistent buffer is used and as such the client info is overwritten after the response. During the course of a normal adapter reset the client info is refreshed in the buffer in preparation for sending the adapter info MAD. However, in the special case of LPM where we reenable the CRQ instead of a full CRQ teardown and reset we fail to refresh the client info in the adapter info buffer. As a result, after Live Partition Migration (LPM) we erroneously report the host's info as our own. [mkp: typos] Link: https://lore.kernel.org/r/20200603203632.18426-1-tyreld@linux.ibm.com Signed-off-by: Tyrel Datwyler Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 83724c50b405f1768bbd49b24ab8bbfc3c6b7c54 Author: Simon Arlott Date: Sat May 30 18:59:44 2020 +0100 scsi: sr: Fix sr_probe() missing deallocate of device minor [ Upstream commit 6555781b3fdec5e94e6914511496144241df7dee ] If the cdrom fails to be registered then the device minor should be deallocated. Link: https://lore.kernel.org/r/072dac4b-8402-4de8-36bd-47e7588969cd@0882a8b5-c6c3-11e9-b005-00805fc181fe Signed-off-by: Simon Arlott Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit eb2cc7ae99228f21cf770564d9c4171a42799e6e Author: Simon Arlott Date: Sat May 30 18:58:25 2020 +0100 scsi: sr: Fix sr_probe() missing mutex_destroy [ Upstream commit a247e07f8dadba5da9f188aaf4f96db0302146d9 ] If the device minor cannot be allocated or the cdrom fails to be registered then the mutex should be destroyed. Link: https://lore.kernel.org/r/06e9de38-eeed-1cab-5e08-e889288935b3@0882a8b5-c6c3-11e9-b005-00805fc181fe Fixes: 51a858817dcd ("scsi: sr: get rid of sr global mutex") Signed-off-by: Simon Arlott Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5f03c8b9b53d0dbe4c7b7c60bb199601d687c92d Author: Jakub Sitnicki Date: Sun Jun 7 22:52:28 2020 +0200 bpf, sockhash: Fix memory leak when unlinking sockets in sock_hash_free [ Upstream commit 33a7c831565c43a7ee2f38c7df4c4a40e1dfdfed ] When sockhash gets destroyed while sockets are still linked to it, we will walk the bucket lists and delete the links. However, we are not freeing the list elements after processing them, leaking the memory. The leak can be triggered by close()'ing a sockhash map when it still contains sockets, and observed with kmemleak: unreferenced object 0xffff888116e86f00 (size 64): comm "race_sock_unlin", pid 223, jiffies 4294731063 (age 217.404s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 81 de e8 41 00 00 00 00 c0 69 2f 15 81 88 ff ff ...A.....i/..... backtrace: [<00000000dd089ebb>] sock_hash_update_common+0x4ca/0x760 [<00000000b8219bd5>] sock_hash_update_elem+0x1d2/0x200 [<000000005e2c23de>] __do_sys_bpf+0x2046/0x2990 [<00000000d0084618>] do_syscall_64+0xad/0x9a0 [<000000000d96f263>] entry_SYSCALL_64_after_hwframe+0x49/0xb3 Fix it by freeing the list element when we're done with it. Fixes: 604326b41a6f ("bpf, sockmap: convert to generic sk_msg interface") Signed-off-by: Jakub Sitnicki Signed-off-by: Alexei Starovoitov Acked-by: John Fastabend Link: https://lore.kernel.org/bpf/20200607205229.2389672-2-jakub@cloudflare.com Signed-off-by: Sasha Levin commit 8a4c95effab2bca80e250290cba01fa06ada4a80 Author: Pavel Machek (CIP) Date: Sat Jun 6 17:31:03 2020 +0200 ASoC: meson: add missing free_irq() in error path [ Upstream commit 3b8a299a58b2afce464ae11324b59dcf0f1d10a7 ] free_irq() is missing in case of error, fix that. Signed-off-by: Pavel Machek (CIP) Reviewed-by: Jerome Brunet Link: https://lore.kernel.org/r/20200606153103.GA17905@amd Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 5e75707d5f574c66c6b30b6ab406a5ab9863f48c Author: Chuhong Yuan Date: Wed Jun 3 09:27:28 2020 -0700 xfs: Add the missed xfs_perag_put() for xfs_ifree_cluster() [ Upstream commit 8cc0072469723459dc6bd7beff81b2b3149f4cf4 ] xfs_ifree_cluster() calls xfs_perag_get() at the beginning, but forgets to call xfs_perag_put() in one failed path. Add the missed function call to fix it. Fixes: ce92464c180b ("xfs: make xfs_trans_get_buf return an error code") Signed-off-by: Chuhong Yuan Reviewed-by: Darrick J. Wong Signed-off-by: Darrick J. Wong Signed-off-by: Sasha Levin commit 991d47c14c0c7874fa95511def9d2222bfcac4c4 Author: Chao Yu Date: Mon Jun 8 20:03:16 2020 +0800 f2fs: handle readonly filesystem in f2fs_ioc_shutdown() [ Upstream commit 8626441f05dc45a2f4693ee6863d02456ce39e60 ] If mountpoint is readonly, we should allow shutdowning filesystem successfully, this fixes issue found by generic/599 testcase of xfstest. Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 0c3b151299a0e30413f8ffc6d738d247764810c4 Author: Mauricio Faria de Oliveira Date: Tue Jun 2 18:15:16 2020 -0300 apparmor: check/put label on apparmor_sk_clone_security() [ Upstream commit 3b646abc5bc6c0df649daea4c2c976bd4d47e4c8 ] Currently apparmor_sk_clone_security() does not check for existing label/peer in the 'new' struct sock; it just overwrites it, if any (with another reference to the label of the source sock.) static void apparmor_sk_clone_security(const struct sock *sk, struct sock *newsk) { struct aa_sk_ctx *ctx = SK_CTX(sk); struct aa_sk_ctx *new = SK_CTX(newsk); new->label = aa_get_label(ctx->label); new->peer = aa_get_label(ctx->peer); } This might leak label references, which might overflow under load. Thus, check for and put labels, to prevent such errors. Note this is similarly done on: static int apparmor_socket_post_create(struct socket *sock, ...) ... if (sock->sk) { struct aa_sk_ctx *ctx = SK_CTX(sock->sk); aa_put_label(ctx->label); ctx->label = aa_get_label(label); } ... Context: ------- The label reference count leak is observed if apparmor_sock_graft() is called previously: this sets the 'ctx->label' field by getting a reference to the current label (later overwritten, without put.) static void apparmor_sock_graft(struct sock *sk, ...) { struct aa_sk_ctx *ctx = SK_CTX(sk); if (!ctx->label) ctx->label = aa_get_current_label(); } And that is the case on crypto/af_alg.c:af_alg_accept(): int af_alg_accept(struct sock *sk, struct socket *newsock, ...) ... struct sock *sk2; ... sk2 = sk_alloc(...); ... security_sock_graft(sk2, newsock); security_sk_clone(sk, sk2); ... Apparently both calls are done on their own right, especially for other LSMs, being introduced in 2010/2014, before apparmor socket mediation in 2017 (see commits [1,2,3,4]). So, it looks OK there! Let's fix the reference leak in apparmor. Test-case: --------- Exercise that code path enough to overflow label reference count. $ cat aa-refcnt-af_alg.c #include #include #include #include #include int main() { int sockfd; struct sockaddr_alg sa; /* Setup the crypto API socket */ sockfd = socket(AF_ALG, SOCK_SEQPACKET, 0); if (sockfd < 0) { perror("socket"); return 1; } memset(&sa, 0, sizeof(sa)); sa.salg_family = AF_ALG; strcpy((char *) sa.salg_type, "rng"); strcpy((char *) sa.salg_name, "stdrng"); if (bind(sockfd, (struct sockaddr *) &sa, sizeof(sa)) < 0) { perror("bind"); return 1; } /* Accept a "connection" and close it; repeat. */ while (!close(accept(sockfd, NULL, 0))); return 0; } $ gcc -o aa-refcnt-af_alg aa-refcnt-af_alg.c $ ./aa-refcnt-af_alg [ 9928.475953] refcount_t overflow at apparmor_sk_clone_security+0x37/0x70 in aa-refcnt-af_alg[1322], uid/euid: 1000/1000 ... [ 9928.507443] RIP: 0010:apparmor_sk_clone_security+0x37/0x70 ... [ 9928.514286] security_sk_clone+0x33/0x50 [ 9928.514807] af_alg_accept+0x81/0x1c0 [af_alg] [ 9928.516091] alg_accept+0x15/0x20 [af_alg] [ 9928.516682] SYSC_accept4+0xff/0x210 [ 9928.519609] SyS_accept+0x10/0x20 [ 9928.520190] do_syscall_64+0x73/0x130 [ 9928.520808] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 Note that other messages may be seen, not just overflow, depending on the value being incremented by kref_get(); on another run: [ 7273.182666] refcount_t: saturated; leaking memory. ... [ 7273.185789] refcount_t: underflow; use-after-free. Kprobes: ------- Using kprobe events to monitor sk -> sk_security -> label -> count (kref): Original v5.7 (one reference leak every iteration) ... (af_alg_accept+0x0/0x1c0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd2 ... (af_alg_release_parent+0x0/0xd0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd4 ... (af_alg_accept+0x0/0x1c0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd3 ... (af_alg_release_parent+0x0/0xd0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd5 ... (af_alg_accept+0x0/0x1c0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd4 ... (af_alg_release_parent+0x0/0xd0) label=0xffff8a0f36c25eb0 label_refcnt=0x11fd6 Patched v5.7 (zero reference leak per iteration) ... (af_alg_accept+0x0/0x1c0) label=0xffff9ff376c25eb0 label_refcnt=0x593 ... (af_alg_release_parent+0x0/0xd0) label=0xffff9ff376c25eb0 label_refcnt=0x594 ... (af_alg_accept+0x0/0x1c0) label=0xffff9ff376c25eb0 label_refcnt=0x593 ... (af_alg_release_parent+0x0/0xd0) label=0xffff9ff376c25eb0 label_refcnt=0x594 ... (af_alg_accept+0x0/0x1c0) label=0xffff9ff376c25eb0 label_refcnt=0x593 ... (af_alg_release_parent+0x0/0xd0) label=0xffff9ff376c25eb0 label_refcnt=0x594 Commits: ------- [1] commit 507cad355fc9 ("crypto: af_alg - Make sure sk_security is initialized on accept()ed sockets") [2] commit 4c63f83c2c2e ("crypto: af_alg - properly label AF_ALG socket") [3] commit 2acce6aa9f65 ("Networking") a.k.a ("crypto: af_alg - Avoid sock_graft call warning) [4] commit 56974a6fcfef ("apparmor: add base infastructure for socket mediation") Fixes: 56974a6fcfef ("apparmor: add base infastructure for socket mediation") Reported-by: Brian Moyles Signed-off-by: Mauricio Faria de Oliveira Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 7925b0e191e0939b096ff2706156e8e5f086c21e Author: Martin Blumenstingl Date: Sun Jun 7 15:02:58 2020 +0200 net: dsa: lantiq_gswip: fix and improve the unsupported interface error [ Upstream commit 4d3da2d8d91f66988a829a18a0ce59945e8ae4fb ] While trying to use the lantiq_gswip driver on one of my boards I made a mistake when specifying the phy-mode (because the out-of-tree driver wants phy-mode "gmii" or "mii" for the internal PHYs). In this case the following error is printed multiple times: Unsupported interface: 3 While it gives at least a hint at what may be wrong it is not very user friendly. Print the human readable phy-mode and also which port is configured incorrectly (this hardware supports ports 0..6) to improve the cases where someone made a mistake. Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200") Signed-off-by: Martin Blumenstingl Acked-by: Hauke Mehrtens Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 5405101f00cbeb463ab385b3ca9a70d34ff56662 Author: John Johansen Date: Fri Jun 5 18:12:21 2020 -0700 apparmor: fix introspection of of task mode for unconfined tasks [ Upstream commit dd2569fbb053719f7df7ef8fdbb45cf47156a701 ] Fix two issues with introspecting the task mode. 1. If a task is attached to a unconfined profile that is not the ns->unconfined profile then. Mode the mode is always reported as - $ ps -Z LABEL PID TTY TIME CMD unconfined 1287 pts/0 00:00:01 bash test (-) 1892 pts/0 00:00:00 ps instead of the correct value of (unconfined) as shown below $ ps -Z LABEL PID TTY TIME CMD unconfined 2483 pts/0 00:00:01 bash test (unconfined) 3591 pts/0 00:00:00 ps 2. if a task is confined by a stack of profiles that are unconfined the output of label mode is again the incorrect value of (-) like above, instead of (unconfined). This is because the visibile profile count increment is skipped by the special casing of unconfined. Fixes: f1bd904175e8 ("apparmor: add the base fns() for domain labels") Signed-off-by: John Johansen Signed-off-by: Sasha Levin commit 8f90c6dd549100256d2ddde020d718dc69581d0a Author: ashimida Date: Tue Jun 2 15:45:17 2020 +0800 mksysmap: Fix the mismatch of '.L' symbols in System.map [ Upstream commit 72d24accf02add25e08733f0ecc93cf10fcbd88c ] When System.map was generated, the kernel used mksysmap to filter the kernel symbols, but all the symbols with the second letter 'L' in the kernel were filtered out, not just the symbols starting with 'dot + L'. For example: ashimida@ubuntu:~/linux$ cat System.map |grep ' .L' ashimida@ubuntu:~/linux$ nm -n vmlinux |grep ' .L' ffff0000088028e0 t bLength_show ...... ffff0000092e0408 b PLLP_OUTC_lock ffff0000092e0410 b PLLP_OUTA_lock The original intent should be to filter out all local symbols starting with '.L', so the dot should be escaped. Fixes: 00902e984732 ("mksysmap: Add h8300 local symbol pattern") Signed-off-by: ashimida Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit 005f64b6fd84f650a558f70ae24c3bcc407c40de Author: Logan Gunthorpe Date: Wed Jan 9 12:22:28 2019 -0700 NTB: Fix the default port and peer numbers for legacy drivers [ Upstream commit fc8b086d9dbd57458d136c4fa70ee26f832c3a2e ] When the commit adding ntb_default_port_number() and ntb_default_peer_port_number() entered the kernel there was no users of it so it was impossible to tell what the API needed. When a user finally landed a year later (ntb_pingpong) there were more NTB topologies were created and no consideration was considered to how other drivers had changed. Now that there is a user it can be fixed to provide a sensible default for the legacy drivers that do not implement ntb_{peer_}port_number(). Seeing ntb_pingpong doesn't check error codes returning EINVAL was also not sensible. Patches for ntb_pingpong and ntb_perf follow (which are broken otherwise) to support hardware that doesn't have port numbers. This is important not only to not break support with existing drivers but for the cross link topology which, due to its perfect symmetry, cannot assign unique port numbers to each side. Fixes: 1e5301196a88 ("NTB: Add indexed ports NTB API") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit 140ed012ea1fc3466b931a99f866b686461bf97e Author: Logan Gunthorpe Date: Wed Jan 9 12:22:29 2019 -0700 NTB: ntb_pingpong: Choose doorbells based on port number [ Upstream commit ca93c45755da98302c93abdd788fc09113baf9e0 ] This commit fixes pingpong support for existing drivers that do not implement ntb_default_port_number() and ntb_default_peer_port_number(). This is required for hardware (like the crosslink topology of switchtec) which cannot assign reasonable port numbers to each port due to its perfect symmetry. Instead of picking the doorbell to use based on the the index of the peer, we use the peer's port number. This is a bit clearer and easier to understand. Fixes: c7aeb0afdcc2 ("NTB: ntb_pp: Add full multi-port NTB API support") Signed-off-by: Logan Gunthorpe Acked-by: Allen Hubbe Tested-by: Alexander Fomichev Signed-off-by: Jon Mason Signed-off-by: Sasha Levin commit d69eefd57e2a50fe5fd8f287b51b3c17d10424d1 Author: Colin Ian King Date: Thu Jun 4 18:12:16 2020 +0100 ASoC: meson: fix memory leak of links if allocation of ldata fails [ Upstream commit 6e801dc411329aff592fbd48fb116183d0acdb00 ] Currently if the allocation of ldata fails the error return path does not kfree the allocated links object. Fix this by adding an error exit return path that performs the necessary kfree'ing. Fixes: 7864a79f37b5 ("ASoC: meson: add axg sound card support") Signed-off-by: Colin Ian King Addresses-Coverity: ("Resource leak") Link: https://lore.kernel.org/r/20200604171216.60043-1-colin.king@canonical.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit aeadf66a5db6de978dc94f99b8a10c0c34f05a48 Author: Ahmed S. Darwish Date: Wed Jun 3 16:49:47 2020 +0200 net: mdiobus: Disable preemption upon u64_stats update [ Upstream commit c7e261d81783387a0502878cd229327e7c54322e ] The u64_stats mechanism uses sequence counters to protect against 64-bit values tearing on 32-bit architectures. Updating u64_stats is thus a sequence counter write side critical section where preemption must be disabled. For mdiobus_stats_acct(), disable preemption upon the u64_stats update. It is called from process context through mdiobus_read() and mdiobus_write(). Reported-by: kernel test robot Signed-off-by: Ahmed S. Darwish Reviewed-by: Sebastian Andrzej Siewior Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 8dd312267f27d6cee54d177b788691d20f677917 Author: Wang Hai Date: Thu Jun 4 20:18:51 2020 +0800 yam: fix possible memory leak in yam_init_driver [ Upstream commit 98749b7188affbf2900c2aab704a8853901d1139 ] If register_netdev(dev) fails, free_netdev(dev) needs to be called, otherwise a memory leak will occur. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Reported-by: Hulk Robot Signed-off-by: Wang Hai Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 13c2b1c37f80e03f0e35dacb80cdec9b2b7a8e63 Author: Tero Kristo Date: Wed May 27 15:24:26 2020 +0300 crypto: omap-sham - huge buffer access fixes [ Upstream commit 6395166d7a19019d5e9574eb9ecdaf0028abb887 ] The ctx internal buffer can only hold buflen amount of data, don't try to copy over more than that. Also, initialize the context sg pointer if we only have data in the context internal buffer, this can happen when closing a hash with certain data amounts. Signed-off-by: Tero Kristo Signed-off-by: Herbert Xu Signed-off-by: Sasha Levin commit 2dcef8fd3497d7db396d4da139d587650727c856 Author: Thierry Reding Date: Wed Jun 3 16:20:02 2020 +0200 drm/nouveau: gr/gk20a: Use firmware version 0 [ Upstream commit 21454fe697fde188ad6fb541f94b9838fa73ab38 ] Tegra firmware doesn't actually use any version numbers and passing -1 causes the existing firmware binaries not to be found. Use version 0 to find the correct files. Fixes: ef16dc278ec2 ("drm/nouveau/gr/gf100-: select implementation based on available FW") Signed-off-by: Thierry Reding Reviewed-by: Emil Velikov Signed-off-by: Ben Skeggs Signed-off-by: Sasha Levin commit 2f6400e5c19c2f1fc969e3c739cf03bd87b8c458 Author: Arnd Bergmann Date: Tue Apr 7 16:21:46 2020 +0200 clk: sprd: fix compile-testing [ Upstream commit b5f73d47f34b238221ac771b5fe4907df621d7cb ] I got a build failure with CONFIG_ARCH_SPRD=m when the main portion of the clock driver failed to get linked into the kernel: ERROR: modpost: "sprd_pll_sc_gate_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_pll_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_div_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_comp_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_mux_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_gate_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_sc_gate_ops" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_clk_probe" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_clk_regmap_init" [drivers/clk/sprd/sc9863a-clk.ko] undefined! ERROR: modpost: "sprd_pll_ops" [drivers/clk/sprd/sc9860-clk.ko] undefined! ERROR: modpost: "sprd_div_ops" [drivers/clk/sprd/sc9860-clk.ko] undefined! ERROR: modpost: "sprd_mux_ops" [drivers/clk/sprd/sc9860-clk.ko] undefined! This is a combination of two trivial bugs: - A platform should not be 'tristate', it should be a 'bool' symbol like the other platforms, if only for consistency, and to avoid surprises like this one. - The clk Makefile does not traverse into the sprd subdirectory if the platform is disabled but the drivers are enabled for compile-testing. Fixing either of the two would be sufficient to address the link failure, but for correctness, both need to be changed. Fixes: 2b1b799d7630 ("arm64: change ARCH_SPRD Kconfig to tristate") Fixes: d41f59fd92f2 ("clk: sprd: Add common infrastructure") Acked-by: Chunyan Zhang Signed-off-by: Arnd Bergmann Signed-off-by: Sasha Levin commit 692b4a425c8b7ae93aac419d81ec0b686a788e1b Author: Will Deacon Date: Tue May 26 18:33:00 2020 +0100 sparc32: mm: Don't try to free page-table pages if ctor() fails [ Upstream commit 454b0289c6b5f2c66164654b80212d15fbef7a03 ] The pages backing page-table allocations for SRMMU are allocated via memblock as part of the "nocache" region initialisation during srmmu_paging_init() and should not be freed even if a later call to pgtable_pte_page_ctor() fails. Remove the broken call to __free_page(). Cc: David S. Miller Cc: Kirill A. Shutemov Fixes: 1ae9ae5f7df7 ("sparc: handle pgtable_page_ctor() fail") Signed-off-by: Will Deacon Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 0a8287278abc629be354db88450909c41e370feb Author: Navid Emamdoost Date: Mon Jun 1 02:11:16 2020 -0500 pwm: img: Call pm_runtime_put() in pm_runtime_get_sync() failed case [ Upstream commit ca162ce98110b98e7d97b7157328d34dcfdd40a9 ] Even in failed case of pm_runtime_get_sync(), the usage_count is incremented. In order to keep the usage_count with correct value call appropriate pm_runtime_put(). Signed-off-by: Navid Emamdoost Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin commit 5b2a4f514370ec81a5b76c71b0f870c239f350c0 Author: Pingfan Liu Date: Wed Apr 1 22:00:44 2020 +0800 powerpc/crashkernel: Take "mem=" option into account [ Upstream commit be5470e0c285a68dc3afdea965032f5ddc8269d7 ] 'mem=" option is an easy way to put high pressure on memory during some test. Hence after applying the memory limit, instead of total mem, the actual usable memory should be considered when reserving mem for crashkernel. Otherwise the boot up may experience OOM issue. E.g. it would reserve 4G prior to the change and 512M afterward, if passing crashkernel="2G-4G:384M,4G-16G:512M,16G-64G:1G,64G-128G:2G,128G-:4G", and mem=5G on a 256G machine. This issue is powerpc specific because it puts higher priority on fadump and kdump reservation than on "mem=". Referring the following code: if (fadump_reserve_mem() == 0) reserve_crashkernel(); ... /* Ensure that total memory size is page-aligned. */ limit = ALIGN(memory_limit ?: memblock_phys_mem_size(), PAGE_SIZE); memblock_enforce_memory_limit(limit); While on other arches, the effect of "mem=" takes a higher priority and pass through memblock_phys_mem_size() before calling reserve_crashkernel(). Signed-off-by: Pingfan Liu Reviewed-by: Hari Bathini Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/1585749644-4148-1-git-send-email-kernelfans@gmail.com Signed-off-by: Sasha Levin commit fb3052ffaf526514598aa49c54aa4553615fabb3 Author: John Stultz Date: Fri May 29 21:38:23 2020 +0000 ASoC: qcom: q6asm-dai: kCFI fix [ Upstream commit a6b675a89e51a1cdad0481b809b7840d3f86e4b5 ] Fixes the following kCFI crash seen on db845c, caused by the function prototypes not matching the callback function prototype. [ 82.585661] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000001 [ 82.595387] Mem abort info: [ 82.599463] ESR = 0x96000005 [ 82.602658] EC = 0x25: DABT (current EL), IL = 32 bits [ 82.608177] SET = 0, FnV = 0 [ 82.611829] EA = 0, S1PTW = 0 [ 82.615369] Data abort info: [ 82.618751] ISV = 0, ISS = 0x00000005 [ 82.622641] CM = 0, WnR = 0 [ 82.625774] user pgtable: 4k pages, 39-bit VAs, pgdp=0000000174259000 [ 82.632292] [0000000000000001] pgd=0000000000000000, pud=0000000000000000 [ 82.639167] Internal error: Oops: 96000005 [#1] PREEMPT SMP [ 82.644795] Modules linked in: hci_uart btqca xhci_plat_hcd xhci_pci_renesas xhci_pci xhci_hcd wcn36xx wcnss_ctrl wcd934x vctrl_regulator ufs_qcom syscon_reboot_e [ 82.644927] qcom_apcs_ipc_mailbox q6asm_dai q6routing q6asm q6afe_dai q6adm q6afe q6core q6dsp_common pm8941_pwrkey pm8916_wdt platform_mhu pinctrl_spmi_mpp pine [ 82.812982] CPU: 3 PID: 240 Comm: kworker/u16:4 Tainted: G W 5.6.0-rc7-mainline-00960-g0c34353d11b9-dirty #1 [ 82.824201] Hardware name: Thundercomm Dragonboard 845c (DT) [ 82.829937] Workqueue: qcom_apr_rx apr_rxwq [apr] [ 82.834698] pstate: 80c00005 (Nzcv daif +PAN +UAO) [ 82.839553] pc : __cfi_check_fail+0x4/0x1c [q6asm_dai] [ 82.844754] lr : __cfi_check+0x3a8/0x3b0 [q6asm_dai] [ 82.849767] sp : ffffffc0105f3c20 [ 82.853123] x29: ffffffc0105f3c30 x28: 0000000000000020 [ 82.858489] x27: ffffff80f4588400 x26: ffffff80f458ec94 [ 82.863854] x25: ffffff80f458ece8 x24: ffffffe3670c7000 [ 82.869220] x23: ffffff8094bb7b34 x22: ffffffe367137000 [ 82.874585] x21: bd07909b332eada6 x20: 0000000000000001 [ 82.879950] x19: ffffffe36713863c x18: ffffff80f8df4430 [ 82.885316] x17: 0000000000000001 x16: ffffffe39d15e660 [ 82.890681] x15: 0000000000000001 x14: 0000000000000027 [ 82.896047] x13: 0000000000000000 x12: ffffffe39e6465a0 [ 82.901413] x11: 0000000000000051 x10: 000000000000ffff [ 82.906779] x9 : 000ffffffe366c19 x8 : c3c5f18762d1ceef [ 82.912145] x7 : 0000000000000000 x6 : ffffffc010877698 [ 82.917511] x5 : ffffffc0105f3c00 x4 : 0000000000000000 [ 82.922877] x3 : 0000000000000000 x2 : 0000000000000001 [ 82.928243] x1 : ffffffe36713863c x0 : 0000000000000001 [ 82.933610] Call trace: [ 82.936099] __cfi_check_fail+0x4/0x1c [q6asm_dai] [ 82.940955] q6asm_srvc_callback+0x22c/0x618 [q6asm] [ 82.945973] apr_rxwq+0x1a8/0x27c [apr] [ 82.949861] process_one_work+0x2e8/0x54c [ 82.953919] worker_thread+0x27c/0x4d4 [ 82.957715] kthread+0x144/0x154 [ 82.960985] ret_from_fork+0x10/0x18 [ 82.964603] Code: a8c37bfd f85f8e5e d65f03c0 b40000a0 (39400008) [ 82.970762] ---[ end trace 410accb839617143 ]--- [ 82.975429] Kernel panic - not syncing: Fatal exception Signed-off-by: John Stultz Reviewed-by: Srinivas Kandagatla Cc: Patrick Lai Cc: Banajit Goswami Cc: Liam Girdwood Cc: Mark Brown Cc: Jaroslav Kysela Cc: Takashi Iwai Cc: Srinivas Kandagatla Cc: Vinod Koul Cc: Kuninori Morimoto Cc: Stephan Gerhold Cc: Sami Tolvanen Cc: Todd Kjos Cc: Alistair Delva Cc: Amit Pundir Cc: Sumit Semwal Cc: alsa-devel@alsa-project.org Link: https://lore.kernel.org/r/20200529213823.98812-1-john.stultz@linaro.org Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f4ff6cd76dc240e26f45e04a5aa88a17cde0c1d7 Author: Paulo Alcantara Date: Tue May 19 15:38:27 2020 -0300 cifs: set up next DFS target before generic_ip_connect() [ Upstream commit aaa3aef34d3ab9499a5c7633823429f7a24e6dff ] If we mount a very specific DFS link \\FS0.FOO.COM\dfs\link -> \FS0\share1, \FS1\share2 where its target list contains NB names ("FS0" & "FS1") rather than FQDN ones ("FS0.FOO.COM" & "FS1.FOO.COM"), we end up connecting to \FOO\share1 but server->hostname will have "FOO.COM". The reason is because both "FS0" and "FS0.FOO.COM" resolve to same IP address and they share same TCP server connection, but "FS0.FOO.COM" was the first hostname set -- which is OK. However, if the echo thread timeouts and we still have a good connection to "FS0", in cifs_reconnect() rc = generic_ip_connect(server) -> success if (rc) { ... reconn_inval_dfs_target(server, cifs_sb, &tgt_list, &tgt_it); ... } ... it successfully reconnects to "FS0" server but does not set up next DFS target - which should be the same target server "\FS0\share1" - and server->hostname remains set to "FS0.FOO.COM" rather than "FS0", as reconn_inval_dfs_target() would have it set to "FS0" if called earlier. Finally, in __smb2_reconnect(), the reconnect of tcons would fail because tcon->ses->server->hostname (FS0.FOO.COM) does not match DFS target's hostname (FS0). Fix that by calling reconn_inval_dfs_target() before generic_ip_connect() so server->hostname will get updated correctly prior to reconnecting its tcons in __smb2_reconnect(). With "cifs: handle hostnames that resolve to same ip in failover" patch - The above problem would not occur. - We could save an DNS query to find out that they both resolve to the same ip address. Signed-off-by: Paulo Alcantara (SUSE) Reviewed-by: Aurelien Aptel Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 86f04de9f36d2177b1a67ad93d0bc13ce1152b83 Author: Qiushi Wu Date: Wed May 27 22:02:30 2020 -0500 RDMA/core: Fix several reference count leaks. [ Upstream commit 0b8e125e213204508e1b3c4bdfe69713280b7abd ] kobject_init_and_add() takes reference even when it fails. If this function returns an error, kobject_put() must be called to properly clean up the memory associated with the object. Previous commit b8eb718348b8 ("net-sysfs: Fix reference count leak in rx|netdev_queue_add_kobject") fixed a similar problem. Link: https://lore.kernel.org/r/20200528030231.9082-1-wu000273@umn.edu Signed-off-by: Qiushi Wu Reviewed-by: Jason Gunthorpe Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit e0907e4085deca523739b410995b6ba6c25e2964 Author: Jon Derrick Date: Wed May 27 23:02:39 2020 -0400 PCI: vmd: Filter resource type bits from shadow register [ Upstream commit 3e5095eebe015d5a4d566aa5e03c8621add5f0a7 ] Versions of VMD with the Host Physical Address shadow register use this register to calculate the bus address offset needed to do guest passthrough of the domain. This register shadows the Host Physical Address registers including the resource type bits. After calculating the offset, the extra resource type bits lead to the VMD resources being over-provisioned at the front and under-provisioned at the back. Example: pci 10000:80:02.0: reg 0x10: [mem 0xf801fffc-0xf803fffb 64bit] Expected: pci 10000:80:02.0: reg 0x10: [mem 0xf8020000-0xf803ffff 64bit] If other devices are mapped in the over-provisioned front, it could lead to resource conflict issues with VMD or those devices. Link: https://lore.kernel.org/r/20200528030240.16024-3-jonathan.derrick@intel.com Fixes: a1a30170138c9 ("PCI: vmd: Fix shadow offsets to reflect spec changes") Signed-off-by: Jon Derrick Signed-off-by: Lorenzo Pieralisi Signed-off-by: Sasha Levin commit c745f9ef3c8cbae70556131eaeaf0f64510243b7 Author: Xiyu Yang Date: Mon May 25 22:15:41 2020 +0800 nfsd: Fix svc_xprt refcnt leak when setup callback client failed [ Upstream commit a4abc6b12eb1f7a533c2e7484cfa555454ff0977 ] nfsd4_process_cb_update() invokes svc_xprt_get(), which increases the refcount of the "c->cn_xprt". The reference counting issue happens in one exception handling path of nfsd4_process_cb_update(). When setup callback client failed, the function forgets to decrease the refcnt increased by svc_xprt_get(), causing a refcnt leak. Fix this issue by calling svc_xprt_put() when setup callback client failed. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Signed-off-by: J. Bruce Fields Signed-off-by: Sasha Levin commit 3be21617fc451ed59bcf7a6275a7565c35471099 Author: Kajol Jain Date: Mon May 25 16:13:03 2020 +0530 powerpc/perf/hv-24x7: Fix inconsistent output values incase multiple hv-24x7 events run [ Upstream commit b4ac18eead28611ff470d0f47a35c4e0ac080d9c ] Commit 2b206ee6b0df ("powerpc/perf/hv-24x7: Display change in counter values")' added to print _change_ in the counter value rather then raw value for 24x7 counters. Incase of transactions, the event count is set to 0 at the beginning of the transaction. It also sets the event's prev_count to the raw value at the time of initialization. Because of setting event count to 0, we are seeing some weird behaviour, whenever we run multiple 24x7 events at a time. For example: command#: ./perf stat -e "{hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/, hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/}" -C 0 -I 1000 sleep 100 1.000121704 120 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 1.000121704 5 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 2.000357733 8 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 2.000357733 10 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 3.000495215 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 3.000495215 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 4.000641884 56 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 4.000641884 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 5.000791887 18,446,744,073,709,551,616 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ Getting these large values in case we do -I. As we are setting event_count to 0, for interval case, overall event_count is not coming in incremental order. As we may can get new delta lesser then previous count. Because of which when we print intervals, we are getting negative value which create these large values. This patch removes part where we set event_count to 0 in function 'h_24x7_event_read'. There won't be much impact as we do set event->hw.prev_count to the raw value at the time of initialization to print change value. With this patch In power9 platform command#: ./perf stat -e "{hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/, hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/}" -C 0 -I 1000 sleep 100 1.000117685 93 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 1.000117685 1 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 2.000349331 98 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 2.000349331 2 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 3.000495900 131 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 3.000495900 4 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 4.000645920 204 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ 4.000645920 61 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=1/ 4.284169997 22 hv_24x7/PM_MCS01_128B_RD_DISP_PORT01,chip=0/ Suggested-by: Sukadev Bhattiprolu Signed-off-by: Kajol Jain Tested-by: Madhavan Srinivasan Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200525104308.9814-2-kjain@linux.ibm.com Signed-off-by: Sasha Levin commit 6f9dc02c8c1028e89c24179f5025fde8e6d110e9 Author: Mark Zhang Date: Wed May 27 16:57:03 2020 +0300 IB/mlx5: Fix DEVX support for MLX5_CMD_OP_INIT2INIT_QP command [ Upstream commit d246a3061528be6d852156d25c02ea69d6db7e65 ] The commit citied in the Fixes line wasn't complete and solved only part of the problems. Update the mlx5_ib to properly support MLX5_CMD_OP_INIT2INIT_QP command in the DEVX, that is required when modify the QP tx_port_affinity. Fixes: 819f7427bafd ("RDMA/mlx5: Add init2init as a modify command") Link: https://lore.kernel.org/r/20200527135703.482501-1-leon@kernel.org Signed-off-by: Mark Zhang Reviewed-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 70205f1ecba9dc0a7b9479139a040d1ceb15a002 Author: Alain Volmat Date: Sun Mar 22 15:07:40 2020 +0100 clk: clk-flexgen: fix clock-critical handling [ Upstream commit a403bbab1a73d798728d76931cab3ff0399b9560 ] Fixes an issue leading to having all clocks following a critical clocks marked as well as criticals. Fixes: fa6415affe20 ("clk: st: clk-flexgen: Detect critical clocks") Signed-off-by: Alain Volmat Link: https://lkml.kernel.org/r/20200322140740.3970-1-avolmat@me.com Reviewed-by: Patrice Chotard Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 12d0a63611deb3e48515f4fa914a8f11bfff0792 Author: Sudhakar Panneerselvam Date: Fri May 22 16:51:57 2020 +0000 scsi: vhost: Notify TCM about the maximum sg entries supported per command [ Upstream commit 5ae6a6a915033bfee79e76e0c374d4f927909edc ] vhost-scsi pre-allocates the maximum sg entries per command and if a command requires more than VHOST_SCSI_PREALLOC_SGLS entries, then that command is failed by it. This patch lets vhost communicate the max sg limit when it registers vhost_scsi_ops with TCM. With this change, TCM would report the max sg entries through "Block Limits" VPD page which will be typically queried by the SCSI initiator during device discovery. By knowing this limit, the initiator could ensure the maximum transfer length is less than or equal to what is reported by vhost-scsi. Link: https://lore.kernel.org/r/1590166317-953-1-git-send-email-sudhakar.panneerselvam@oracle.com Cc: Michael S. Tsirkin Cc: Jason Wang Cc: Paolo Bonzini Cc: Stefan Hajnoczi Reviewed-by: Mike Christie Signed-off-by: Sudhakar Panneerselvam Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0c730c778e2701fa4b632eac6c277f3e31dfcd19 Author: Xiyu Yang Date: Mon May 25 22:16:24 2020 +0800 scsi: lpfc: Fix lpfc_nodelist leak when processing unsolicited event [ Upstream commit 7217e6e694da3aae6d17db8a7f7460c8d4817ebf ] In order to create or activate a new node, lpfc_els_unsol_buffer() invokes lpfc_nlp_init() or lpfc_enable_node() or lpfc_nlp_get(), all of them will return a reference of the specified lpfc_nodelist object to "ndlp" with increased refcnt. When lpfc_els_unsol_buffer() returns, local variable "ndlp" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of lpfc_els_unsol_buffer(). When "ndlp" in DEV_LOSS, the function forgets to decrease the refcnt increased by lpfc_nlp_init() or lpfc_enable_node() or lpfc_nlp_get(), causing a refcnt leak. Fix this issue by calling lpfc_nlp_put() when "ndlp" in DEV_LOSS. Link: https://lore.kernel.org/r/1590416184-52592-1-git-send-email-xiyuyang19@fudan.edu.cn Reviewed-by: Daniel Wagner Reviewed-by: James Smart Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 045c3a8a6c92ab876962a2f367dc1d85fcc79666 Author: Quanyang Wang Date: Mon Mar 2 13:50:43 2020 -0800 clk: zynqmp: fix memory leak in zynqmp_register_clocks [ Upstream commit 58b0fb86260063f86afecaebf4056c876fff2a19 ] This is detected by kmemleak running on zcu102 board: unreferenced object 0xffffffc877e48180 (size 128): comm "swapper/0", pid 1, jiffies 4294892909 (age 315.436s) hex dump (first 32 bytes): 64 70 5f 76 69 64 65 6f 5f 72 65 66 5f 64 69 76 dp_video_ref_div 31 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1............... backtrace: [<00000000c9be883b>] __kmalloc_track_caller+0x200/0x380 [<00000000f02c3809>] kvasprintf+0x7c/0x100 [<00000000e51dde4d>] kasprintf+0x60/0x80 [<0000000092298b05>] zynqmp_register_clocks+0x29c/0x398 [<00000000faaff182>] zynqmp_clock_probe+0x3cc/0x4c0 [<000000005f5986f0>] platform_drv_probe+0x58/0xa8 [<00000000d5810136>] really_probe+0xd8/0x2a8 [<00000000f5b671be>] driver_probe_device+0x5c/0x100 [<0000000038f91fcf>] __device_attach_driver+0x98/0xb8 [<000000008a3f2ac2>] bus_for_each_drv+0x74/0xd8 [<000000001cb2783d>] __device_attach+0xe0/0x140 [<00000000c268031b>] device_initial_probe+0x24/0x30 [<000000006998de4b>] bus_probe_device+0x9c/0xa8 [<00000000647ae6ff>] device_add+0x3c0/0x610 [<0000000071c14bb8>] of_device_add+0x40/0x50 [<000000004bb5d132>] of_platform_device_create_pdata+0xbc/0x138 This is because that when num_nodes is larger than 1, clk_out is allocated using kasprintf for these nodes but only the last node's clk_out is freed. Signed-off-by: Quanyang Wang Signed-off-by: Michal Simek Signed-off-by: Tejas Patel Signed-off-by: Jolly Shah Link: https://lkml.kernel.org/r/1583185843-20707-5-git-send-email-jolly.shah@xilinx.com Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit b0150ea4a6c17020ef5061a01fdd365f8bea722b Author: Dan Carpenter Date: Thu May 21 15:12:21 2020 +0300 scsi: cxgb3i: Fix some leaks in init_act_open() [ Upstream commit b6170a49c59c27a10efed26c5a2969403e69aaba ] There wasn't any clean up done if cxgb3_alloc_atid() failed and also the original code didn't release "csk->l2t". Link: https://lore.kernel.org/r/20200521121221.GA247492@mwanda Fixes: 6f7efaabefeb ("[SCSI] cxgb3i: change cxgb3i to use libcxgbi") Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 7c65dd34eb90498e058126524dee3f7fb193c30d Author: Marek Szyprowski Date: Mon Apr 27 09:48:29 2020 +0200 mfd: wm8994: Fix driver operation if loaded as modules [ Upstream commit d4f9b5428b53dd67f49ee8deed8d4366ed6b1933 ] WM8994 chip has built-in regulators, which might be used for chip operation. They are controlled by a separate wm8994-regulator driver, which should be loaded before this driver calls regulator_get(), because that driver also provides consumer-supply mapping for the them. If that driver is not yet loaded, regulator core substitute them with dummy regulator, what breaks chip operation, because the built-in regulators are never enabled. Fix this by annotating this driver with MODULE_SOFTDEP() "pre" dependency to "wm8994_regulator" module. Signed-off-by: Marek Szyprowski Acked-by: Charles Keepax Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit c4828919f01a73273c983c27786a3cf75788041e Author: Christophe Leroy Date: Tue May 19 05:48:51 2020 +0000 powerpc/ptdump: Add _PAGE_COHERENT flag [ Upstream commit 3af4786eb429b2df76cbd7ce3bae21467ac3e4fb ] For platforms using shared.c (4xx, Book3e, Book3s/32), also handle the _PAGE_COHERENT flag which corresponds to the M bit of the WIMG flags. Signed-off-by: Christophe Leroy [mpe: Make it more verbose, use "coherent" rather than "m"] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/324c3d860717e8e91fca3bb6c0f8b23e1644a404.1589866984.git.christophe.leroy@csgroup.eu Signed-off-by: Sasha Levin commit 6e3e96b898af44eb136cadc19f9480917189e707 Author: Peter Chen Date: Sun May 10 13:30:41 2020 +0800 usb: gadget: core: sync interrupt before unbind the udc [ Upstream commit 3c73bc52195def14165c3a7d91bdbb33b51725f5 ] The threaded interrupt handler may still be called after the usb_gadget_disconnect is called, it causes the structures used at interrupt handler was freed before it uses, eg the usb_request. This issue usually occurs we remove the udc function during the transfer. Below is the example when doing stress test for android switch function, the EP0's request is freed by .unbind (configfs_composite_unbind -> composite_dev_cleanup), but the threaded handler accesses this request during handling setup packet request. In fact, there is no protection between unbind the udc and udc interrupt handling, so we have to avoid the interrupt handler is occurred or scheduled during the .unbind flow. init: Sending signal 9 to service 'adbd' (pid 18077) process group... android_work: did not send uevent (0 0 000000007bec2039) libprocessgroup: Successfully killed process cgroup uid 0 pid 18077 in 6ms init: Service 'adbd' (pid 18077) received signal 9 init: Sending signal 9 to service 'adbd' (pid 18077) process group... libprocessgroup: Successfully killed process cgroup uid 0 pid 18077 in 0ms init: processing action (init.svc.adbd=stopped) from (/init.usb.configfs.rc:14) init: Received control message 'start' for 'adbd' from pid: 399 (/vendor/bin/hw/android.hardware.usb@1. init: starting service 'adbd'... read descriptors read strings Unable to handle kernel read from unreadable memory at virtual address 000000000000002a android_work: sent uevent USB_STATE=CONNECTED Mem abort info: ESR = 0x96000004 EC = 0x25: DABT (current EL), IL = 32 bits SET = 0, FnV = 0 EA = 0, S1PTW = 0 Data abort info: ISV = 0, ISS = 0x00000004 CM = 0, WnR = 0 user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e97f1000 using random self ethernet address [000000000000002a] pgd=0000000000000000 Internal error: Oops: 96000004 [#1] PREEMPT SMP Modules linked in: CPU: 0 PID: 232 Comm: irq/68-5b110000 Not tainted 5.4.24-06075-g94a6b52b5815 #92 Hardware name: Freescale i.MX8QXP MEK (DT) pstate: 00400085 (nzcv daIf +PAN -UAO) using random host ethernet address pc : composite_setup+0x5c/0x1730 lr : android_setup+0xc0/0x148 sp : ffff80001349bba0 x29: ffff80001349bba0 x28: ffff00083a50da00 x27: ffff8000124e6000 x26: ffff800010177950 x25: 0000000000000040 x24: ffff000834e18010 x23: 0000000000000000 x22: 0000000000000000 x21: ffff00083a50da00 x20: ffff00082e75ec40 x19: 0000000000000000 x18: 0000000000000000 x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000 x14: 0000000000000000 x13: 0000000000000000 x12: 0000000000000001 x11: ffff80001180fb58 x10: 0000000000000040 x9 : ffff8000120fc980 x8 : 0000000000000000 x7 : ffff00083f98df50 x6 : 0000000000000100 x5 : 00000307e8978431 x4 : ffff800011386788 x3 : 0000000000000000 x2 : ffff800012342000 x1 : 0000000000000000 x0 : ffff800010c6d3a0 Call trace: composite_setup+0x5c/0x1730 android_setup+0xc0/0x148 cdns3_ep0_delegate_req+0x64/0x90 cdns3_check_ep0_interrupt_proceed+0x384/0x738 cdns3_device_thread_irq_handler+0x124/0x6e0 cdns3_thread_irq+0x94/0xa0 irq_thread_fn+0x30/0xa0 irq_thread+0x150/0x248 kthread+0xfc/0x128 ret_from_fork+0x10/0x18 Code: 910e8000 f9400693 12001ed7 79400f79 (3940aa61) ---[ end trace c685db37f8773fba ]--- Kernel panic - not syncing: Fatal exception SMP: stopping secondary CPUs Kernel Offset: disabled CPU features: 0x0002,20002008 Memory Limit: none Rebooting in 5 seconds.. Reviewed-by: Jun Li Signed-off-by: Peter Chen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit f7004253e1d03b416fe2670c6f49630c948cd571 Author: Andy Shevchenko Date: Tue May 19 16:12:30 2020 +0300 gpio: dwapb: Call acpi_gpiochip_free_interrupts() on GPIO chip de-registration [ Upstream commit 494a94e38dcf62543a32a4424d646ff80b4b28bd ] Add missed acpi_gpiochip_free_interrupts() call when unregistering ports. While at it, drop extra check to call acpi_gpiochip_request_interrupts(). There is no need to have an additional check to call acpi_gpiochip_request_interrupts(). Even without any interrupts available the registered ACPI Event handlers can be useful for debugging purposes. Fixes: e6cb3486f5a1 ("gpio: dwapb: add gpio-signaled acpi event support") Signed-off-by: Andy Shevchenko Tested-by: Serge Semin Acked-by: Serge Semin Link: https://lore.kernel.org/r/20200519131233.59032-1-andriy.shevchenko@linux.intel.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit cd2c9acd3b0b915f5afbd4f0a2ac83f9b56689ec Author: Dinghao Liu Date: Thu May 21 15:39:19 2020 +0800 usb: cdns3: Fix runtime PM imbalance on error [ Upstream commit e5b913496099527abe46e175e5e2c844367bded0 ] pm_runtime_get_sync() increments the runtime PM usage counter even when it returns an error code. Thus a pairing decrement is needed on the error handling path to keep the counter balanced. Reviewed-by: Peter Chen Signed-off-by: Dinghao Liu Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit f3922d1a65cd8f8287be624e1c68f7d3beaba1b1 Author: Omer Shpigelman Date: Mon May 18 22:27:46 2020 +0300 habanalabs: don't allow hard reset with open processes [ Upstream commit 36fafe87edd636292a4ed6a3af9608f2c7d0d0fb ] When the MMU is heavily used by the engines, unmapping might take a lot of time due to a full MMU cache invalidation done as part of the unmap flow. Hence we might not be able to kill all open processes before going to hard reset the device, as it involves unmapping of all user memory. In case of a failure in killing all open processes, we should stop the hard reset flow as it might lead to a kernel crash - one thread (killing of a process) is updating MMU structures that other thread (hard reset) is freeing. Stopping a hard reset flow leaves the device as nonoperational and the user can then initiate a hard reset via sysfs to reinitialize the device. Signed-off-by: Omer Shpigelman Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit c7e949b1817c72ffbb9811a9d6415db0b860c79b Author: Christophe JAILLET Date: Sat Apr 18 09:07:51 2020 +0200 m68k/PCI: Fix a memory leak in an error handling path [ Upstream commit c3f4ec050f56eeab7c1f290321f9b762c95bd332 ] If 'ioremap' fails, we must free 'bridge', as done in other error handling path bellow. Fixes: 19cc4c843f40 ("m68k/PCI: Replace pci_fixup_irqs() call with host bridge IRQ mapping hooks") Signed-off-by: Christophe JAILLET Reviewed-by: Geert Uytterhoeven Signed-off-by: Greg Ungerer Signed-off-by: Sasha Levin commit 9fb9f51bb2229999dd332b3bfeb388a66cd32cba Author: Jon Derrick Date: Mon May 11 12:21:14 2020 -0400 PCI: pci-bridge-emul: Fix PCIe bit conflicts [ Upstream commit c88d19181771bd189147681ef38fc1533ebeff4c ] This patch fixes two bit conflicts in the pci-bridge-emul driver: 1. Bit 3 of Device Status (19 of Device Control) is marked as both Write-1-to-Clear and Read-Only. It should be Write-1-to-Clear. The Read-Only and Reserved bitmasks are shifted by 1 bit due to this error. 2. Bit 12 of Slot Control is marked as both Read-Write and Reserved. It should be Read-Write. Link: https://lore.kernel.org/r/20200511162117.6674-2-jonathan.derrick@intel.com Signed-off-by: Jon Derrick Signed-off-by: Lorenzo Pieralisi Acked-by: Rob Herring Signed-off-by: Sasha Levin commit 1b22e0d770fca2436887f964d28f17dc32b3819f Author: Aneesh Kumar K.V Date: Wed May 13 08:36:16 2020 +0530 powerpc/book3s64/radix/tlb: Determine hugepage flush correctly [ Upstream commit 8f53f9c0f68ab2168f637494b9e24034899c1310 ] With a 64K page size flush with start and end: (start, end) = (721f680d0000, 721f680e0000) results in: (hstart, hend) = (721f68200000, 721f68000000) ie. hstart is above hend, which indicates no huge page flush is needed. However the current logic incorrectly sets hflush = true in this case, because hstart != hend. That causes us to call __tlbie_va_range() passing hstart/hend, to do a huge page flush even though we don't need to. __tlbie_va_range() will skip the actual tlbie operation for start > end. But it will still end up calling fixup_tlbie_va_range() and doing the TLB fixups in there, which is harmless but unnecessary work. Reported-by: Bharata B Rao Signed-off-by: Aneesh Kumar K.V Reviewed-by: Nicholas Piggin [mpe: Drop else case, hflush is already false, flesh out change log] Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/20200513030616.152288-1-aneesh.kumar@linux.ibm.com Signed-off-by: Sasha Levin commit 56ccaf8e87dc35a9067525cb47a71a25964b1a3e Author: Luo Jiaxing Date: Fri May 15 22:13:42 2020 +0800 scsi: hisi_sas: Do not reset phy timer to wait for stray phy up [ Upstream commit e16b9ed61e078d836a0f24a82080cf29d7539c7e ] We found out that after phy up, the hardware reports another oob interrupt but did not follow a phy up interrupt: oob ready -> phy up -> DEV found -> oob read -> wait phy up -> timeout We run link reset when wait phy up timeout, and it send a normal disk into reset processing. So we made some circumvention action in the code, so that this abnormal oob interrupt will not start the timer to wait for phy up. Link: https://lore.kernel.org/r/1589552025-165012-2-git-send-email-john.garry@huawei.com Signed-off-by: Luo Jiaxing Signed-off-by: John Garry Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 40f5ea91d22292cf6ca8f9569df64c0563ae4c58 Author: Aharon Landau Date: Wed May 13 12:55:50 2020 +0300 RDMA/mlx5: Add init2init as a modify command [ Upstream commit 819f7427bafd494ef7ca4942ec6322db20722d7b ] Missing INIT2INIT entry in the list of modify commands caused DEVX applications to be unable to modify_qp for this transition state. Add the MLX5_CMD_OP_INIT2INIT_QP opcode to the list of allowed DEVX opcodes. Fixes: e662e14d801b ("IB/mlx5: Add DEVX support for modify and query commands") Link: https://lore.kernel.org/r/20200513095550.211345-1-leon@kernel.org Signed-off-by: Aharon Landau Reviewed-by: Maor Gottlieb Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit dfa8a28a69e042ed7fabd385276ee7643e6a6c5e Author: Sai Prakash Ranjan Date: Mon May 18 12:02:32 2020 -0600 coresight: tmc: Fix TMC mode read in tmc_read_prepare_etb() [ Upstream commit 347adb0d6385c3220dc01ab61807a5b1892901cc ] On some QCOM platforms like SC7180, SDM845 and SM8150, reading TMC mode register without proper coresight power management can lead to async exceptions like the one in the call trace below in tmc_read_prepare_etb(). This can happen if the user tries to read the TMC etf data via device node without setting up source and the sink first. Fix this by having a check for coresight sysfs mode before reading TMC mode management register. Kernel panic - not syncing: Asynchronous SError Interrupt CPU: 7 PID: 2605 Comm: hexdump Tainted: G S 5.4.30 #122 Call trace: dump_backtrace+0x0/0x188 show_stack+0x20/0x2c dump_stack+0xdc/0x144 panic+0x168/0x36c panic+0x0/0x36c arm64_serror_panic+0x78/0x84 do_serror+0x130/0x138 el1_error+0x84/0xf8 tmc_read_prepare_etb+0x88/0xb8 tmc_open+0x40/0xd8 misc_open+0x120/0x158 chrdev_open+0xb8/0x1a4 do_dentry_open+0x268/0x3a0 vfs_open+0x34/0x40 path_openat+0x39c/0xdf4 do_filp_open+0x90/0x10c do_sys_open+0x150/0x3e8 __arm64_compat_sys_openat+0x28/0x34 el0_svc_common+0xa8/0x160 el0_svc_compat_handler+0x2c/0x38 el0_svc_compat+0x8/0x10 Fixes: 4525412a5046 ("coresight: tmc: making prepare/unprepare functions generic") Reported-by: Stephen Boyd Suggested-by: Mathieu Poirier Signed-off-by: Sai Prakash Ranjan Signed-off-by: Mathieu Poirier Link: https://lore.kernel.org/r/20200518180242.7916-14-mathieu.poirier@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 523f8c223b4a5ec045a4f52b536b8b9a5a411198 Author: Maulik Shah Date: Mon May 18 17:50:02 2020 +0530 arm64: dts: qcom: sc7180: Correct the pdc interrupt ranges [ Upstream commit 7d2f29e49477aa51339e719cf73f0945c39c8a9e ] Few PDC interrupts do not map to respective parent GIC interrupt. Fix this by correcting the pdc interrupt map. Fixes: 22f185ee81d2 ("arm64: dts: qcom: sc7180: Add pdc interrupt controller") Cc: devicetree@vger.kernel.org Signed-off-by: Maulik Shah Link: https://lore.kernel.org/r/1589804402-27130-1-git-send-email-mkshah@codeaurora.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4b0394d95e89e2f0b5f704fd609fdf2aed6ddebb Author: Qian Cai Date: Sun May 10 12:16:56 2020 -0400 vfio/pci: fix memory leaks in alloc_perm_bits() [ Upstream commit 3e63b94b6274324ff2e7d8615df31586de827c4e ] vfio_pci_disable() calls vfio_config_free() but forgets to call free_perm_bits() resulting in memory leaks, unreferenced object 0xc000000c4db2dee0 (size 16): comm "qemu-kvm", pid 4305, jiffies 4295020272 (age 3463.780s) hex dump (first 16 bytes): 00 00 ff 00 ff ff ff ff ff ff ff ff ff ff 00 00 ................ backtrace: [<00000000a6a4552d>] alloc_perm_bits+0x58/0xe0 [vfio_pci] [<00000000ac990549>] vfio_config_init+0xdf0/0x11b0 [vfio_pci] init_pci_cap_msi_perm at drivers/vfio/pci/vfio_pci_config.c:1125 (inlined by) vfio_msi_cap_len at drivers/vfio/pci/vfio_pci_config.c:1180 (inlined by) vfio_cap_len at drivers/vfio/pci/vfio_pci_config.c:1241 (inlined by) vfio_cap_init at drivers/vfio/pci/vfio_pci_config.c:1468 (inlined by) vfio_config_init at drivers/vfio/pci/vfio_pci_config.c:1707 [<000000006db873a1>] vfio_pci_open+0x234/0x700 [vfio_pci] [<00000000630e1906>] vfio_group_fops_unl_ioctl+0x8e0/0xb84 [vfio] [<000000009e34c54f>] ksys_ioctl+0xd8/0x130 [<000000006577923d>] sys_ioctl+0x28/0x40 [<000000006d7b1cf2>] system_call_exception+0x114/0x1e0 [<0000000008ea7dd5>] system_call_common+0xf0/0x278 unreferenced object 0xc000000c4db2e330 (size 16): comm "qemu-kvm", pid 4305, jiffies 4295020272 (age 3463.780s) hex dump (first 16 bytes): 00 ff ff 00 ff ff ff ff ff ff ff ff ff ff 00 00 ................ backtrace: [<000000004c71914f>] alloc_perm_bits+0x44/0xe0 [vfio_pci] [<00000000ac990549>] vfio_config_init+0xdf0/0x11b0 [vfio_pci] [<000000006db873a1>] vfio_pci_open+0x234/0x700 [vfio_pci] [<00000000630e1906>] vfio_group_fops_unl_ioctl+0x8e0/0xb84 [vfio] [<000000009e34c54f>] ksys_ioctl+0xd8/0x130 [<000000006577923d>] sys_ioctl+0x28/0x40 [<000000006d7b1cf2>] system_call_exception+0x114/0x1e0 [<0000000008ea7dd5>] system_call_common+0xf0/0x278 Fixes: 89e1f7d4c66d ("vfio: Add PCI device driver") Signed-off-by: Qian Cai [aw: rolled in follow-up patch] Signed-off-by: Alex Williamson Signed-off-by: Sasha Levin commit 545040abed844e95420409a7c4ef800612a5eff7 Author: Andre Przywara Date: Wed May 13 11:29:58 2020 +0100 arm64: dts: fvp/juno: Fix node address fields [ Upstream commit bb5cce12ac717c7462217cd493ed701d12d6dbce ] The Arm Ltd. boards were using an outdated address convention in the DT node names, by separating the high from the low 32-bits of an address by a comma. Remove the comma from the node name suffix to be DT spec compliant. Link: https://lore.kernel.org/r/20200513103016.130417-3-andre.przywara@arm.com Signed-off-by: Andre Przywara Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 4a3880e065a9d2941b9f43eba1000f38aa66e8db Author: Emmanuel Nicolet Date: Sat May 9 18:58:32 2020 +0000 ps3disk: use the default segment boundary [ Upstream commit 720bc316690bd27dea9d71510b50f0cd698ffc32 ] Since commit dcebd755926b ("block: use bio_for_each_bvec() to compute multi-page bvec count"), the kernel will bug_on on the PS3 because bio_split() is called with sectors == 0: kernel BUG at block/bio.c:1853! Oops: Exception in kernel mode, sig: 5 [#1] BE PAGE_SIZE=4K MMU=Hash PREEMPT SMP NR_CPUS=8 NUMA PS3 Modules linked in: firewire_sbp2 rtc_ps3(+) soundcore ps3_gelic(+) \ ps3rom(+) firewire_core ps3vram(+) usb_common crc_itu_t CPU: 0 PID: 97 Comm: blkid Not tainted 5.3.0-rc4 #1 NIP: c00000000027d0d0 LR: c00000000027d0b0 CTR: 0000000000000000 REGS: c00000000135ae90 TRAP: 0700 Not tainted (5.3.0-rc4) MSR: 8000000000028032 CR: 44008240 XER: 20000000 IRQMASK: 0 GPR00: c000000000289368 c00000000135b120 c00000000084a500 c000000004ff8300 GPR04: 0000000000000c00 c000000004c905e0 c000000004c905e0 000000000000ffff GPR08: 0000000000000000 0000000000000001 0000000000000000 000000000000ffff GPR12: 0000000000000000 c0000000008ef000 000000000000003e 0000000000080001 GPR16: 0000000000000100 000000000000ffff 0000000000000000 0000000000000004 GPR20: c00000000062fd7e 0000000000000001 000000000000ffff 0000000000000080 GPR24: c000000000781788 c00000000135b350 0000000000000080 c000000004c905e0 GPR28: c00000000135b348 c000000004ff8300 0000000000000000 c000000004c90000 NIP [c00000000027d0d0] .bio_split+0x28/0xac LR [c00000000027d0b0] .bio_split+0x8/0xac Call Trace: [c00000000135b120] [c00000000027d130] .bio_split+0x88/0xac (unreliable) [c00000000135b1b0] [c000000000289368] .__blk_queue_split+0x11c/0x53c [c00000000135b2d0] [c00000000028f614] .blk_mq_make_request+0x80/0x7d4 [c00000000135b3d0] [c000000000283a8c] .generic_make_request+0x118/0x294 [c00000000135b4b0] [c000000000283d34] .submit_bio+0x12c/0x174 [c00000000135b580] [c000000000205a44] .mpage_bio_submit+0x3c/0x4c [c00000000135b600] [c000000000206184] .mpage_readpages+0xa4/0x184 [c00000000135b750] [c0000000001ff8fc] .blkdev_readpages+0x24/0x38 [c00000000135b7c0] [c0000000001589f0] .read_pages+0x6c/0x1a8 [c00000000135b8b0] [c000000000158c74] .__do_page_cache_readahead+0x118/0x184 [c00000000135b9b0] [c0000000001591a8] .force_page_cache_readahead+0xe4/0xe8 [c00000000135ba50] [c00000000014fc24] .generic_file_read_iter+0x1d8/0x830 [c00000000135bb50] [c0000000001ffadc] .blkdev_read_iter+0x40/0x5c [c00000000135bbc0] [c0000000001b9e00] .new_sync_read+0x144/0x1a0 [c00000000135bcd0] [c0000000001bc454] .vfs_read+0xa0/0x124 [c00000000135bd70] [c0000000001bc7a4] .ksys_read+0x70/0xd8 [c00000000135be20] [c00000000000a524] system_call+0x5c/0x70 Instruction dump: 7fe3fb78 482e30dc 7c0802a6 482e3085 7c9e2378 f821ff71 7ca42b78 7d3e00d0 7c7d1b78 79290fe0 7cc53378 69290001 <0b090000> 81230028 7bca0020 7929ba62 [ end trace 313fec760f30aa1f ]--- The problem originates from setting the segment boundary of the request queue to -1UL. This makes get_max_segment_size() return zero when offset is zero, whatever the max segment size. The test with BLK_SEG_BOUNDARY_MASK fails and 'mask - (mask & offset) + 1' overflows to zero in the return statement. Not setting the segment boundary and using the default value (BLK_SEG_BOUNDARY_MASK) fixes the problem. Signed-off-by: Emmanuel Nicolet Signed-off-by: Geoff Levand Signed-off-by: Michael Ellerman Link: https://lore.kernel.org/r/060a416c43138f45105c0540eff1a45539f7e2fc.1589049250.git.geoff@infradead.org Signed-off-by: Sasha Levin commit 55e06bac563cdb6bce328170178178a5a9ef62a2 Author: Pali Rohár Date: Thu Apr 30 10:06:15 2020 +0200 PCI: aardvark: Don't blindly enable ASPM L0s and don't write to read-only register [ Upstream commit 90c6cb4a355e7befcb557d217d1d8b8bd5875a05 ] Trying to change Link Status register does not have any effect as this is a read-only register. Trying to overwrite bits for Negotiated Link Width does not make sense. In future proper change of link width can be done via Lane Count Select bits in PCIe Control 0 register. Trying to unconditionally enable ASPM L0s via ASPM Control bits in Link Control register is wrong. There should be at least some detection if endpoint supports L0s as isn't mandatory. Moreover ASPM Control bits in Link Control register are controlled by pcie/aspm.c code which sets it according to system ASPM settings, immediately after aardvark driver probes. So setting these bits by aardvark driver has no long running effect. Remove code which touches ASPM L0s bits from this driver and let kernel's ASPM implementation to set ASPM state properly. Some users are reporting issues that this code is problematic for some Intel wifi cards and removing it fixes them, see e.g.: https://bugzilla.kernel.org/show_bug.cgi?id=196339 If problems with Intel wifi cards occur even after this commit, then pcie/aspm.c code could be modified / hooked to not enable ASPM L0s state for affected problematic cards. Link: https://lore.kernel.org/r/20200430080625.26070-3-pali@kernel.org Tested-by: Tomasz Maciej Nowak Signed-off-by: Pali Rohár Signed-off-by: Lorenzo Pieralisi Acked-by: Rob Herring Acked-by: Thomas Petazzoni Signed-off-by: Sasha Levin commit a51b921b072d0160260e7721e8b93c4eea672272 Author: Andre Przywara Date: Wed May 13 11:30:06 2020 +0100 arm64: dts: fvp: Fix GIC child nodes [ Upstream commit 78631aecc52c4b2adcf611769df2ff9c67ac16d0 ] The GIC DT nodes for the fastmodels were not fully compliant with the DT binding, which has certain expectations about child nodes and their size and address cells values. Use smaller #address-cells and #size-cells values, as the binding requests, and adjust the reg properties accordingly. This requires adjusting the interrupt nexus nodes as well, as one field of the interrupt-map property depends on the GIC's address-size. Since the .dts files share interrupt nexus nodes across different interrupt controllers (GICv2 vs. GICv3), we need to use the only commonly allowed #address-size value of <1> for both. Link: https://lore.kernel.org/r/20200513103016.130417-11-andre.przywara@arm.com Signed-off-by: Andre Przywara Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit 9092cf0711eb90aae08f2ad62a98c7e2303c11bd Author: Daniel Baluta Date: Fri May 15 16:59:51 2020 +0300 ASoC: SOF: Do nothing when DSP PM callbacks are not set [ Upstream commit c26fde3b15ed41f5f452f1da727795f787833287 ] This provides a better separation between runtime and PM sleep callbacks. Only do nothing if given runtime flag is set and calback is not set. With the current implementation, if PM sleep callback is set but runtime callback is not set then at runtime resume we reload the firmware even if we do not support runtime resume callback. Signed-off-by: Daniel Baluta Signed-off-by: Kai Vehmanen Reviewed-by: Pierre-Louis Bossart Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20200515135958.17511-2-kai.vehmanen@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c0ad105896523361e9832cfb7ef1dc525ef135dd Author: Geert Uytterhoeven Date: Thu May 7 09:47:13 2020 +0200 clk: renesas: cpg-mssr: Fix STBCR suspend/resume handling [ Upstream commit ace342097768e35fd41934285604fa97da1e235a ] On SoCs with Standby Control Registers (STBCRs) instead of Module Stop Control Registers (MSTPCRs), the suspend handler saves the wrong registers, and the resume handler prints the wrong register in an error message. Fortunately this cannot happen yet, as the suspend/resume code is used on PSCI systems only, and systems with STBCRs (RZ/A1 and RZ/A2) do not use PSCI. Still, it is better to fix this, to avoid this becoming a problem in the future. Distinguish between STBCRs and MSTPCRs where needed. Replace the useless printing of the virtual register address in the resume error message by printing the register index. Fixes: fde35c9c7db5732c ("clk: renesas: cpg-mssr: Add R7S9210 support") Signed-off-by: Geert Uytterhoeven Link: https://lore.kernel.org/r/20200507074713.30113-1-geert+renesas@glider.be Signed-off-by: Sasha Levin commit 2a2eba909a76abe25e95424b637e7765d47a32b2 Author: Lars Povlsen Date: Wed May 13 14:55:21 2020 +0200 pinctrl: ocelot: Fix GPIO interrupt decoding on Jaguar2 [ Upstream commit 0b47afc65453a70bc521e251138418056f65793f ] This fixes a problem with using the GPIO as an interrupt on Jaguar2 (and similar), as the register layout of the platforms with 64 GPIO's are pairwise, such that the original offset must be multiplied with the platform stride. Fixes: da801ab56ad8 pinctrl: ocelot: add MSCC Jaguar2 support. Reviewed-by: Alexandre Belloni Signed-off-by: Lars Povlsen Link: https://lore.kernel.org/r/20200513125532.24585-4-lars.povlsen@microchip.com Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 4b08481a2162dfbda4d41382e383f6c624cb8673 Author: Kamal Heib Date: Thu May 14 14:47:20 2020 +0300 RDMA/srpt: Fix disabling device management [ Upstream commit 23bbd5818e2b0d265aa1835e66f5055f63a8fa4c ] Avoid disabling device management for devices that don't support Management datagrams (MADs) by checking if the "mad_agent" pointer is initialized before calling ib_modify_port, also fix the error flow in srpt_refresh_port() to disable device management if ib_register_mad_agent() fail. Fixes: 09f8a1486dca ("RDMA/srpt: Fix handling of SR-IOV and iWARP ports") Link: https://lore.kernel.org/r/20200514114720.141139-1-kamalheib1@gmail.com Signed-off-by: Kamal Heib Reviewed-by: Bart Van Assche Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 645943ecaa58775582ffef6ae48efdda835af2ff Author: Yishai Hadas Date: Wed May 6 11:24:42 2020 +0300 RDMA/uverbs: Fix create WQ to use the given user handle [ Upstream commit dbd67252869ba58d086edfa14113e10f8059b97e ] Fix create WQ to use the given user handle, in addition dropped some duplicated code from this flow. Fixes: fd3c7904db6e ("IB/core: Change idr objects to use the new schema") Fixes: f213c0527210 ("IB/uverbs: Add WQ support") Link: https://lore.kernel.org/r/20200506082444.14502-9-leon@kernel.org Signed-off-by: Yishai Hadas Signed-off-by: Leon Romanovsky Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin commit 86dbfac4361fe9d29300f3ab755bcf38347b37fc Author: Andre Przywara Date: Wed May 13 11:30:05 2020 +0100 arm64: dts: juno: Fix GIC child nodes [ Upstream commit a78aee9e434932a500db36cc6d88daeff3745e9f ] The GIC DT nodes for the Juno boards were not fully compliant with the DT binding, which has certain expectations about child nodes and their size and address cells values. Use smaller #address-cells and #size-cells values, as the binding requests, and adjust the reg properties accordingly. This requires adjusting the interrupt nexus nodes as well, as one field of the interrupt-map property depends on the GIC's address-size. Link: https://lore.kernel.org/r/20200513103016.130417-10-andre.przywara@arm.com Signed-off-by: Andre Przywara Signed-off-by: Sudeep Holla Signed-off-by: Sasha Levin commit a2a051fb9b5e5b82a8a83b7e14aabeeae0036bb1 Author: Marek Behún Date: Wed May 6 21:29:16 2020 +0200 arm64: dts: armada-3720-turris-mox: fix SFP binding [ Upstream commit c2671acbbbd822ef077cc168991e0a7dbe2172c9 ] The sfp compatible should be 'sff,sfp', not 'sff,sfp+'. We used patched kernel where the latter was working. Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox") Signed-off-by: Marek Behún Cc: Gregory CLEMENT Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit da5e18770052fd2fbc0f0e76dab699123c676df7 Author: Marek Behún Date: Fri May 1 01:11:44 2020 +0200 arm64: dts: armada-3720-turris-mox: forbid SDR104 on SDIO for FCC purposes [ Upstream commit 7a2c36b039d2343cc29fec6102da839477b8dc60 ] Use sdhci-caps-mask to forbid SDR104 mode on the SDIO capable SDHCI controller. Without this the device cannot pass electromagnetic interference certifications. Fixes: 7109d817db2e ("arm64: dts: marvell: add DTS for Turris Mox") Signed-off-by: Marek Behún Cc: Gregory CLEMENT Signed-off-by: Gregory CLEMENT Signed-off-by: Sasha Levin commit 9527654c0dbcb853809f9702406da09eb334858c Author: Martin Wilck Date: Mon Apr 20 22:29:09 2020 +0200 dm mpath: switch paths in dm_blk_ioctl() code path [ Upstream commit 2361ae595352dec015d14292f1b539242d8446d6 ] SCSI LUN passthrough code such as qemu's "scsi-block" device model pass every IO to the host via SG_IO ioctls. Currently, dm-multipath calls choose_pgpath() only in the block IO code path, not in the ioctl code path (unless current_pgpath is NULL). This has the effect that no path switching and thus no load balancing is done for SCSI-passthrough IO, unless the active path fails. Fix this by using the same logic in multipath_prepare_ioctl() as in multipath_clone_and_map(). Note: The allegedly best path selection algorithm, service-time, still wouldn't work perfectly, because the io size of the current request is always set to 0. Changing that for the IO passthrough case would require the ioctl cmd and arg to be passed to dm's prepare_ioctl() method. Signed-off-by: Martin Wilck Reviewed-by: Hannes Reinecke Signed-off-by: Mike Snitzer Signed-off-by: Sasha Levin commit 7c8f5590adb7d8bb50742297a356b48f9f9da22c Author: Srinivas Kandagatla Date: Tue May 12 12:09:30 2020 +0100 misc: fastrpc: fix potential fastrpc_invoke_ctx leak [ Upstream commit 74003385cf716f1b88cc7753ca282f5493f204a2 ] fastrpc_invoke_ctx can have refcount of 2 in error path where rpmsg_send() fails to send invoke message. decrement the refcount properly in the error path to fix this leak. This also fixes below static checker warning: drivers/misc/fastrpc.c:990 fastrpc_internal_invoke() warn: 'ctx->refcount.refcount.ref.counter' not decremented on lines: 990. Fixes: c68cfb718c8f ("misc: fastrpc: Add support for context") Reported-by: Dan Carpenter Signed-off-by: Srinivas Kandagatla Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20200512110930.2550-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 08936b2176ff35a0f04ebe833830d4fe0113c334 Author: Srinivas Kandagatla Date: Mon May 11 17:27:22 2020 +0100 misc: fastrpc: Fix an incomplete memory release in fastrpc_rpmsg_probe() [ Upstream commit 0978de9fc7335c73934ab8fac189fb4cb3f23191 ] fastrpc_channel_ctx is not freed if misc_register() fails, this would lead to a memory leak. Fix this leak by adding kfree in misc_register() error path. Fixes: 278d56f970ae ("misc: fastrpc: Reference count channel context") Signed-off-by: Srinivas Kandagatla Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20200511162722.2552-1-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit c318cf2f5006a29a90467bbe85344cb7be3cb737 Author: Michael Auchter Date: Mon May 11 15:50:41 2020 +0100 nvmem: ensure sysfs writes handle write-protect pin [ Upstream commit b96fc5416b099a0c2509ca07a80b140d34db2b9b ] Commit 2a127da461a9 ("nvmem: add support for the write-protect pin") added support for handling write-protect pins to the nvmem core, and Commit 1c89074bf850 ("eeprom: at24: remove the write-protect pin support") retrofitted the at24 driver to use this support. These changes broke write() on the nvmem sysfs attribute for eeproms which utilize a write-protect pin, as the write callback invokes the nvmem device's reg_write callback directly which no longer handles changing the state of the write-protect pin. Change the read and write callbacks for the sysfs attribute to invoke nvmme_reg_read/nvmem_reg_write helpers which handle this, rather than calling reg_read/reg_write directly. Fixes: 2a127da461a9 ("nvmem: add support for the write-protect pin") Signed-off-by: Michael Auchter Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20200511145042.31223-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit a0b87556acee782a45b73d1592e9e871d379b769 Author: Serge Semin Date: Thu May 7 02:31:32 2020 +0300 serial: 8250: Fix max baud limit in generic 8250 port [ Upstream commit 7b668c064ec33f3d687c3a413d05e355172e6c92 ] Standard 8250 UART ports are designed in a way so they can communicate with baud rates up to 1/16 of a reference frequency. It's expected from most of the currently supported UART controllers. That's why the former version of serial8250_get_baud_rate() method called uart_get_baud_rate() with min and max baud rates passed as (port->uartclk / 16 / UART_DIV_MAX) and ((port->uartclk + tolerance) / 16) respectively. Doing otherwise, like it was suggested in commit ("serial: 8250_mtk: support big baud rate."), caused acceptance of bauds, which was higher than the normal UART controllers actually supported. As a result if some user-space program requested to set a baud greater than (uartclk / 16) it would have been permitted without truncation, but then serial8250_get_divisor(baud) (which calls uart_get_divisor() to get the reference clock divisor) would have returned a zero divisor. Setting zero divisor will cause an unpredictable effect varying from chip to chip. In case of DW APB UART the communications just stop. Lets fix this problem by getting back the limitation of (uartclk + tolerance) / 16 maximum baud supported by the generic 8250 port. Mediatek 8250 UART ports driver developer shouldn't have touched it in the first place notably seeing he already provided a custom version of set_termios() callback in that glue-driver which took into account the extended baud rate values and accordingly updated the standard and vendor-specific divisor latch registers anyway. Fixes: 81bb549fdf14 ("serial: 8250_mtk: support big baud rate.") Signed-off-by: Serge Semin Cc: Alexey Malahov Cc: Thomas Bogendoerfer Cc: Paul Burton Cc: Ralf Baechle Cc: Arnd Bergmann Cc: Long Cheng Cc: Andy Shevchenko Cc: Maxime Ripard Cc: Catalin Marinas Cc: Will Deacon Cc: Russell King Cc: linux-mips@vger.kernel.org Cc: linux-arm-kernel@lists.infradead.org Cc: linux-mediatek@lists.infradead.org Link: https://lore.kernel.org/r/20200506233136.11842-2-Sergey.Semin@baikalelectronics.ru Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8829b0022d4d64582167c7ff65d33da9e67cd7fd Author: Bryan O'Donoghue Date: Fri May 8 17:29:37 2020 +0100 usb: roles: Switch on role-switch uevent reporting [ Upstream commit 3e63cff384e625f09758ce8f4d01ae3033402b63 ] Right now we don't report to user-space a role switch when doing a usb_role_switch_set_role() despite having registered the uevent callbacks. This patch switches on the notifications allowing user-space to see role-switch change notifications and subsequently determine the current controller data-role. example: PFX=/devices/platform/soc/78d9000.usb/ci_hdrc.0 root@somebox# udevadm monitor -p KERNEL[49.894994] change $PFX/usb_role/ci_hdrc.0-role-switch (usb_role) ACTION=change DEVPATH=$PFX/usb_role/ci_hdrc.0-role-switch SUBSYSTEM=usb_role DEVTYPE=usb_role_switch USB_ROLE_SWITCH=ci_hdrc.0-role-switch SEQNUM=2432 Cc: Heikki Krogerus Cc: Greg Kroah-Hartman Cc: Chunfeng Yun Cc: Suzuki K Poulose Cc: Alexandre Belloni Cc: Wen Yang Cc: chenqiwu Cc: linux-kernel@vger.kernel.org Signed-off-by: Bryan O'Donoghue Link: https://lore.kernel.org/r/20200508162937.2566818-1-bryan.odonoghue@linaro.org Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit b6bddb74c07b5de807e4f75623d58d8f9bdeb9d8 Author: Oliver Neukum Date: Thu May 7 10:58:06 2020 +0200 usblp: poison URBs upon disconnect [ Upstream commit 296a193b06120aa6ae7cf5c0d7b5e5b55968026e ] syzkaller reported an URB that should have been killed to be active. We do not understand it, but this should fix the issue if it is real. Signed-off-by: Oliver Neukum Reported-by: syzbot+be5b5f86a162a6c281e6@syzkaller.appspotmail.com Link: https://lore.kernel.org/r/20200507085806.5793-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit be66f10a60e3ec0b589898f78a428bcb34095730 Author: Jérôme Pouiller Date: Tue May 12 17:04:02 2020 +0200 staging: wfx: fix output of rx_stats on big endian hosts [ Upstream commit a823d6ecd4904e1a6ffb12964de88fb0bb4802f6 ] The struct hif_rx_stats contains only little endian values. Thus, it is necessary to fix byte ordering before to use them. Signed-off-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20200512150414.267198-6-Jerome.Pouiller@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 373a187be0b97e74d697be0c832aba99ee798667 Author: Marek Szyprowski Date: Wed May 6 15:26:58 2020 +0200 clk: samsung: Mark top ISP and CAM clocks on Exynos542x as critical [ Upstream commit e47bd937e602bb4379546095d1bd0b9871fa60c2 ] The TOP 'aclk*_isp', 'aclk550_cam', 'gscl_wa' and 'gscl_wb' clocks must be kept enabled all the time to allow proper access to power management control for the ISP and CAM power domains. The last two clocks, although related to GScaler device and GSCL power domain, provides also the I_WRAP_CLK signal to MIPI CSIS0/1 devices, which are a part of CAM power domain and are needed for proper power on/off sequence. Currently there are no drivers for the devices, which are part of CAM and ISP power domains yet. This patch only fixes the race between disabling the unused power domains and disabling unused clocks, which randomly resulted in the following error during boot: Power domain CAM disable failed Power domain ISP disable failed Fixes: 318fa46cc60d ("clk/samsung: exynos542x: mark some clocks as critical") Signed-off-by: Marek Szyprowski Acked-by: Chanwoo Choi Signed-off-by: Sylwester Nawrocki Signed-off-by: Sasha Levin commit 19f8bac059b1e2ad6f40d3e2ab7bd9598d56b3aa Author: Sibi Sankar Date: Wed Apr 15 12:46:18 2020 +0530 remoteproc: qcom_q6v5_mss: map/unmap mpss segments before/after use [ Upstream commit be050a3429f46ecf13eb2b80f299479f8bb823fb ] The application processor accessing the mpss region when the Q6 modem is running will lead to an XPU violation. Fix this by un-mapping the mpss segments post copy during mpss authentication and coredumps. Tested-by: Evan Green Signed-off-by: Sibi Sankar Link: https://lore.kernel.org/r/20200415071619.6052-1-sibis@codeaurora.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 34044514dc596c888fe898d953eef54e37990fab Author: Russell King Date: Wed May 6 10:36:38 2020 +0100 i2c: pxa: clear all master action bits in i2c_pxa_stop_message() [ Upstream commit e81c979f4e071d516aa27cf5a0c3939da00dc1ca ] If we timeout during a message transfer, the control register may contain bits that cause an action to be set. Read-modify-writing the register leaving these bits set may trigger the hardware to attempt one of these actions unintentionally. Always clear these bits when cleaning up after a message or after a timeout. Signed-off-by: Russell King Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 6ae31bb65682d2486dc6d481ed2fa986a49987d3 Author: Konstantin Khlebnikov Date: Mon May 11 09:15:18 2020 +0300 f2fs: report delalloc reserve as non-free in statfs for project quota [ Upstream commit baaa7ebf25c78c5cb712fac16b7f549100beddd3 ] This reserved space isn't committed yet but cannot be used for allocations. For userspace it has no difference from used space. See the same fix in ext4 commit f06925c73942 ("ext4: report delalloc reserve as non-free in statfs for project quota"). Fixes: ddc34e328d06 ("f2fs: introduce f2fs_statfs_project") Signed-off-by: Konstantin Khlebnikov Reviewed-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit f407e930f9029b5d7cff6a2b93607ad73525ee23 Author: Chao Yu Date: Sat May 9 15:01:04 2020 +0800 f2fs: compress: let lz4 compressor handle output buffer budget properly [ Upstream commit f6644143c63f2eac88973f7fea087582579b0189 ] Commonly, in order to handle lz4 worst compress case, caller should allocate buffer with size of LZ4_compressBound(inputsize) for target compressed data storing, however in this case, if caller didn't allocate enough space, lz4 compressor still can handle output buffer budget properly, and end up compressing when left space in output buffer is not enough. So we don't have to allocate buffer with size for worst case, then we can avoid 2 * 4KB size intermediate buffer allocation when log_cluster_size is 2, and avoid unnecessary compressing work of compressor if we can not save at least 4KB space. Suggested-by: Daeho Jeong Signed-off-by: Chao Yu Signed-off-by: Jaegeuk Kim Signed-off-by: Sasha Levin commit 5ba031e31c7a73f89d79e7af873cba9ba2b78017 Author: Andreas Klinger Date: Mon May 4 20:10:34 2020 +0200 iio: bmp280: fix compensation of humidity [ Upstream commit dee2dabc0e4115b80945fe2c91603e634f4b4686 ] Limit the output of humidity compensation to the range between 0 and 100 percent. Depending on the calibration parameters of the individual sensor it happens, that a humidity above 100 percent or below 0 percent is calculated, which don't make sense in terms of relative humidity. Add a clamp to the compensation formula as described in the datasheet of the sensor in chapter 4.2.3. Although this clamp is documented, it was never in the driver of the kernel. It depends on the circumstances (calibration parameters, temperature, humidity) if one can see a value above 100 percent without the clamp. The writer of this patch was working with this type of sensor without noting this error. So it seems to be a rare event when this bug occures. Signed-off-by: Andreas Klinger Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 4d08eb5071407265108753ac6d89b4fc72f18a7b Author: Qiushi Wu Date: Sun May 3 13:22:35 2020 -0500 rtc: mc13xxx: fix a double-unlock issue [ Upstream commit 8816cd726a4fee197af2d851cbe25991ae19ea14 ] In function mc13xxx_rtc_probe, the mc13xxx_unlock() is called before rtc_register_device(). But in the error path of rtc_register_device(), the mc13xxx_unlock() is called again, which causes a double-unlock problem. Thus add a call of the function “mc13xxx_lock” in an if branch for the completion of the exception handling. Fixes: e4ae7023e182a ("rtc: mc13xxx: set range") Signed-off-by: Qiushi Wu Link: https://lore.kernel.org/r/20200503182235.1652-1-wu000273@umn.edu Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit ddaa88123713429ae836c65515a79cd49d59aa84 Author: Christophe Leroy Date: Wed Apr 8 15:58:49 2020 +0000 powerpc/kasan: Fix stack overflow by increasing THREAD_SHIFT [ Upstream commit edbadaf0671072298e506074128b64e003c5812c ] When CONFIG_KASAN is selected, the stack usage is increased. In the same way as x86 and arm64 architectures, increase THREAD_SHIFT when CONFIG_KASAN is selected. Fixes: 2edb16efc899 ("powerpc/32: Add KASAN support") Reported-by: Signed-off-by: Christophe Leroy Signed-off-by: Michael Ellerman Link: https://bugzilla.kernel.org/show_bug.cgi?id=207129 Link: https://lore.kernel.org/r/2c50f3b1c9bbaa4217c9a98f3044bd2a36c46a4f.1586361277.git.christophe.leroy@c-s.fr Signed-off-by: Sasha Levin commit cb76ffb5e5e3ee514a2cf216d8dccc0d529ef6be Author: Jim Quinlan Date: Thu May 7 16:15:41 2020 -0400 PCI: brcmstb: Fix window register offset from 4 to 8 [ Upstream commit 077a4fa92a615a4d0f86eae68d777b9dd5e5a95b ] The outbound memory window registers were being referenced with an incorrect stride offset. This probably wasn't noticed previously as there was likely only one such window employed. Link: https://lore.kernel.org/r/20200507201544.43432-3-james.quinlan@broadcom.com Fixes: c0452137034b ("PCI: brcmstb: Add Broadcom STB PCIe host controller driver") Signed-off-by: Jim Quinlan Signed-off-by: Lorenzo Pieralisi Acked-by: Florian Fainelli Acked-by: Nicolas Saenz Julienne Signed-off-by: Sasha Levin commit e3c59cbeb86a349c60b92181998753fb7f139d92 Author: Marco Felsch Date: Sat May 9 14:34:35 2020 -0700 Input: edt-ft5x06 - fix get_default register write access [ Upstream commit 255cdaf73412de13608fb776101402dca68bed2b ] Since commit b6eba86030bf ("Input: edt-ft5x06 - add offset support for ev-ft5726") offset-x and offset-y is supported. Devices using those offset parameters don't support the offset parameter so we need to add the NO_REGISTER check for edt_ft5x06_ts_get_defaults(). Fixes: b6eba86030bf ("Input: edt-ft5x06 - add offset support for ev-ft5726") Signed-off-by: Marco Felsch Link: https://lore.kernel.org/r/20200227112819.16754-2-m.felsch@pengutronix.de Signed-off-by: Dmitry Torokhov Signed-off-by: Sasha Levin commit b6dc7dd590a068de632485af641d482a6f0e6028 Author: Viacheslav Dubeyko Date: Wed Apr 22 13:55:52 2020 +0300 scsi: qla2xxx: Fix issue with adapter's stopping state [ Upstream commit 803e45550b11c8e43d89812356fe6f105adebdf9 ] The goal of the following command sequence is to restart the adapter. However, the tgt_stop flag remains set, indicating that the adapter is still in stopping state even after re-enabling it. echo 0x7fffffff > /sys/module/qla2xxx/parameters/logging modprobe target_core_mod modprobe tcm_qla2xxx mkdir /sys/kernel/config/target/qla2xxx mkdir /sys/kernel/config/target/qla2xxx/ mkdir /sys/kernel/config/target/qla2xxx//tpgt_1 echo 1 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable echo 0 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable echo 1 > /sys/kernel/config/target/qla2xxx//tpgt_1/enable kernel: PID 1396:qla_target.c:1555 qlt_stop_phase1(): tgt_stop 0x0, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-e803:1: PID 1396:qla_target.c:1567: Stopping target for host 1(c0000000033557e8) kernel: PID 1396:qla_target.c:1579 qlt_stop_phase1(): tgt_stop 0x1, tgt_stopped 0x0 kernel: PID 1396:qla_target.c:1266 qlt_schedule_sess_for_deletion(): tgt_stop 0x1, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-e801:1: PID 1396:qla_target.c:1316: Scheduling sess c00000002d5cd800 for deletion 21:00:00:24:ff:7f:35:c7 kernel: qla2xxx [0001:00:02.0]-290a:1: PID 340:qla_target.c:1187: qlt_unreg_sess sess c00000002d5cd800 for deletion 21:00:00:24:ff:7f:35:c7 kernel: qla2xxx [0001:00:02.0]-f801:1: PID 340:qla_target.c:1145: Unregistration of sess c00000002d5cd800 21:00:00:24:ff:7f:35:c7 finished fcp_cnt 0 kernel: PID 340:qla_target.c:1155 qlt_free_session_done(): tgt_stop 0x1, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-4807:1: PID 346:qla_os.c:6329: ISP abort scheduled. kernel: qla2xxx [0001:00:02.0]-28f1:1: PID 346:qla_os.c:3956: Mark all dev lost kernel: PID 346:qla_target.c:1266 qlt_schedule_sess_for_deletion(): tgt_stop 0x1, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-4808:1: PID 346:qla_os.c:6338: ISP abort end. kernel: PID 1396:qla_target.c:6812 qlt_enable_vha(): tgt_stop 0x1, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-4807:1: PID 346:qla_os.c:6329: ISP abort scheduled. kernel: qla2xxx [0001:00:02.0]-4808:1: PID 346:qla_os.c:6338: ISP abort end. qlt_handle_cmd_for_atio() rejects the request to send commands because the adapter is in the stopping state: kernel: PID 0:qla_target.c:4442 qlt_handle_cmd_for_atio(): tgt_stop 0x1, tgt_stopped 0x0 kernel: qla2xxx [0001:00:02.0]-3861:1: PID 0:qla_target.c:4447: New command while device c000000005314600 is shutting down kernel: qla2xxx [0001:00:02.0]-e85f:1: PID 0:qla_target.c:5728: qla_target: Unable to send command to target This patch calls qla_stop_phase2() in addition to qlt_stop_phase1() in tcm_qla2xxx_tpg_enable_store() and tcm_qla2xxx_npiv_tpg_enable_store(). The qlt_stop_phase1() marks adapter as stopping (tgt_stop == 0x1, tgt_stopped == 0x0) but qlt_stop_phase2() marks adapter as stopped (tgt_stop == 0x0, tgt_stopped == 0x1). Link: https://lore.kernel.org/r/52be1e8a3537f6c5407eae3edd4c8e08a9545ea5.camel@yadro.com Reviewed-by: Roman Bolshakov Reviewed-by: Himanshu Madhani Signed-off-by: Viacheslav Dubeyko Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit f094489933b58f65d4e83ce4496bc0456c79b145 Author: Kunihiko Hayashi Date: Wed Apr 22 16:24:47 2020 +0900 PCI: endpoint: functions/pci-epf-test: Fix DMA channel release [ Upstream commit 0e86d981f9b7252e9716c5137cd8e4d9ad8ef32f ] When unbinding pci_epf_test, pci_epf_test_clean_dma_chan() is called in pci_epf_test_unbind() even though epf_test->dma_supported is false. As a result, dma_release_channel() will trigger a NULL pointer dereference because dma_chan is not set. Avoid calling dma_release_channel() if epf_test->dma_supported is false. Link: https://lore.kernel.org/r/1587540287-10458-1-git-send-email-hayashi.kunihiko@socionext.com Fixes: 5ebf3fc59bd2 ("PCI: endpoint: functions/pci-epf-test: Add DMA support to transfer data") Signed-off-by: Kunihiko Hayashi [lorenzo.pieralisi@arm.com: commit log] Signed-off-by: Lorenzo Pieralisi Acked-by: Kishon Vijay Abraham I Signed-off-by: Sasha Levin commit 5294d139bd5f17eaecee1d0252764ac6d26edcc8 Author: Ard Biesheuvel Date: Tue Apr 21 18:22:56 2020 +0200 PCI: Allow pci_resize_resource() for devices on root bus [ Upstream commit d09ddd8190fbdc07696bf34b548ae15aa1816714 ] When resizing a BAR, pci_reassign_bridge_resources() is invoked to bring the bridge windows of parent bridges in line with the new BAR assignment. This assumes the device whose BAR is being resized lives on a subordinate bus, but this is not necessarily the case. A device may live on the root bus, in which case dev->bus->self is NULL, and passing a NULL pci_dev pointer to pci_reassign_bridge_resources() will cause it to crash. So let's make the call to pci_reassign_bridge_resources() conditional on whether dev->bus->self is non-NULL in the first place. Fixes: 8bb705e3e79d84e7 ("PCI: Add pci_resize_resource() for resizing BARs") Link: https://lore.kernel.org/r/20200421162256.26887-1-ardb@kernel.org Signed-off-by: Ard Biesheuvel Signed-off-by: Bjorn Helgaas Reviewed-by: Christian König Signed-off-by: Sasha Levin commit 9ab21eb86cc0e411876cf28d5a1b93f6cbdeb29c Author: Dan Carpenter Date: Fri May 1 12:40:11 2020 +0300 ALSA: isa/wavefront: prevent out of bounds write in ioctl [ Upstream commit 7f0d5053c5a9d23fe5c2d337495a9d79038d267b ] The "header->number" comes from the ioctl and it needs to be clamped to prevent out of bounds writes. Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20200501094011.GA960082@mwanda Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit ace05ed6d9564627e2b239b67b1de3605f147c6b Author: Kai-Heng Feng Date: Thu Apr 30 16:32:51 2020 +0800 ALSA: hda/realtek - Introduce polarity for micmute LED GPIO [ Upstream commit dbd13179780555ecd3c992dea1222ca31920e892 ] Currently mute LED and micmute LED share the same GPIO polarity. So split the polarity for mute and micmute, in case they have different polarities. Signed-off-by: Kai-Heng Feng Link: https://lore.kernel.org/r/20200430083255.5093-1-kai.heng.feng@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 56fe6059e1755a810a9054afe0e0be977731ddbd Author: Neil Armstrong Date: Thu Mar 26 17:59:55 2020 +0100 arm64: dts: meson: fixup SCP sram nodes [ Upstream commit 9ecded10b4b6af238da0c86197b0418912e7513e ] The GX and AXG SCP sram nodes were using invalid compatible and node names for the sram entries. Fixup the sram entries node names, and use proper compatible for them. It notably fixes: sram@c8000000: 'scp-shmem@0', 'scp-shmem@200' do not match any of the regexes: '^([a-z]*-)?sram(-section)?@[a-f0-9]+$', 'pinctrl-[0-9]+' Signed-off-by: Neil Armstrong Signed-off-by: Kevin Hilman Link: https://lore.kernel.org/r/20200326165958.19274-3-narmstrong@baylibre.com Signed-off-by: Sasha Levin commit eec49d4c04721dbc39cb6b4f7cf929d7f6458310 Author: Dan Carpenter Date: Tue Apr 28 16:19:39 2020 +0300 scsi: qedi: Check for buffer overflow in qedi_set_path() [ Upstream commit 4a4c0cfb4be74e216dd4446b254594707455bfc6 ] Smatch complains that the "path_data->handle" variable is user controlled. It comes from iscsi_set_path() so that seems possible. It's harmless to add a limit check. The qedi->ep_tbl[] array has qedi->max_active_conns elements (which is always ISCSI_MAX_SESS_PER_HBA (4096) elements). The array is allocated in the qedi_cm_alloc_mem() function. Link: https://lore.kernel.org/r/20200428131939.GA696531@mwanda Fixes: ace7f46ba5fd ("scsi: qedi: Add QLogic FastLinQ offload iSCSI driver framework.") Acked-by: Manish Rangankar Signed-off-by: Dan Carpenter Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5b5f5abdbcd7defd4942718f52eaba9da7305169 Author: Johannes Thumshirn Date: Tue Apr 28 19:45:55 2020 +0900 scsi: core: free sgtables in case command setup fails [ Upstream commit 20a66f2bf280277ab5bb22e27445153b4eb0ac88 ] In case scsi_setup_fs_cmnd() fails we're not freeing the sgtables allocated by scsi_init_io(), thus we leak the allocated memory. Free the sgtables allocated by scsi_init_io() in case scsi_setup_fs_cmnd() fails. Technically scsi_setup_scsi_cmnd() does not suffer from this problem as it can only fail if scsi_init_io() fails, so it does not have sgtables allocated. But to maintain symmetry and as a measure of defensive programming, free the sgtables on scsi_setup_scsi_cmnd() failure as well. scsi_mq_free_sgtables() has safeguards against double-freeing of memory so this is safe to do. While we're at it, rename scsi_mq_free_sgtables() to scsi_free_sgtables(). Link: https://bugzilla.kernel.org/show_bug.cgi?id=205595 Link: https://lore.kernel.org/r/20200428104605.8143-2-johannes.thumshirn@wdc.com Reviewed-by: Christoph Hellwig Reviewed-by: Daniel Wagner Reviewed-by: Hannes Reinecke Signed-off-by: Johannes Thumshirn Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 62afba0d312e80af699854e1314fb933c3f62bb0 Author: Neil Armstrong Date: Thu Mar 26 17:59:57 2020 +0100 arm64: dts: meson-gxbb-kii-pro: fix board compatible [ Upstream commit d120b5f98031eefc22164ae8c6ea3711e7a04c19 ] Remove the uneeded "amlogic,p201", "amlogic,s905" in the board compatible list. It fixes: meson-gxbb-kii-pro.dt.yaml: /: compatible: ['videostrong,kii-pro', 'amlogic,p201', 'amlogic,s905', 'amlogic,meson-gxbb'] is not valid under any of the given schemas Signed-off-by: Neil Armstrong Signed-off-by: Kevin Hilman Link: https://lore.kernel.org/r/20200326165958.19274-5-narmstrong@baylibre.com Signed-off-by: Sasha Levin commit eac5dd33c734a083a22d60e0f6cd1d1070db2b62 Author: Arnd Bergmann Date: Tue Apr 28 23:26:59 2020 +0200 ASoC: codecs: wm97xx: fix ac97 dependency [ Upstream commit ee2cbe06935bfa58f1fe07dc2a2283945f4b97dc ] A recent build fix got the dependency slightly wrong, breaking builds with CONFIG_AC97_BUS_NEW: WARNING: unmet direct dependencies detected for SND_SOC_WM9713 Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_AC97_BUS [=n] Selected by [m]: - SND_SOC_ZYLONITE [=m] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_PXA2XX_SOC [=m] && MACH_ZYLONITE [=y] && AC97_BUS [=n]=n WARNING: unmet direct dependencies detected for SND_SOC_WM9712 Depends on [n]: SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_SOC_AC97_BUS [=n] Selected by [m]: - SND_PXA2XX_SOC_EM_X270 [=m] && SOUND [=y] && !UML && SND [=y] && SND_SOC [=y] && SND_PXA2XX_SOC [=m] && (MACH_EM_X270 [=n] || MACH_EXEDA [=n] || MACH_CM_X300 [=y]) && AC97_BUS [=n]=n Change the dependency to allow either version of the AC97 library code. Fixes: 5a309875787d ("ASoC: Fix SND_SOC_ALL_CODECS imply ac97 fallout") Signed-off-by: Arnd Bergmann Acked-by: Charles Keepax Link: https://lore.kernel.org/r/20200428212721.2877627-1-arnd@arndb.de Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 7eaabdcfa470233ad0624fd00b50ae1926b7ff29 Author: Yoshihiro Shimoda Date: Tue Apr 21 18:36:15 2020 +0900 arm64: dts: renesas: Fix IOMMU device node names [ Upstream commit cf8ae446bbcbf5c48214eb7ddaa6ac6e12f4633d ] Fix IOMMU device node names as "iommu@". Fixes: 8f507babc617 ("arm64: dts: renesas: r8a774a1: Add IPMMU device nodes") Fixes: 63093a8e58be ("arm64: dts: renesas: r8a774b1: Add IPMMU device nodes") Fixes: 6c7e02178e8f ("arm64: dts: renesas: r8a774c0: Add IPMMU device nodes") Fixes: 3b7e7848f0e8 ("arm64: dts: renesas: r8a7795: Add IPMMU device nodes") Fixes: e4b9a493df45 ("arm64: dts: renesas: r8a7795-es1: Add IPMMU device nodes") Fixes: 389baa409617 ("arm64: dts: renesas: r8a7796: Add IPMMU device nodes") Fixes: 55697cbb44e4 ("arm64: dts: renesas: r8a779{65,80,90}: Add IPMMU devices nodes") Fixes: ce3b52a1595b ("arm64: dts: renesas: r8a77970: Add IPMMU device nodes") Fixes: a3901e7398e1 ("arm64: dts: renesas: r8a77995: Add IPMMU device nodes") Signed-off-by: Yoshihiro Shimoda Reviewed-by: Niklas Söderlund Link: https://lore.kernel.org/r/1587461775-13369-1-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 0ddf20892c7854cfcb7e0657806b411f9e7badba Author: Marek Vasut Date: Wed Apr 22 12:45:58 2020 +0200 ARM: dts: stm32: Add missing ethernet PHY reset on AV96 [ Upstream commit 010ca9fe500bfe365860b50220ff80541c18f0e1 ] Add PHY reset GPIO on AV96 ethernet PHY. Reviewed-by: Manivannan Sadhasivam Signed-off-by: Marek Vasut Cc: Alexandre Torgue Cc: Manivannan Sadhasivam Cc: Maxime Coquelin Cc: Patrice Chotard Cc: Patrick Delaunay Cc: linux-stm32@st-md-mailman.stormreply.com To: linux-arm-kernel@lists.infradead.org Signed-off-by: Alexandre Torgue Signed-off-by: Sasha Levin commit b5c5358d447b110ed0d7012193dc64992b1c458e Author: Linus Walleij Date: Thu Feb 13 15:27:54 2020 +0100 ARM: integrator: Add some Kconfig selections [ Upstream commit d2854bbe5f5c4b4bec8061caf4f2e603d8819446 ] The CMA and DMA_CMA Kconfig options need to be selected by the Integrator in order to produce boot console on some Integrator systems. The REGULATOR and REGULATOR_FIXED_VOLTAGE need to be selected in order to boot the system from an external MMC card when using MMCI/PL181 from the device tree probe path. Select these things directly from the Kconfig so we are sure to be able to bring the systems up with console from any device tree. Signed-off-by: Linus Walleij Signed-off-by: Sasha Levin commit 5f7745f3e21f44eab5a842c9a0961007f3f9e09b Author: Xiyu Yang Date: Sat Apr 25 20:48:35 2020 +0800 ASoC: davinci-mcasp: Fix dma_chan refcnt leak when getting dma type [ Upstream commit a697ae6ea56e23397341b027098c1b11d9ab13da ] davinci_mcasp_get_dma_type() invokes dma_request_chan(), which returns a reference of the specified dma_chan object to "chan" with increased refcnt. When davinci_mcasp_get_dma_type() returns, local variable "chan" becomes invalid, so the refcount should be decreased to keep refcount balanced. The reference counting issue happens in one exception handling path of davinci_mcasp_get_dma_type(). When chan device is NULL, the function forgets to decrease the refcnt increased by dma_request_chan(), causing a refcnt leak. Fix this issue by calling dma_release_channel() when chan device is NULL. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Acked-by: Peter Ujfalusi Link: https://lore.kernel.org/r/1587818916-38730-1-git-send-email-xiyuyang19@fudan.edu.cn Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit c7cb7fde8440a165a8a1df2563c750dea34c23ce Author: Yoshihiro Shimoda Date: Tue Apr 21 18:35:56 2020 +0900 ARM: dts: renesas: Fix IOMMU device node names [ Upstream commit ae990a1de014396ffc8d0fcc31b6888c9b0ce59a ] Fix IOMMU device node names as "iommu@". Fixes: bbb44da0b595 ("ARM: dts: r8a7743: Add IPMMU DT nodes") Fixes: 0dcba3de5835 ("ARM: dts: r8a7745: Add IPMMU DT nodes") Fixes: 350ae49b97c4 ("ARM: dts: r8a7744: Add IPMMU DT nodes") Fixes: 70496727c082 ("ARM: shmobile: r8a7790: Add IPMMU DT nodes") Fixes: f1951852ed17 ("ARM: shmobile: r8a7791: Add IPMMU DT nodes") Fixes: 098cb3a601e6 ("ARM: shmobile: r8a7793: Add IPMMU nodes") Fixes: 1cb2794f6082 ("ARM: shmobile: r8a7794: Add IPMMU DT nodes") Signed-off-by: Yoshihiro Shimoda Reviewed-by: Niklas Söderlund Link: https://lore.kernel.org/r/1587461756-13317-1-git-send-email-yoshihiro.shimoda.uh@renesas.com Signed-off-by: Geert Uytterhoeven Signed-off-by: Sasha Levin commit 0648694b0bcd1d130ec000e022fe309542bbf8c8 Author: Jon Hunter Date: Mon Feb 24 14:07:48 2020 +0000 backlight: lp855x: Ensure regulators are disabled on probe failure [ Upstream commit d8207c155a7c6015eb7f43739baa7dfb1fa638af ] If probing the LP885x backlight fails after the regulators have been enabled, then the following warning is seen when releasing the regulators ... WARNING: CPU: 1 PID: 289 at drivers/regulator/core.c:2051 _regulator_put.part.28+0x158/0x160 Modules linked in: tegra_xudc lp855x_bl(+) host1x pwm_tegra ip_tables x_tables ipv6 nf_defrag_ipv6 CPU: 1 PID: 289 Comm: systemd-udevd Not tainted 5.6.0-rc2-next-20200224 #1 Hardware name: NVIDIA Jetson TX1 Developer Kit (DT) ... Call trace: _regulator_put.part.28+0x158/0x160 regulator_put+0x34/0x50 devm_regulator_release+0x10/0x18 release_nodes+0x12c/0x230 devres_release_all+0x34/0x50 really_probe+0x1c0/0x370 driver_probe_device+0x58/0x100 device_driver_attach+0x6c/0x78 __driver_attach+0xb0/0xf0 bus_for_each_dev+0x68/0xc8 driver_attach+0x20/0x28 bus_add_driver+0x160/0x1f0 driver_register+0x60/0x110 i2c_register_driver+0x40/0x80 lp855x_driver_init+0x20/0x1000 [lp855x_bl] do_one_initcall+0x58/0x1a0 do_init_module+0x54/0x1d0 load_module+0x1d80/0x21c8 __do_sys_finit_module+0xe8/0x100 __arm64_sys_finit_module+0x18/0x20 el0_svc_common.constprop.3+0xb0/0x168 do_el0_svc+0x20/0x98 el0_sync_handler+0xf4/0x1b0 el0_sync+0x140/0x180 Fix this by ensuring that the regulators are disabled, if enabled, on probe failure. Finally, ensure that the vddio regulator is disabled in the driver remove handler. Signed-off-by: Jon Hunter Reviewed-by: Daniel Thompson Signed-off-by: Lee Jones Signed-off-by: Sasha Levin commit 83ea70e2e12f90b68cb57d0c0ac5aec33e3ae3e6 Author: Shengjiu Wang Date: Mon Apr 27 14:23:21 2020 +0800 ASoC: fsl_esai: Disable exception interrupt before scheduling tasklet [ Upstream commit 1fecbb71fe0e46b886f84e3b6decca6643c3af6d ] Disable exception interrupt before scheduling tasklet, otherwise if the tasklet isn't handled immediately, there will be endless xrun interrupt. Fixes: 7ccafa2b3879 ("ASoC: fsl_esai: recover the channel swap after xrun") Signed-off-by: Shengjiu Wang Acked-by: Nicolin Chen Link: https://lore.kernel.org/r/a8f2ad955aac9e52587beedc1133b3efbe746895.1587968824.git.shengjiu.wang@nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 712ee450ee813cae50c3898f0f2d300642456b0f Author: Dan Carpenter Date: Fri Apr 24 13:42:35 2020 +0300 staging: wfx: check ssidlen and prevent an array overflow [ Upstream commit 87f86cddda65cab8a7e3df8a00e16abeccaa0730 ] We need to cap "ssidlen" to prevent a memcpy() overflow. Fixes: 40115bbc40e2 ("staging: wfx: implement the rest of mac80211 API") Signed-off-by: Dan Carpenter Reviewed-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20200424104235.GA416402@mwanda Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin commit 8cb970b28aca1b33149407680cce5eef7a3f8084 Author: Bryan O'Donoghue Date: Sun Mar 29 13:41:16 2020 +0100 clk: qcom: msm8916: Fix the address location of pll->config_reg [ Upstream commit f47ab3c2f5338828a67e89d5f688d2cef9605245 ] During the process of debugging a processor derived from the msm8916 which we found the new processor was not starting one of its PLLs. After tracing the addresses and writes that downstream was doing and comparing to upstream it became obvious that we were writing to a different register location than downstream when trying to configure the PLL. This error is also present in upstream msm8916. As an example clk-pll.c::clk_pll_recalc_rate wants to write to pll->config_reg updating the bit-field POST_DIV_RATIO. That bit-field is defined in PLL_USER_CTL not in PLL_CONFIG_CTL. Taking the BIMC PLL as an example lm80-p0436-13_c_qc_snapdragon_410_processor_hrd.pdf 0x01823010 GCC_BIMC_PLL_USER_CTL 0x01823014 GCC_BIMC_PLL_CONFIG_CTL This pattern is repeated for gpll0, gpll1, gpll2 and bimc_pll. This error is likely not apparent since the bootloader will already have initialized these PLLs. This patch corrects the location of config_reg from PLL_CONFIG_CTL to PLL_USER_CTL for all relevant PLLs on msm8916. Fixes commit 3966fab8b6ab ("clk: qcom: Add MSM8916 Global Clock Controller support") Cc: Georgi Djakov Cc: Andy Gross Cc: Bjorn Andersson Cc: Michael Turquette Cc: Stephen Boyd Signed-off-by: Bryan O'Donoghue Link: https://lkml.kernel.org/r/20200329124116.4185447-1-bryan.odonoghue@linaro.org Signed-off-by: Stephen Boyd Signed-off-by: Sasha Levin commit 309a91f23e8feb56ff8091a6e38e232b28502a88 Author: Alex Elder Date: Wed Apr 15 14:48:52 2020 -0600 remoteproc: Fix IDR initialisation in rproc_alloc() [ Upstream commit 6442df49400b466431979e7634849a464a5f1861 ] If ida_simple_get() returns an error when called in rproc_alloc(), put_device() is called to clean things up. By this time the rproc device type has been assigned, with rproc_type_release() as the release function. The first thing rproc_type_release() does is call: idr_destroy(&rproc->notifyids); But at the time the ida_simple_get() call is made, the notifyids field in the remoteproc structure has not been initialized. I'm not actually sure this case causes an observable problem, but it's incorrect. Fix this by initializing the notifyids field before calling ida_simple_get() in rproc_alloc(). Fixes: b5ab5e24e960 ("remoteproc: maintain a generic child device for each rproc") Signed-off-by: Alex Elder Reviewed-by: Mathieu Poirier Reviewed-by: Suman Anna Reviewed-by: Bjorn Andersson Link: https://lore.kernel.org/r/20200415204858.2448-2-mathieu.poirier@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit b03ce95fe47cfc49b58b742509f3a6d3494644f8 Author: Andy Shevchenko Date: Mon Mar 23 12:41:25 2020 +0200 iio: pressure: bmp280: Tolerate IRQ before registering [ Upstream commit 97b31a6f5fb95b1ec6575b78a7240baddba34384 ] With DEBUG_SHIRQ enabled we have a kernel crash [ 116.482696] BUG: kernel NULL pointer dereference, address: 0000000000000000 ... [ 116.606571] Call Trace: [ 116.609023] [ 116.611047] complete+0x34/0x50 [ 116.614206] bmp085_eoc_irq+0x9/0x10 [bmp280] because DEBUG_SHIRQ mechanism fires an IRQ before registration and drivers ought to be able to handle an interrupt happening before request_irq() returns. Fixes: aae953949651 ("iio: pressure: bmp280: add support for BMP085 EOC interrupt") Signed-off-by: Andy Shevchenko Acked-by: Linus Walleij Signed-off-by: Jonathan Cameron Signed-off-by: Sasha Levin commit 170f9793411470b347d30faf04f6180901f99265 Author: YueHaibing Date: Thu Apr 9 10:18:28 2020 +0300 ASoC: SOF: imx8: Fix randbuild error [ Upstream commit fe17e6cdc0fefca96ba9659be4b2b07487cbf0c5 ] when do randconfig like this: CONFIG_SND_SOC_SOF_IMX8_SUPPORT=y CONFIG_SND_SOC_SOF_IMX8=y CONFIG_SND_SOC_SOF_OF=y CONFIG_IMX_DSP=m CONFIG_IMX_SCU=y there is a link error: sound/soc/sof/imx/imx8.o: In function 'imx8_send_msg': imx8.c:(.text+0x380): undefined reference to 'imx_dsp_ring_doorbell' Select IMX_DSP in SND_SOC_SOF_IMX8_SUPPORT to fix this Fixes: f9ad75468453 ("ASoC: SOF: imx: fix reverse CONFIG_SND_SOC_SOF_OF dependency") Reported-by: Hulk Robot Signed-off-by: YueHaibing Signed-off-by: Daniel Baluta Link: https://lore.kernel.org/r/20200409071832.2039-2-daniel.baluta@oss.nxp.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2c54a161da19bc8d71a6908c7a0bcd339aa7a972 Author: Adam Honse Date: Fri Apr 10 15:48:44 2020 -0500 i2c: piix4: Detect secondary SMBus controller on AMD AM4 chipsets [ Upstream commit f27237c174fd9653033330e4e532cd9d153ce824 ] The AMD X370 and other AM4 chipsets (A/B/X 3/4/5 parts) and Threadripper equivalents have a secondary SMBus controller at I/O port address 0x0B20. This bus is used by several manufacturers to control motherboard RGB lighting via embedded controllers. I have been using this bus in my OpenRGB project to control the Aura RGB on many motherboards and ASRock also uses this bus for their Polychrome RGB controller. I am not aware of any CZ-compatible platforms which do not have the second SMBus channel. All of AMD's AM4- and Threadripper- series chipsets that OpenRGB users have tested appear to have this secondary bus. I also noticed this secondary bus is present on older AMD platforms including my FM1 home server. Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=202587 Signed-off-by: Adam Honse Reviewed-by: Jean Delvare Reviewed-by: Sebastian Reichel Tested-by: Sebastian Reichel Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit fa1482c4f522ef394207f310f7015f9b4fc06c9a Author: Dan Carpenter Date: Tue Apr 7 12:28:52 2020 +0300 rtc: rc5t619: Fix an ERR_PTR vs NULL check [ Upstream commit 11ddbdfb68e4f9791e4bd4f8d7c87d3f19670967 ] The devm_kzalloc() function returns NULL on error, it doesn't return error pointers so this check doesn't work. Fixes: 540d1e15393d ("rtc: rc5t619: Add Ricoh RC5T619 RTC driver") Signed-off-by: Dan Carpenter Link: https://lore.kernel.org/r/20200407092852.GI68494@mwanda Signed-off-by: Alexandre Belloni Signed-off-by: Sasha Levin commit efdcc5c80262aef339d0b7f2b50ce5fbdfc047ba Author: Dmitry Osipenko Date: Mon Mar 30 23:40:11 2020 +0300 ASoC: tegra: tegra_wm8903: Support nvidia, headset property [ Upstream commit 3ef9d5073b552d56bd6daf2af1e89b7e8d4df183 ] The microphone-jack state needs to be masked in a case of a 4-pin jack when microphone and ground pins are shorted. Presence of nvidia,headset tells that WM8903 CODEC driver should mask microphone's status if short circuit is detected, i.e headphones are inserted. Signed-off-by: Dmitry Osipenko Link: https://lore.kernel.org/r/20200330204011.18465-3-digetx@gmail.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 59b76e6d667985e0c19c57e84d15a62a78a5c730 Author: Rikard Falkeborn Date: Tue Mar 17 22:13:32 2020 +0100 clk: sunxi: Fix incorrect usage of round_down() [ Upstream commit ee25d9742dabed3fd18158b518f846abeb70f319 ] round_down() can only round to powers of 2. If round_down() is asked to round to something that is not a power of 2, incorrect results are produced. The incorrect results can be both too large and too small. Instead, use rounddown() which can round to any number. Fixes: 6a721db180a2 ("clk: sunxi: Add A31 clocks support") Signed-off-by: Rikard Falkeborn Signed-off-by: Maxime Ripard Signed-off-by: Sasha Levin commit 27bc8ad4802919d89c5c7ce5e67d6f110165047a Author: Enric Balletbo i Serra Date: Mon Apr 13 16:10:51 2020 +0200 power: supply: bq24257_charger: Replace depends on REGMAP_I2C with select [ Upstream commit 87c3d579c8ed0eaea6b1567d529a8daa85a2bc6c ] regmap is a library function that gets selected by drivers that need it. No driver modules should depend on it. Depending on REGMAP_I2C makes this driver only build if another driver already selected REGMAP_I2C, as the symbol can't be selected through the menu kernel configuration. Fixes: 2219a935963e ("power_supply: Add TI BQ24257 charger driver") Signed-off-by: Enric Balletbo i Serra Signed-off-by: Sebastian Reichel Signed-off-by: Sasha Levin commit 10a70b7893be02b4ca146c692ac9e683b1f550f6 Author: Jérôme Pouiller Date: Wed Apr 1 13:04:03 2020 +0200 staging: wfx: fix potential deadlock in wfx_tx_flush() [ Upstream commit a39e761aa4fefa2a8aaf549217329933b91da7c9 ] wfx_tx_flush() wait there are no more frame in device buffer. However, this event may never happens since wfx_tx_flush() don't forbid to enqueue new frames. Note that wfx_tx_flush() should only ensure that all frames currently in hardware queues are sent. So the current code is more restrictive that it should. Note that wfx_tx_flush() release the lock before to return while wfx_tx_lock_flush() keep the lock. Reviewed-by: Dan Carpenter Signed-off-by: Jérôme Pouiller Link: https://lore.kernel.org/r/20200401110405.80282-31-Jerome.Pouiller@silabs.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin