commit 19bfeb47e96bb342d8c43a8ba0e68baf053b0dfc Author: Greg Kroah-Hartman Date: Wed Apr 28 13:19:16 2021 +0200 Linux 5.4.115 Tested-by: Jon Hunter Tested-by: Florian Fainelli Tested-by: Guenter Roeck Tested-by: Sudip Mukherjee Tested-by: Jason Self Tested-by: Shuah Khan Tested-by: Hulk Robot Tested-by: Linux Kernel Functional Testing Link: https://lore.kernel.org/r/20210426072816.686976183@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit af7099bad49591675a9b14bb48437bc6b53b4435 Author: Oliver Neukum Date: Wed Apr 21 09:45:13 2021 +0200 USB: CDC-ACM: fix poison/unpoison imbalance commit a8b3b519618f30a87a304c4e120267ce6f8dc68a upstream. suspend() does its poisoning conditionally, resume() does it unconditionally. On a device with combined interfaces this will balance, on a device with two interfaces the counter will go negative and resubmission will fail. Both actions need to be done conditionally. Fixes: 6069e3e927c8f ("USB: cdc-acm: untangle a circular dependency between callback and softint") Signed-off-by: Oliver Neukum Cc: stable Link: https://lore.kernel.org/r/20210421074513.4327-1-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman commit d7fad2ce15bdbbd0fec3ebe999fd7cab2267f53e Author: Johan Hovold Date: Mon Apr 26 10:11:49 2021 +0200 net: hso: fix NULL-deref on disconnect regression commit 2ad5692db72874f02b9ad551d26345437ea4f7f3 upstream. Commit 8a12f8836145 ("net: hso: fix null-ptr-deref during tty device unregistration") fixed the racy minor allocation reported by syzbot, but introduced an unconditional NULL-pointer dereference on every disconnect instead. Specifically, the serial device table must no longer be accessed after the minor has been released by hso_serial_tty_unregister(). Fixes: 8a12f8836145 ("net: hso: fix null-ptr-deref during tty device unregistration") Cc: stable@vger.kernel.org Cc: Anirudh Rayabharam Reported-by: Leonardo Antoniazzi Signed-off-by: Johan Hovold Reviewed-by: Anirudh Rayabharam Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 699017fe0de495868f869a287395e0d2e6fc2f83 Author: Mike Galbraith Date: Fri Apr 16 14:02:07 2021 +0200 x86/crash: Fix crash_setup_memmap_entries() out-of-bounds access commit 5849cdf8c120e3979c57d34be55b92d90a77a47e upstream. Commit in Fixes: added support for kexec-ing a kernel on panic using a new system call. As part of it, it does prepare a memory map for the new kernel. However, while doing so, it wrongly accesses memory it has not allocated: it accesses the first element of the cmem->ranges[] array in memmap_exclude_ranges() but it has not allocated the memory for it in crash_setup_memmap_entries(). As KASAN reports: BUG: KASAN: vmalloc-out-of-bounds in crash_setup_memmap_entries+0x17e/0x3a0 Write of size 8 at addr ffffc90000426008 by task kexec/1187 (gdb) list *crash_setup_memmap_entries+0x17e 0xffffffff8107cafe is in crash_setup_memmap_entries (arch/x86/kernel/crash.c:322). 317 unsigned long long mend) 318 { 319 unsigned long start, end; 320 321 cmem->ranges[0].start = mstart; 322 cmem->ranges[0].end = mend; 323 cmem->nr_ranges = 1; 324 325 /* Exclude elf header region */ 326 start = image->arch.elf_load_addr; (gdb) Make sure the ranges array becomes a single element allocated. [ bp: Write a proper commit message. ] Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call") Signed-off-by: Mike Galbraith Signed-off-by: Borislav Petkov Reviewed-by: Dave Young Cc: Link: https://lkml.kernel.org/r/725fa3dc1da2737f0f6188a1a9701bead257ea9d.camel@gmx.de Signed-off-by: Greg Kroah-Hartman commit b3962b4e8334f0d45a293b359d9d5036919c6f22 Author: John Paul Adrian Glaubitz Date: Fri Apr 16 15:46:15 2021 -0700 ia64: tools: remove duplicate definition of ia64_mf() on ia64 [ Upstream commit f4bf09dc3aaa4b07cd15630f2023f68cb2668809 ] The ia64_mf() macro defined in tools/arch/ia64/include/asm/barrier.h is already defined in on ia64 which causes libbpf failing to build: CC /usr/src/linux/tools/bpf/bpftool//libbpf/staticobjs/libbpf.o In file included from /usr/src/linux/tools/include/asm/barrier.h:24, from /usr/src/linux/tools/include/linux/ring_buffer.h:4, from libbpf.c:37: /usr/src/linux/tools/include/asm/../../arch/ia64/include/asm/barrier.h:43: error: "ia64_mf" redefined [-Werror] 43 | #define ia64_mf() asm volatile ("mf" ::: "memory") | In file included from /usr/include/ia64-linux-gnu/asm/intrinsics.h:20, from /usr/include/ia64-linux-gnu/asm/swab.h:11, from /usr/include/linux/swab.h:8, from /usr/include/linux/byteorder/little_endian.h:13, from /usr/include/ia64-linux-gnu/asm/byteorder.h:5, from /usr/src/linux/tools/include/uapi/linux/perf_event.h:20, from libbpf.c:36: /usr/include/ia64-linux-gnu/asm/gcc_intrin.h:382: note: this is the location of the previous definition 382 | #define ia64_mf() __asm__ volatile ("mf" ::: "memory") | cc1: all warnings being treated as errors Thus, remove the definition from tools/arch/ia64/include/asm/barrier.h. Signed-off-by: John Paul Adrian Glaubitz Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 763cbe5e1ebb08887b9be61481d7b2e1d465904c Author: Randy Dunlap Date: Fri Apr 16 15:46:09 2021 -0700 ia64: fix discontig.c section mismatches [ Upstream commit e2af9da4f867a1a54f1252bf3abc1a5c63951778 ] Fix IA64 discontig.c Section mismatch warnings. When CONFIG_SPARSEMEM=y and CONFIG_MEMORY_HOTPLUG=y, the functions computer_pernodesize() and scatter_node_data() should not be marked as __meminit because they are needed after init, on any memory hotplug event. Also, early_nr_cpus_node() is called by compute_pernodesize(), so early_nr_cpus_node() cannot be __meminit either. WARNING: modpost: vmlinux.o(.text.unlikely+0x1612): Section mismatch in reference from the function arch_alloc_nodedata() to the function .meminit.text:compute_pernodesize() The function arch_alloc_nodedata() references the function __meminit compute_pernodesize(). This is often because arch_alloc_nodedata lacks a __meminit annotation or the annotation of compute_pernodesize is wrong. WARNING: modpost: vmlinux.o(.text.unlikely+0x1692): Section mismatch in reference from the function arch_refresh_nodedata() to the function .meminit.text:scatter_node_data() The function arch_refresh_nodedata() references the function __meminit scatter_node_data(). This is often because arch_refresh_nodedata lacks a __meminit annotation or the annotation of scatter_node_data is wrong. WARNING: modpost: vmlinux.o(.text.unlikely+0x1502): Section mismatch in reference from the function compute_pernodesize() to the function .meminit.text:early_nr_cpus_node() The function compute_pernodesize() references the function __meminit early_nr_cpus_node(). This is often because compute_pernodesize lacks a __meminit annotation or the annotation of early_nr_cpus_node is wrong. Link: https://lkml.kernel.org/r/20210411001201.3069-1-rdunlap@infradead.org Signed-off-by: Randy Dunlap Cc: Mike Rapoport Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 3dce9c4bb546fc467eff2f42bc1e2cc37d086ec7 Author: Randy Dunlap Date: Fri Apr 16 15:46:03 2021 -0700 csky: change a Kconfig symbol name to fix e1000 build error [ Upstream commit d199161653d612b8fb96ac51bfd5b2d2782ecef3 ] e1000's #define of CONFIG_RAM_BASE conflicts with a Kconfig symbol in arch/csky/Kconfig. The symbol in e1000 has been around longer, so change arch/csky/ to use DRAM_BASE instead of RAM_BASE to remove the conflict. (although e1000 is also a 2-line change) Link: https://lkml.kernel.org/r/20210411055335.7111-1-rdunlap@infradead.org Signed-off-by: Randy Dunlap Reported-by: kernel test robot Acked-by: Guo Ren Cc: Jesse Brandeburg Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Sasha Levin commit 892f6bc55746e3419cd3aee37a4b7f08bd2de2a0 Author: Wan Jiabing Date: Wed Apr 14 19:31:48 2021 +0800 cavium/liquidio: Fix duplicate argument [ Upstream commit 416dcc5ce9d2a810477171c62ffa061a98f87367 ] Fix the following coccicheck warning: ./drivers/net/ethernet/cavium/liquidio/cn66xx_regs.h:413:6-28: duplicated argument to & or | The CN6XXX_INTR_M1UPB0_ERR here is duplicate. Here should be CN6XXX_INTR_M1UNB0_ERR. Signed-off-by: Wan Jiabing Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 2ccca124620eb952097b7ab4aa712f9ed20ba245 Author: Michael Brown Date: Tue Apr 13 16:25:12 2021 +0100 xen-netback: Check for hotplug-status existence before watching [ Upstream commit 2afeec08ab5c86ae21952151f726bfe184f6b23d ] The logic in connect() is currently written with the assumption that xenbus_watch_pathfmt() will return an error for a node that does not exist. This assumption is incorrect: xenstore does allow a watch to be registered for a nonexistent node (and will send notifications should the node be subsequently created). As of commit 1f2565780 ("xen-netback: remove 'hotplug-status' once it has served its purpose"), this leads to a failure when a domU transitions into XenbusStateConnected more than once. On the first domU transition into Connected state, the "hotplug-status" node will be deleted by the hotplug_status_changed() callback in dom0. On the second or subsequent domU transition into Connected state, the hotplug_status_changed() callback will therefore never be invoked, and so the backend will remain stuck in InitWait. This failure prevents scenarios such as reloading the xen-netfront module within a domU, or booting a domU via iPXE. There is unfortunately no way for the domU to work around this dom0 bug. Fix by explicitly checking for existence of the "hotplug-status" node, thereby creating the behaviour that was previously assumed to exist. Signed-off-by: Michael Brown Reviewed-by: Paul Durrant Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 78687d6a321328f7f8e7cea5dc7524327b0e90ca Author: Vasily Gorbik Date: Fri Apr 9 00:15:21 2021 +0200 s390/entry: save the caller of psw_idle [ Upstream commit a994eddb947ea9ebb7b14d9a1267001699f0a136 ] Currently psw_idle does not allocate a stack frame and does not save its r14 and r15 into the save area. Even though this is valid from call ABI point of view, because psw_idle does not make any calls explicitly, in reality psw_idle is an entry point for controlled transition into serving interrupts. So, in practice, psw_idle stack frame is analyzed during stack unwinding. Depending on build options that r14 slot in the save area of psw_idle might either contain a value saved by previous sibling call or complete garbage. [task 0000038000003c28] do_ext_irq+0xd6/0x160 [task 0000038000003c78] ext_int_handler+0xba/0xe8 [task *0000038000003dd8] psw_idle_exit+0x0/0x8 <-- pt_regs ([task 0000038000003dd8] 0x0) [task 0000038000003e10] default_idle_call+0x42/0x148 [task 0000038000003e30] do_idle+0xce/0x160 [task 0000038000003e70] cpu_startup_entry+0x36/0x40 [task 0000038000003ea0] arch_call_rest_init+0x76/0x80 So, to make a stacktrace nicer and actually point for the real caller of psw_idle in this frequently occurring case, make psw_idle save its r14. [task 0000038000003c28] do_ext_irq+0xd6/0x160 [task 0000038000003c78] ext_int_handler+0xba/0xe8 [task *0000038000003dd8] psw_idle_exit+0x0/0x6 <-- pt_regs ([task 0000038000003dd8] arch_cpu_idle+0x3c/0xd0) [task 0000038000003e10] default_idle_call+0x42/0x148 [task 0000038000003e30] do_idle+0xce/0x160 [task 0000038000003e70] cpu_startup_entry+0x36/0x40 [task 0000038000003ea0] arch_call_rest_init+0x76/0x80 Reviewed-by: Sven Schnelle Signed-off-by: Vasily Gorbik Signed-off-by: Heiko Carstens Signed-off-by: Sasha Levin commit 026490fac49643dd9a8c69f42a03d928c406ce5e Author: Phillip Potter Date: Sun Apr 11 12:28:24 2021 +0100 net: geneve: check skb is large enough for IPv4/IPv6 header [ Upstream commit 6628ddfec7580882f11fdc5c194a8ea781fdadfa ] Check within geneve_xmit_skb/geneve6_xmit_skb that sk_buff structure is large enough to include IPv4 or IPv6 header, and reject if not. The geneve_xmit_skb portion and overall idea was contributed by Eric Dumazet. Fixes a KMSAN-found uninit-value bug reported by syzbot at: https://syzkaller.appspot.com/bug?id=abe95dc3e3e9667fc23b8d81f29ecad95c6f106f Suggested-by: Eric Dumazet Reported-by: syzbot+2e406a9ac75bb71d4b7a@syzkaller.appspotmail.com Signed-off-by: Phillip Potter Signed-off-by: Eric Dumazet Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit caaf9371ecad11d3319b458ad9421a0b78848381 Author: Tony Lindgren Date: Wed Mar 24 15:10:32 2021 +0200 ARM: dts: Fix swapped mmc order for omap3 [ Upstream commit a1ebdb3741993f853865d1bd8f77881916ad53a7 ] Also some omap3 devices like n900 seem to have eMMC and micro-sd swapped around with commit 21b2cec61c04 ("mmc: Set PROBE_PREFER_ASYNCHRONOUS for drivers that existed in v4.4"). Let's fix the issue with aliases as discussed on the mailing lists. While the mmc aliases should be board specific, let's first fix the issue with minimal changes. Cc: Aaro Koskinen Cc: Peter Ujfalusi Signed-off-by: Tony Lindgren Signed-off-by: Sasha Levin commit be60afbb9136fa635262190f55be2593091c146f Author: Jiapeng Zhong Date: Wed Jan 20 15:34:30 2021 +0800 HID: wacom: Assign boolean values to a bool variable [ Upstream commit e29c62ffb008829dc8bcc0a2ec438adc25a8255e ] Fix the following coccicheck warnings: ./drivers/hid/wacom_wac.c:2536:2-6: WARNING: Assignment of 0/1 to bool variable. Reported-by: Abaci Robot Signed-off-by: Jiapeng Zhong Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit 116ee59ef8866afa9ce4112cddd36317ae8d6aa7 Author: Jia-Ju Bai Date: Thu Mar 4 05:19:57 2021 -0800 HID: alps: fix error return code in alps_input_configured() [ Upstream commit fa8ba6e5dc0e78e409e503ddcfceef5dd96527f4 ] When input_register_device() fails, no error return code is assigned. To fix this bug, ret is assigned with -ENOENT as error return code. Reported-by: TOTE Robot Signed-off-by: Jia-Ju Bai Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit a4e2b91cea5216e84568ba6ab45c7cf87b61f213 Author: Shou-Chieh Hsu Date: Tue Mar 2 11:58:01 2021 +0800 HID: google: add don USB id [ Upstream commit 36b87cf302a4f13f8b4344bcf98f67405a145e2f ] Add 1 additional hammer-like device. Signed-off-by: Shou-Chieh Hsu Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin commit aefb6ac6ac111c50ba5dfae3f015ca03b1b84d7f Author: Leo Yan Date: Tue Apr 20 23:15:53 2021 +0800 perf auxtrace: Fix potential NULL pointer dereference [ Upstream commit b14585d9f18dc617e975815570fe836be656b1da ] In the function auxtrace_parse_snapshot_options(), the callback pointer "itr->parse_snapshot_options" can be NULL if it has not been set during the AUX record initialization. This can cause tool crashing if the callback pointer "itr->parse_snapshot_options" is dereferenced without performing NULL check. Add a NULL check for the pointer "itr->parse_snapshot_options" before invoke the callback. Fixes: d20031bb63dd6dde ("perf tools: Add AUX area tracing Snapshot Mode") Signed-off-by: Leo Yan Acked-by: Adrian Hunter Cc: Adrian Hunter Cc: Alexander Shishkin Cc: Andi Kleen Cc: Jiri Olsa Cc: Mark Rutland Cc: Namhyung Kim Cc: Peter Zijlstra Cc: Tiezhu Yang Link: http://lore.kernel.org/lkml/20210420151554.2031768-1-leo.yan@linaro.org Signed-off-by: Arnaldo Carvalho de Melo Signed-off-by: Sasha Levin commit 39638289595b94d6d9cc10fce8e78ca014fcd9ca Author: Jim Mattson Date: Wed Apr 21 17:18:34 2021 -0700 perf/x86/kvm: Fix Broadwell Xeon stepping in isolation_ucodes[] [ Upstream commit 4b2f1e59229b9da319d358828cdfa4ddbc140769 ] The only stepping of Broadwell Xeon parts is stepping 1. Fix the relevant isolation_ucodes[] entry, which previously enumerated stepping 2. Although the original commit was characterized as an optimization, it is also a workaround for a correctness issue. If a PMI arrives between kvm's call to perf_guest_get_msrs() and the subsequent VM-entry, a stale value for the IA32_PEBS_ENABLE MSR may be restored at the next VM-exit. This is because, unbeknownst to kvm, PMI throttling may clear bits in the IA32_PEBS_ENABLE MSR. CPUs with "PEBS isolation" don't suffer from this issue, because perf_guest_get_msrs() doesn't report the IA32_PEBS_ENABLE value. Fixes: 9b545c04abd4f ("perf/x86/kvm: Avoid unnecessary work in guest filtering") Signed-off-by: Jim Mattson Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Peter Shier Acked-by: Andi Kleen Link: https://lkml.kernel.org/r/20210422001834.1748319-1-jmattson@google.com Signed-off-by: Sasha Levin commit 319a06e58ed7f1443f7133c05513de470f90628d Author: Kan Liang Date: Thu Apr 15 14:22:43 2021 -0700 perf/x86/intel/uncore: Remove uncore extra PCI dev HSWEP_PCI_PCU_3 [ Upstream commit 9d480158ee86ad606d3a8baaf81e6b71acbfd7d5 ] There may be a kernel panic on the Haswell server and the Broadwell server, if the snbep_pci2phy_map_init() return error. The uncore_extra_pci_dev[HSWEP_PCI_PCU_3] is used in the cpu_init() to detect the existence of the SBOX, which is a MSR type of PMON unit. The uncore_extra_pci_dev is allocated in the uncore_pci_init(). If the snbep_pci2phy_map_init() returns error, perf doesn't initialize the PCI type of the PMON units, so the uncore_extra_pci_dev will not be allocated. But perf may continue initializing the MSR type of PMON units. A null dereference kernel panic will be triggered. The sockets in a Haswell server or a Broadwell server are identical. Only need to detect the existence of the SBOX once. Current perf probes all available PCU devices and stores them into the uncore_extra_pci_dev. It's unnecessary. Use the pci_get_device() to replace the uncore_extra_pci_dev. Only detect the existence of the SBOX on the first available PCU device once. Factor out hswep_has_limit_sbox(), since the Haswell server and the Broadwell server uses the same way to detect the existence of the SBOX. Add some macros to replace the magic number. Fixes: 5306c31c5733 ("perf/x86/uncore/hsw-ep: Handle systems with only two SBOXes") Reported-by: Steve Wahl Signed-off-by: Kan Liang Signed-off-by: Peter Zijlstra (Intel) Tested-by: Steve Wahl Link: https://lkml.kernel.org/r/1618521764-100923-1-git-send-email-kan.liang@linux.intel.com Signed-off-by: Sasha Levin commit 82808cc026811fbc3ecf0c0b267a12a339eead56 Author: Ali Saidi Date: Thu Apr 15 17:27:11 2021 +0000 locking/qrwlock: Fix ordering in queued_write_lock_slowpath() [ Upstream commit 84a24bf8c52e66b7ac89ada5e3cfbe72d65c1896 ] While this code is executed with the wait_lock held, a reader can acquire the lock without holding wait_lock. The writer side loops checking the value with the atomic_cond_read_acquire(), but only truly acquires the lock when the compare-and-exchange is completed successfully which isn’t ordered. This exposes the window between the acquire and the cmpxchg to an A-B-A problem which allows reads following the lock acquisition to observe values speculatively before the write lock is truly acquired. We've seen a problem in epoll where the reader does a xchg while holding the read lock, but the writer can see a value change out from under it. Writer | Reader -------------------------------------------------------------------------------- ep_scan_ready_list() | |- write_lock_irq() | |- queued_write_lock_slowpath() | |- atomic_cond_read_acquire() | | read_lock_irqsave(&ep->lock, flags); --> (observes value before unlock) | chain_epi_lockless() | | epi->next = xchg(&ep->ovflist, epi); | | read_unlock_irqrestore(&ep->lock, flags); | | | atomic_cmpxchg_relaxed() | |-- READ_ONCE(ep->ovflist); | A core can order the read of the ovflist ahead of the atomic_cmpxchg_relaxed(). Switching the cmpxchg to use acquire semantics addresses this issue at which point the atomic_cond_read can be switched to use relaxed semantics. Fixes: b519b56e378ee ("locking/qrwlock: Use atomic_cond_read_acquire() when spinning in qrwlock") Signed-off-by: Ali Saidi [peterz: use try_cmpxchg()] Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Steve Capper Acked-by: Will Deacon Acked-by: Waiman Long Tested-by: Steve Capper Signed-off-by: Sasha Levin commit c6eb92b37af1f4ae8439e088d56efec22eab137c Author: Andre Przywara Date: Wed Apr 14 11:47:40 2021 +0100 arm64: dts: allwinner: Revert SD card CD GPIO for Pine64-LTS [ Upstream commit 4d09ccc4a81e7de6b002482af554d8b5626f5041 ] Commit 941432d00768 ("arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD card") enabled the card detect GPIO for the SOPine module, along the way with the Pine64-LTS, which share the same base .dtsi. This was based on the observation that the Pine64-LTS has as "push-push" SD card socket, and that the schematic mentions the card detect GPIO. After having received two reports about failing SD card access with that patch, some more research and polls on that subject revealed that there are at least two different versions of the Pine64-LTS out there: - On some boards (including mine) the card detect pin is "stuck" at high, regardless of an microSD card being inserted or not. - On other boards the card-detect is working, but is active-high, by virtue of an explicit inverter circuit, as shown in the schematic. To cover all versions of the board out there, and don't take any chances, let's revert the introduction of the active-low CD GPIO, but let's use the broken-cd property for the Pine64-LTS this time. That should avoid regressions and should work for everyone, even allowing SD card changes now. The SOPine card detect has proven to be working, so let's keep that GPIO in place. Fixes: 941432d00768 ("arm64: dts: allwinner: Drop non-removable from SoPine/LTS SD card") Reported-by: Michael Weiser Reported-by: Daniel Kulesz Suggested-by: Chen-Yu Tsai Signed-off-by: Andre Przywara Tested-by: Michael Weiser Signed-off-by: Maxime Ripard Link: https://lore.kernel.org/r/20210414104740.31497-1-andre.przywara@arm.com Signed-off-by: Sasha Levin commit 37ee803d7ed7af885ae8776e3833de2476207573 Author: Yuanyuan Zhong Date: Mon Apr 12 17:17:59 2021 -0600 pinctrl: lewisburg: Update number of pins in community [ Upstream commit 196d941753297d0ca73c563ccd7d00be049ec226 ] When updating pin names for Intel Lewisburg, the numbers of pins were left behind. Update them accordingly. Fixes: e66ff71fd0db ("pinctrl: lewisburg: Update pin list according to v1.1v6") Signed-off-by: Yuanyuan Zhong Signed-off-by: Andy Shevchenko Signed-off-by: Sasha Levin commit dbb355960ef9c12caac7a0694cc4376a4f3314fd Author: Tony Lindgren Date: Sat Apr 17 11:38:39 2021 +0300 gpio: omap: Save and restore sysconfig [ Upstream commit ddd8d94ca31e768c76cf8bfe34ba7b10136b3694 ] As we are using cpu_pm to save and restore context, we must also save and restore the GPIO sysconfig register. This is needed because we are not calling PM runtime functions at all with cpu_pm. We need to save the sysconfig on idle as it's value can get reconfigured by PM runtime and can be different from the init time value. Device specific flags like "ti,no-idle-on-init" can affect the init value. Fixes: b764a5863fd8 ("gpio: omap: Remove custom PM calls and use cpu_pm instead") Cc: Aaro Koskinen Cc: Adam Ford Cc: Andreas Kemnade Cc: Grygorii Strashko Cc: Peter Ujfalusi Signed-off-by: Tony Lindgren Acked-by: Grygorii Strashko Signed-off-by: Bartosz Golaszewski Signed-off-by: Sasha Levin commit 835c8d688e1e84b00204d2a142a33b3b0dda962e Author: Sven Schnelle Date: Fri Mar 6 13:18:31 2020 +0100 s390/ptrace: return -ENOSYS when invalid syscall is supplied commit cd29fa798001075a554b978df3a64e6656c25794 upstream. The current code returns the syscall number which an invalid syscall number is supplied and tracing is enabled. This makes the strace testsuite fail. Signed-off-by: Sven Schnelle Signed-off-by: Vasily Gorbik Link: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1895132 [krzysztof: adjusted the backport around missing ifdef CONFIG_SECCOMP, add Link and Fixes; apparently this should go with the referenced commit] Fixes: 00332c16b160 ("s390/ptrace: pass invalid syscall numbers to tracing") Signed-off-by: Krzysztof Kozlowski Signed-off-by: Greg Kroah-Hartman