commit c4bbda210077280030b01adf17d2a5fb39ace668 Author: Greg Kroah-Hartman Date: Sun May 10 10:32:53 2020 +0200 Linux 5.6.12 commit d2873537a02df48552d36701b2d6bac5255526db Author: Will Deacon Date: Wed Mar 25 11:13:46 2020 +0000 mm/mremap: Add comment explaining the untagging behaviour of mremap() commit b2a84de2a2deb76a6a51609845341f508c518c03 upstream. Commit dcde237319e6 ("mm: Avoid creating virtual address aliases in brk()/mmap()/mremap()") changed mremap() so that only the 'old' address is untagged, leaving the 'new' address in the form it was passed from userspace. This prevents the unexpected creation of aliasing virtual mappings in userspace, but looks a bit odd when you read the code. Add a comment justifying the untagging behaviour in mremap(). Reported-by: Linus Torvalds Acked-by: Linus Torvalds Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit 2133af1e025dd4774feb1290339e7c80ed1ab694 Author: Jiri Slaby Date: Mon Apr 20 09:04:24 2020 +0200 cgroup, netclassid: remove double cond_resched commit 526f3d96b8f83b1b13d73bd0b5c79cc2c487ec8e upstream. Commit 018d26fcd12a ("cgroup, netclassid: periodically release file_lock on classid") added a second cond_resched to write_classid indirectly by update_classid_task. Remove the one in write_classid. Signed-off-by: Jiri Slaby Cc: Dmitry Yakunin Cc: Konstantin Khlebnikov Cc: David S. Miller Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit ca4c2a01d57dd80626a22f4ce2ab4fbb6462bc1c Author: Thomas Pedersen Date: Mon Jan 13 21:59:40 2020 -0800 mac80211: add ieee80211_is_any_nullfunc() commit 30b2f0be23fb40e58d0ad2caf8702c2a44cda2e1 upstream. commit 08a5bdde3812 ("mac80211: consider QoS Null frames for STA_NULLFUNC_ACKED") Fixed a bug where we failed to take into account a nullfunc frame can be either non-QoS or QoS. It turns out there is at least one more bug in ieee80211_sta_tx_notify(), introduced in commit 7b6ddeaf27ec ("mac80211: use QoS NDP for AP probing"), where we forgot to check for the QoS variant and so assumed the QoS nullfunc frame never went out Fix this by adding a helper ieee80211_is_any_nullfunc() which consolidates the check for non-QoS and QoS nullfunc frames. Replace existing compound conditionals and add a couple more missing checks for QoS variant. Signed-off-by: Thomas Pedersen Link: https://lore.kernel.org/r/20200114055940.18502-3-thomas@adapt-ip.com Signed-off-by: Johannes Berg Signed-off-by: Greg Kroah-Hartman commit 29b85f14a6971a9539dd0e5dec62806f2cb5cfc1 Author: Rafael J. Wysocki Date: Fri Mar 20 15:07:29 2020 +0100 ACPI: PM: s2idle: Fix comment in acpi_s2idle_prepare_late() commit 243a98894dc525ad2fbeb608722fcb682be3186d upstream. Fix a comment in acpi_s2idle_prepare_late() that has become outdated after commit f0ac20c3f613 ("ACPI: EC: Fix flushing of pending work"). Fixes: f0ac20c3f613 ("ACPI: EC: Fix flushing of pending work") Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman commit e0cf5868c4146bfbe7e372cfd727d356b0ae28fa Author: Hans de Goede Date: Fri Mar 6 10:17:24 2020 +0100 platform/x86: GPD pocket fan: Fix error message when temp-limits are out of range commit 1d6f8c5bac93cceb2d4ac8e6331050652004d802 upstream. Commit 1f27dbd8265d ("platform/x86: GPD pocket fan: Allow somewhat lower/higher temperature limits") changed the module-param sanity check to accept temperature limits between 20 and 90 degrees celcius. But the error message printed when the module params are outside this range was not updated. This commit updates the error message to match the new min and max value for the temp-limits. Reported-by: Pavel Machek Signed-off-by: Hans de Goede Acked-by: Pavel Machek Signed-off-by: Andy Shevchenko Signed-off-by: Greg Kroah-Hartman commit 9fa270b7348e5b6ea29188bd7e0c667296b1220a Author: Qian Cai Date: Thu Apr 2 11:39:55 2020 -0400 x86/kvm: fix a missing-prototypes "vmread_error" commit 514ccc194971d0649e4e7ec8a9b3a6e33561d7bf upstream. The commit 842f4be95899 ("KVM: VMX: Add a trampoline to fix VMREAD error handling") removed the declaration of vmread_error() causes a W=1 build failure with KVM_WERROR=y. Fix it by adding it back. arch/x86/kvm/vmx/vmx.c:359:17: error: no previous prototype for 'vmread_error' [-Werror=missing-prototypes] asmlinkage void vmread_error(unsigned long field, bool fault) ^~~~~~~~~~~~ Signed-off-by: Qian Cai Message-Id: <20200402153955.1695-1-cai@lca.pw> Signed-off-by: Paolo Bonzini Signed-off-by: Greg Kroah-Hartman commit c07e922d1d0f491a36d23409dd61c5a5513ae23c Author: Takashi Iwai Date: Fri Apr 24 08:12:22 2020 +0200 ALSA: hda: Match both PCI ID and SSID for driver blacklist commit 977dfef40c8996b69afe23a9094d184049efb7bb upstream. The commit 3c6fd1f07ed0 ("ALSA: hda: Add driver blacklist") added a new blacklist for the devices that are known to have empty codecs, and one of the entries was ASUS ROG Zenith II (PCI SSID 1043:874f). However, it turned out that the very same PCI SSID is used for the previous model that does have the valid HD-audio codecs and the change broke the sound on it. Since the empty codec problem appear on the certain AMD platform (PCI ID 1022:1487), this patch changes the blacklist matching to both PCI ID and SSID using pci_match_id(). Also, the entry that was removed by the previous fix for ASUS ROG Zenigh II is re-added. Link: https://lore.kernel.org/r/20200424061222.19792-1-tiwai@suse.de Signed-off-by: Takashi Iwai Signed-off-by: Greg Kroah-Hartman commit d0a077eef4ae85e7a6a1134fbe148039068e9d43 Author: Aaron Ma Date: Fri Apr 3 22:34:19 2020 +0800 drm/amdgpu: Fix oops when pp_funcs is unset in ACPI event commit 5932d260a8d85a103bd6c504fbb85ff58b156bf9 upstream. On ARCTURUS and RENOIR, powerplay is not supported yet. When plug in or unplug power jack, ACPI event will issue. Then kernel NULL pointer BUG will be triggered. Check for NULL pointers before calling. Signed-off-by: Aaron Ma Signed-off-by: Alex Deucher Cc: stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman commit 99dc0cc0dcf78d3b245290ce9c0055e8167b8690 Author: Jere Leppänen Date: Tue Apr 21 22:03:42 2020 +0300 sctp: Fix SHUTDOWN CTSN Ack in the peer restart case commit 12dfd78e3a74825e6f0bc8df7ef9f938fbc6bfe3 upstream. When starting shutdown in sctp_sf_do_dupcook_a(), get the value for SHUTDOWN Cumulative TSN Ack from the new association, which is reconstructed from the cookie, instead of the old association, which the peer doesn't have anymore. Otherwise the SHUTDOWN is either ignored or replied to with an ABORT by the peer because CTSN Ack doesn't match the peer's Initial TSN. Fixes: bdf6fa52f01b ("sctp: handle association restarts when the socket is closed.") Signed-off-by: Jere Leppänen Acked-by: Marcelo Ricardo Leitner Signed-off-by: David S. Miller Signed-off-by: Greg Kroah-Hartman commit 549e321c9468f0084ae0239c3668dae10a6220e1 Author: Andrii Nakryiko Date: Tue Apr 21 18:24:07 2020 -0700 tools/runqslower: Ensure own vmlinux.h is picked up first [ Upstream commit dfc55ace9939e1e8703ad37ddbba41aaa31cc0cb ] Reorder include paths to ensure that runqslower sources are picking up vmlinux.h, generated by runqslower's own Makefile. When runqslower is built from selftests/bpf, due to current -I$(BPF_INCLUDE) -I$(OUTPUT) ordering, it might pick up not-yet-complete vmlinux.h, generated by selftests Makefile, which could lead to compilation errors like [0]. So ensure that -I$(OUTPUT) goes first and rely on runqslower's Makefile own dependency chain to ensure vmlinux.h is properly completed before source code relying on it is compiled. [0] https://travis-ci.org/github/libbpf/libbpf/jobs/677905925 Signed-off-by: Andrii Nakryiko Signed-off-by: Alexei Starovoitov Link: https://lore.kernel.org/bpf/20200422012407.176303-1-andriin@fb.com Signed-off-by: Sasha Levin commit 8846b918c55e47123e37f9220f5d5cdc3c78f900 Author: Doug Berger Date: Thu Apr 23 16:13:30 2020 -0700 net: systemport: suppress warnings on failed Rx SKB allocations [ Upstream commit 3554e54a46125030c534820c297ed7f6c3907e24 ] The driver is designed to drop Rx packets and reclaim the buffers when an allocation fails, and the network interface needs to safely handle this packet loss. Therefore, an allocation failure of Rx SKBs is relatively benign. However, the output of the warning message occurs with a high scheduling priority that can cause excessive jitter/latency for other high priority processing. This commit suppresses the warning messages to prevent scheduling problems while retaining the failure count in the statistics of the network interface. Signed-off-by: Doug Berger Acked-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f56650e8f770f9c9f5ff0cc85e83f65720ce33dd Author: Doug Berger Date: Thu Apr 23 16:02:11 2020 -0700 net: bcmgenet: suppress warnings on failed Rx SKB allocations [ Upstream commit ecaeceb8a8a145d93c7e136f170238229165348f ] The driver is designed to drop Rx packets and reclaim the buffers when an allocation fails, and the network interface needs to safely handle this packet loss. Therefore, an allocation failure of Rx SKBs is relatively benign. However, the output of the warning message occurs with a high scheduling priority that can cause excessive jitter/latency for other high priority processing. This commit suppresses the warning messages to prevent scheduling problems while retaining the failure count in the statistics of the network interface. Signed-off-by: Doug Berger Acked-by: Florian Fainelli Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit 6a2d15ac54c67ca8e4c6c648a6efd9dda7731eb2 Author: Madhuparna Bhowmik Date: Thu Apr 9 13:59:06 2020 +0530 mac80211: sta_info: Add lockdep condition for RCU list usage [ Upstream commit 8ca47eb9f9e4e10e7e7fa695731a88941732c38d ] The function sta_info_get_by_idx() uses RCU list primitive. It is called with local->sta_mtx held from mac80211/cfg.c. Add lockdep expression to avoid any false positive RCU list warnings. Signed-off-by: Madhuparna Bhowmik Link: https://lore.kernel.org/r/20200409082906.27427-1-madhuparnabhowmik10@gmail.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 6f7eb520c385d6b7b97a136376296ec475b0d48b Author: Nathan Chancellor Date: Mon Apr 13 12:50:42 2020 -0700 lib/mpi: Fix building for powerpc with clang [ Upstream commit 5990cdee689c6885b27c6d969a3d58b09002b0bc ] 0day reports over and over on an powerpc randconfig with clang: lib/mpi/generic_mpih-mul1.c:37:13: error: invalid use of a cast in a inline asm context requiring an l-value: remove the cast or build with -fheinous-gnu-extensions Remove the superfluous casts, which have been done previously for x86 and arm32 in commit dea632cadd12 ("lib/mpi: fix build with clang") and commit 7b7c1df2883d ("lib/mpi/longlong.h: fix building with 32-bit x86"). Reported-by: kbuild test robot Signed-off-by: Nathan Chancellor Acked-by: Herbert Xu Signed-off-by: Michael Ellerman Link: https://github.com/ClangBuiltLinux/linux/issues/991 Link: https://lore.kernel.org/r/20200413195041.24064-1-natechancellor@gmail.com Signed-off-by: Sasha Levin commit 7c923fe0217e7df157c2e6e8907dce38243163ee Author: Russell King Date: Thu Apr 23 08:57:42 2020 +0100 net: phy: bcm84881: clear settings on link down [ Upstream commit 796a8fa28980050bf1995617f0876484f3dc1026 ] Clear the link partner advertisement, speed, duplex and pause when the link goes down, as other phylib drivers do. This avoids the stale link partner, speed and duplex settings being reported via ethtool. Signed-off-by: Russell King Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f34a2ce2ae8037303c09a295f55eb79bd3006fdf Author: Steven Rostedt (VMware) Date: Wed Apr 22 21:38:45 2020 -0400 ftrace: Fix memory leak caused by not freeing entry in unregister_ftrace_direct() [ Upstream commit 353da87921a5ec654e7e9024e083f099f1b33c97 ] kmemleak reported the following: unreferenced object 0xffff90d47127a920 (size 32): comm "modprobe", pid 1766, jiffies 4294792031 (age 162.568s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 22 01 00 00 00 00 ad de ........"....... 00 78 12 a7 ff ff ff ff 00 00 b6 c0 ff ff ff ff .x.............. backtrace: [<00000000bb79e72e>] register_ftrace_direct+0xcb/0x3a0 [<00000000295e4f79>] do_one_initcall+0x72/0x340 [<00000000873ead18>] do_init_module+0x5a/0x220 [<00000000974d9de5>] load_module+0x2235/0x2550 [<0000000059c3d6ce>] __do_sys_finit_module+0xc0/0x120 [<000000005a8611b4>] do_syscall_64+0x60/0x230 [<00000000a0cdc49e>] entry_SYSCALL_64_after_hwframe+0x49/0xb3 The entry used to save the direct descriptor needs to be freed when unregistering. Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit edc28823ab8f2c7fe111aac9010a149489e3ba7d Author: Vamshi K Sthambamkadi Date: Wed Apr 22 11:45:06 2020 +0530 tracing: Fix memory leaks in trace_events_hist.c [ Upstream commit 9da73974eb9c965dd9989befb593b8c8da9e4bdc ] kmemleak report 1: [<9092c50b>] kmem_cache_alloc_trace+0x138/0x270 [<05a2c9ed>] create_field_var+0xcf/0x180 [<528a2d68>] action_create+0xe2/0xc80 [<63f50b61>] event_hist_trigger_func+0x15b5/0x1920 [<28ea5d3d>] trigger_process_regex+0x7b/0xc0 [<3138e86f>] event_trigger_write+0x4d/0xb0 [] __vfs_write+0x30/0x200 [<4f424a0d>] vfs_write+0x96/0x1b0 [] ksys_write+0x53/0xc0 [<3717101a>] __ia32_sys_write+0x15/0x20 [] do_fast_syscall_32+0x70/0x250 [<46e2629c>] entry_SYSENTER_32+0xaf/0x102 This is because save_vars[] of struct hist_trigger_data are not destroyed kmemleak report 2: [<9092c50b>] kmem_cache_alloc_trace+0x138/0x270 [<6e5e97c5>] create_var+0x3c/0x110 [] create_field_var+0xaf/0x180 [<528a2d68>] action_create+0xe2/0xc80 [<63f50b61>] event_hist_trigger_func+0x15b5/0x1920 [<28ea5d3d>] trigger_process_regex+0x7b/0xc0 [<3138e86f>] event_trigger_write+0x4d/0xb0 [] __vfs_write+0x30/0x200 [<4f424a0d>] vfs_write+0x96/0x1b0 [] ksys_write+0x53/0xc0 [<3717101a>] __ia32_sys_write+0x15/0x20 [] do_fast_syscall_32+0x70/0x250 [<46e2629c>] entry_SYSENTER_32+0xaf/0x102 struct hist_field allocated through create_var() do not initialize "ref" field to 1. The code in __destroy_hist_field() does not destroy object if "ref" is initialized to zero, the condition if (--hist_field->ref > 1) always passes since unsigned int wraps. kmemleak report 3: [] __kmalloc_track_caller+0x139/0x2b0 [] kstrdup+0x27/0x50 [<39d70006>] init_var_ref+0x58/0xd0 [<8ca76370>] create_var_ref+0x89/0xe0 [] action_create+0x38f/0xc80 [<7c146821>] event_hist_trigger_func+0x15b5/0x1920 [<07de3f61>] trigger_process_regex+0x7b/0xc0 [] event_trigger_write+0x4d/0xb0 [<19bf1512>] __vfs_write+0x30/0x200 [<64ce4d27>] vfs_write+0x96/0x1b0 [] ksys_write+0x53/0xc0 [<7d4230cd>] __ia32_sys_write+0x15/0x20 [<8eadca00>] do_fast_syscall_32+0x70/0x250 [<235cf985>] entry_SYSENTER_32+0xaf/0x102 hist_fields (system & event_name) are not freed Link: http://lkml.kernel.org/r/20200422061503.GA5151@cosmos Signed-off-by: Vamshi K Sthambamkadi Signed-off-by: Steven Rostedt (VMware) Signed-off-by: Sasha Levin commit 8c6c4ddc00b4aa4f756ad906ae17d3bbc6121934 Author: Paulo Alcantara Date: Mon Apr 20 19:42:57 2020 -0300 cifs: do not share tcons with DFS [ Upstream commit 65303de829dd6d291a4947c1a31de31896f8a060 ] This disables tcon re-use for DFS shares. tcon->dfs_path stores the path that the tcon should connect to when doing failing over. If that tcon is used multiple times e.g. 2 mounts using it with different prefixpath, each will need a different dfs_path but there is only one tcon. The other solution would be to split the tcon in 2 tcons during failover but that is much harder. tcons could not be shared with DFS in cifs.ko because in a DFS namespace like: //domain/dfsroot -> /serverA/dfsroot, /serverB/dfsroot //serverA/dfsroot/link -> /serverA/target1/aa/bb //serverA/dfsroot/link2 -> /serverA/target1/cc/dd you can see that link and link2 are two DFS links that both resolve to the same target share (/serverA/target1), so cifs.ko will only contain a single tcon for both link and link2. The problem with that is, if we (auto)mount "link" and "link2", cifs.ko will only contain a single tcon for both DFS links so we couldn't perform failover or refresh the DFS cache for both links because tcon->dfs_path was set to either "link" or "link2", but not both -- which is wrong. Signed-off-by: Paulo Alcantara (SUSE) Reviewed-by: Aurelien Aptel Reviewed-by: Ronnie Sahlberg Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 0c25053254f4a1753b3ef64fcb7cd903f1a901e2 Author: Jeremie Francois (on alpha) Date: Fri Apr 10 18:57:40 2020 +0200 scripts/config: allow colons in option strings for sed [ Upstream commit e461bc9f9ab105637b86065d24b0b83f182d477c ] Sed broke on some strings as it used colon as a separator. I made it more robust by using \001, which is legit POSIX AFAIK. E.g. ./config --set-str CONFIG_USBNET_DEVADDR "de:ad:be:ef:00:01" failed with: sed: -e expression #1, char 55: unknown option to `s' Signed-off-by: Jeremie Francois (on alpha) Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin commit dbcfc48203a893137afa982cc135356b535a2e31 Author: Ronnie Sahlberg Date: Tue Apr 21 12:37:39 2020 +1000 cifs: protect updating server->dstaddr with a spinlock [ Upstream commit fada37f6f62995cc449b36ebba1220594bfe55fe ] We use a spinlock while we are reading and accessing the destination address for a server. We need to also use this spinlock to protect when we are modifying this address from reconn_set_ipaddr(). Signed-off-by: Ronnie Sahlberg Reviewed-by: Jeff Layton Signed-off-by: Steve French Signed-off-by: Sasha Levin commit 4e7b37d9127a8783874e394853fe0d6453fa0006 Author: Matthias Blankertz Date: Fri Apr 17 17:30:17 2020 +0200 ASoC: rsnd: Fix "status check failed" spam for multi-SSI [ Upstream commit 54cb6221688660670a2e430892d7f4e6370263b8 ] Fix the rsnd_ssi_stop function to skip disabling the individual SSIs of a multi-SSI setup, as the actual stop is performed by rsnd_ssiu_stop_gen2 - the same logic as in rsnd_ssi_start. The attempt to disable these SSIs was harmless, but caused a "status check failed" message to be printed for every SSI in the multi-SSI setup. The disabling of interrupts is still performed, as they are enabled for all SSIs in rsnd_ssi_init, but care is taken to not accidentally set the EN bit for an SSI where it was not set by rsnd_ssi_start. Signed-off-by: Matthias Blankertz Acked-by: Kuninori Morimoto Link: https://lore.kernel.org/r/20200417153017.1744454-3-matthias.blankertz@cetitec.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 762c23029faf3b996f0e9edfb0148d88ec4dffdb Author: Matthias Blankertz Date: Fri Apr 17 17:30:16 2020 +0200 ASoC: rsnd: Don't treat master SSI in multi SSI setup as parent [ Upstream commit 0c258657ddfe81b4fc0183378d800c97ba0b7cdd ] The master SSI of a multi-SSI setup was attached both to the RSND_MOD_SSI slot and the RSND_MOD_SSIP slot of the rsnd_dai_stream. This is not correct wrt. the meaning of being "parent" in the rest of the SSI code, where it seems to indicate an SSI that provides clock and word sync but is not transmitting/receiving audio data. Not treating the multi-SSI master as parent allows removal of various special cases to the rsnd_ssi_is_parent conditions introduced in commit a09fb3f28a60 ("ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode"). It also fixes the issue that operations performed via rsnd_dai_call() were performed twice for the master SSI. This caused some "status check failed" spam when stopping a multi-SSI stream as the driver attempted to stop the master SSI twice. Signed-off-by: Matthias Blankertz Acked-by: Kuninori Morimoto Link: https://lore.kernel.org/r/20200417153017.1744454-2-matthias.blankertz@cetitec.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 17e001ba9535bc85c03aa59467e56fd4a41ce8f0 Author: Julien Beraud Date: Wed Apr 15 14:24:32 2020 +0200 net: stmmac: Fix sub-second increment [ Upstream commit 91a2559c1dc5b0f7e1256d42b1508935e8eabfbf ] In fine adjustement mode, which is the current default, the sub-second increment register is the number of nanoseconds that will be added to the clock when the accumulator overflows. At each clock cycle, the value of the addend register is added to the accumulator. Currently, we use 20ns = 1e09ns / 50MHz as this value whatever the frequency of the ptp clock actually is. The adjustment is then done on the addend register, only incrementing every X clock cycles X being the ratio between 50MHz and ptp_clock_rate (addend = 2^32 * 50MHz/ptp_clock_rate). This causes the following issues : - In case the frequency of the ptp clock is inferior or equal to 50MHz, the addend value calculation will overflow and the default addend value will be set to 0, causing the clock to not work at all. (For instance, for ptp_clock_rate = 50MHz, addend = 2^32). - The resolution of the timestamping clock is limited to 20ns while it is not needed, thus limiting the accuracy of the timestamping to 20ns. Fix this by setting sub-second increment to 2e09ns / ptp_clock_rate. It will allow to reach the minimum possible frequency for ptp_clk_ref, which is 5MHz for GMII 1000Mps Full-Duplex by setting the sub-second-increment to a higher value. For instance, for 25MHz, it gives ssinc = 80ns and default_addend = 2^31. It will also allow to use a lower value for sub-second-increment, thus improving the timestamping accuracy with frequencies higher than 100MHz, for instance, for 200MHz, ssinc = 10ns and default_addend = 2^31. v1->v2: - Remove modifications to the calculation of default addend, which broke compatibility with clock frequencies for which 2000000000 / ptp_clk_freq is not an integer. - Modify description according to discussions. Signed-off-by: Julien Beraud Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a35f0ff17983761cfc1e42dba31e878baeb702c8 Author: Julien Beraud Date: Wed Apr 15 14:24:31 2020 +0200 net: stmmac: fix enabling socfpga's ptp_ref_clock [ Upstream commit 15ce30609d1e88d42fb1cd948f453e6d5f188249 ] There are 2 registers to write to enable a ptp ref clock coming from the fpga. One that enables the usage of the clock from the fpga for emac0 and emac1 as a ptp ref clock, and the other to allow signals from the fpga to reach emac0 and emac1. Currently, if the dwmac-socfpga has phymode set to PHY_INTERFACE_MODE_MII, PHY_INTERFACE_MODE_GMII, or PHY_INTERFACE_MODE_SGMII, both registers will be written and the ptp ref clock will be set as coming from the fpga. Separate the 2 register writes to only enable signals from the fpga to reach emac0 or emac1 when ptp ref clock is not coming from the fpga. Signed-off-by: Julien Beraud Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit a1c6f01e5d2518724bde925a0e5f1e0d84096abb Author: Xiyu Yang Date: Wed Apr 15 16:41:20 2020 +0800 wimax/i2400m: Fix potential urb refcnt leak [ Upstream commit 7717cbec172c3554d470023b4020d5781961187e ] i2400mu_bus_bm_wait_for_ack() invokes usb_get_urb(), which increases the refcount of the "notif_urb". When i2400mu_bus_bm_wait_for_ack() returns, local variable "notif_urb" becomes invalid, so the refcount should be decreased to keep refcount balanced. The issue happens in all paths of i2400mu_bus_bm_wait_for_ack(), which forget to decrease the refcnt increased by usb_get_urb(), causing a refcnt leak. Fix this issue by calling usb_put_urb() before the i2400mu_bus_bm_wait_for_ack() returns. Signed-off-by: Xiyu Yang Signed-off-by: Xin Tan Signed-off-by: David S. Miller Signed-off-by: Sasha Levin commit f345518ed6f25a061338dee71d094b3e57167865 Author: Sandeep Raghuraman Date: Fri Apr 17 01:37:45 2020 +0530 drm/amdgpu: Correctly initialize thermal controller for GPUs with Powerplay table v0 (e.g Hawaii) [ Upstream commit bbc25dadc7ed19f9d6b2e30980f0eb4c741bb8bf ] Initialize thermal controller fields in the PowerPlay table for Hawaii GPUs, so that fan speeds are reported. Signed-off-by: Sandeep Raghuraman Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 506d740cb1c8a239b11d8961eb912f796539b1fe Author: Prike Liang Date: Wed Apr 15 21:43:41 2020 +0800 drm/amd/powerplay: fix resume failed as smu table initialize early exit [ Upstream commit 45a5e639548c459a5accebad340078e4e6e0e512 ] When the amdgpu in the suspend/resume loop need notify the dpm disabled, otherwise the smu table will be uninitialize and result in resume failed. Signed-off-by: Prike Liang Tested-by: Mengbing Wang Reviewed-by: Alex Deucher Reviewed-by: Huang Rui Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 01b3a160750ecacd521a0d128cd80f36f6ae0079 Author: Alex Elder Date: Fri Apr 3 12:50:04 2020 -0500 remoteproc: qcom_q6v5_mss: fix a bug in q6v5_probe() [ Upstream commit 13c060b50a341dd60303e5264d12108b5747f200 ] If looking up the DT "firmware-name" property fails in q6v6_probe(), the function returns without freeing the remoteproc structure that has been allocated. Fix this by jumping to the free_rproc label, which takes care of this. Signed-off-by: Alex Elder Link: https://lore.kernel.org/r/20200403175005.17130-3-elder@linaro.org Signed-off-by: Bjorn Andersson Signed-off-by: Sasha Levin commit 4b7ac410326d83043dac6545440b1785a1c4aff3 Author: Amadeusz Sławiński Date: Wed Apr 15 12:28:49 2020 -0400 ASoC: codecs: hdac_hdmi: Fix incorrect use of list_for_each_entry [ Upstream commit 326b509238171d37402dbe308e154cc234ed1960 ] If we don't find any pcm, pcm will point at address at an offset from the the list head and not a meaningful structure. Fix this by returning correct pcm if found and NULL if not. Found with coccinelle. Signed-off-by: Amadeusz Sławiński Link: https://lore.kernel.org/r/20200415162849.308-1-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ff2aef3db9ef733b23e40809a27f5547af8d53cd Author: Matthias Blankertz Date: Wed Apr 15 16:10:17 2020 +0200 ASoC: rsnd: Fix HDMI channel mapping for multi-SSI mode [ Upstream commit b94e164759b82d0c1c80d4b1c8f12c9bee83f11d ] The HDMI?_SEL register maps up to four stereo SSI data lanes onto the sdata[0..3] inputs of the HDMI output block. The upper half of the register contains four blocks of 4 bits, with the most significant controlling the sdata3 line and the least significant the sdata0 line. The shift calculation has an off-by-one error, causing the parent SSI to be mapped to sdata3, the first multi-SSI child to sdata0 and so forth. As the parent SSI transmits the stereo L/R channels, and the HDMI core expects it on the sdata0 line, this causes no audio to be output when playing stereo audio on a multichannel capable HDMI out, and multichannel audio has permutated channels. Fix the shift calculation to map the parent SSI to sdata0, the first child to sdata1 etc. Signed-off-by: Matthias Blankertz Acked-by: Kuninori Morimoto Link: https://lore.kernel.org/r/20200415141017.384017-3-matthias.blankertz@cetitec.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit f5378c3618ff4b1440f659ce3c7ee23a5c1af8dd Author: Matthias Blankertz Date: Wed Apr 15 16:10:16 2020 +0200 ASoC: rsnd: Fix parent SSI start/stop in multi-SSI mode [ Upstream commit a09fb3f28a60ba3e928a1fa94b0456780800299d ] The parent SSI of a multi-SSI setup must be fully setup, started and stopped since it is also part of the playback/capture setup. So only skip the SSI (as per commit 203cdf51f288 ("ASoC: rsnd: SSI parent cares SWSP bit") and commit 597b046f0d99 ("ASoC: rsnd: control SSICR::EN correctly")) if the SSI is parent outside of a multi-SSI setup. Signed-off-by: Matthias Blankertz Acked-by: Kuninori Morimoto Link: https://lore.kernel.org/r/20200415141017.384017-2-matthias.blankertz@cetitec.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 756825fc1d9ec8be1d972536cf788507529d2c45 Author: Thinh Nguyen Date: Fri Jan 31 16:59:27 2020 -0800 usb: dwc3: gadget: Properly set maxpacket limit [ Upstream commit d94ea5319813658ad5861d161ae16a194c2abf88 ] Currently the calculation of max packet size limit for IN endpoints is too restrictive. This prevents a matching of a capable hardware endpoint during configuration. Below is the minimum recommended HW configuration to support a particular endpoint setup from the databook: For OUT endpoints, the databook recommended the minimum RxFIFO size to be at least 3x MaxPacketSize + 3x setup packets size (8 bytes each) + clock crossing margin (16 bytes). For IN endpoints, the databook recommended the minimum TxFIFO size to be at least 3x MaxPacketSize for endpoints that support burst. If the endpoint doesn't support burst or when the device is operating in USB 2.0 mode, a minimum TxFIFO size of 2x MaxPacketSize is recommended. Base on these recommendations, we can calculate the MaxPacketSize limit of each endpoint. This patch revises the IN endpoint MaxPacketSize limit and also sets the MaxPacketSize limit for OUT endpoints. Reference: Databook 3.30a section 3.2.2 and 3.2.3 Signed-off-by: Thinh Nguyen Signed-off-by: Felipe Balbi Signed-off-by: Sasha Levin commit 3ac5d22e7cba6442148cf916a3f34c81506ee1b2 Author: Amadeusz Sławiński Date: Wed Apr 15 12:24:35 2020 -0400 ASoC: topology: Fix endianness issue [ Upstream commit 26d87881590fd55ccdd8f829498d7b3033f81990 ] As done in already existing cases, we should use le32_to_cpu macro while accessing hdr->magic. Found with sparse. Signed-off-by: Amadeusz Sławiński Link: https://lore.kernel.org/r/20200415162435.31859-2-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit db23f9177eb538044f57dfbf0156c696f6744264 Author: Sebastian Reichel Date: Tue Apr 14 20:11:40 2020 +0200 ASoC: sgtl5000: Fix VAG power-on handling [ Upstream commit aa7812737f2877e192d57626cbe8825cc7cf6de9 ] As mentioned slightly out of patch context in the code, there is no reset routine for the chip. On boards where the chip is supplied by a fixed regulator, it might not even be resetted during (e.g. watchdog) reboot and can be in any state. If the device is probed with VAG enabled, the driver's probe routine will generate a loud pop sound when ANA_POWER is being programmed. Avoid this by properly disabling just the VAG bit and waiting the required power down time. Signed-off-by: Sebastian Reichel Reviewed-by: Fabio Estevam Link: https://lore.kernel.org/r/20200414181140.145825-1-sebastian.reichel@collabora.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 23ce3e2c4179b15dab7c8c2892ddbf80f0104d6f Author: Wu Bo Date: Tue Apr 14 10:13:28 2020 +0800 scsi: sg: add sg_remove_request in sg_write [ Upstream commit 83c6f2390040f188cc25b270b4befeb5628c1aee ] If the __copy_from_user function failed we need to call sg_remove_request in sg_write. Link: https://lore.kernel.org/r/610618d9-e983-fd56-ed0f-639428343af7@huawei.com Acked-by: Douglas Gilbert Signed-off-by: Wu Bo Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 0d365414d2983409a2d7b2cde8e2541e828ff39f Author: Vasily Khoruzhick Date: Sun Mar 29 15:22:53 2020 -0700 drm/bridge: anx6345: set correct BPC for display_info of connector [ Upstream commit 1e8a6ce9186dbf342eebc07cf14cae5e82164e03 ] Some drivers (e.g. sun4i-drm) need this info to decide whether they need to enable dithering. Currently driver reports what panel supports and if panel supports 8 we don't get dithering enabled. Hardcode BPC to 6 for now since that's the only BPC that driver supports. Fixes: 6aa192698089 ("drm/bridge: Add Analogix anx6345 support") Signed-off-by: Vasily Khoruzhick Acked-by: Jernej Skrabec Signed-off-by: Jernej Skrabec Link: https://patchwork.freedesktop.org/patch/msgid/20200329222253.2941405-1-anarsoul@gmail.com Signed-off-by: Sasha Levin commit 8079acfe5b45d5601a399ba4e938ed75d8dc68c2 Author: Tyler Hicks Date: Mon Apr 13 15:21:45 2020 -0500 selftests/ipc: Fix test failure seen after initial test run [ Upstream commit b87080eab4c1377706c113fc9c0157f19ea8fed1 ] After successfully running the IPC msgque test once, subsequent runs result in a test failure: $ sudo ./run_kselftest.sh TAP version 13 1..1 # selftests: ipc: msgque # Failed to get stats for IPC queue with id 0 # Failed to dump queue: -22 # Bail out! # # Pass 0 Fail 0 Xfail 0 Xpass 0 Skip 0 Error 0 not ok 1 selftests: ipc: msgque # exit=1 The dump_queue() function loops through the possible message queue index values using calls to msgctl(kern_id, MSG_STAT, ...) where kern_id represents the index value. The first time the test is ran, the initial index value of 0 is valid and the test is able to complete. The index value of 0 is not valid in subsequent test runs and the loop attempts to try index values of 1, 2, 3, and so on until a valid index value is found that corresponds to the message queue created earlier in the test. The msgctl() syscall returns -1 and sets errno to EINVAL when invalid index values are used. The test failure is caused by incorrectly comparing errno to -EINVAL when cycling through possible index values. Fix invalid test failures on subsequent runs of the msgque test by correctly comparing errno values to a non-negated EINVAL. Fixes: 3a665531a3b7 ("selftests: IPC message queue copy feature test") Signed-off-by: Tyler Hicks Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit b668423c13b012e6e14b2faf4e9da6c544d70fbb Author: Jarkko Sakkinen Date: Sun Apr 12 17:23:07 2020 +0300 Revert "Kernel selftests: tpm2: check for tpm support" [ Upstream commit aaa2d92efe1f972567f1691b423ab8dc606ab3a9 ] This reverts commit b32694cd0724d4ceca2c62cc7c3d3a8d1ffa11fc. The original comment was neither reviewed nor tested. Thus, this the *only* possible action to take. Cc: Nikita Sobolev Signed-off-by: Jarkko Sakkinen Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit c03b7f4d2422eaf50f843511ba5f22e764879692 Author: Sandipan Das Date: Thu Jan 30 12:31:19 2020 +0530 selftests: vm: Fix 64-bit test builds for powerpc64le [ Upstream commit 963e3e9c9a127013eb4d3c82eb997068b1adbb89 ] Some tests are built only for 64-bit systems. This makes sure that these tests are built for both big and little endian variants of powerpc64. Fixes: 7549b3364201 ("selftests: vm: Build/Run 64bit tests only on 64bit arch") Reviewed-by: Kamalesh Babulal Signed-off-by: Sandipan Das Tested-by: Michael Ellerman Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit 036b7355ea0b6574d470b9d1a1f3b001801fd8ad Author: Sandipan Das Date: Thu Jan 30 12:31:18 2020 +0530 selftests: vm: Do not override definition of ARCH [ Upstream commit 24c3f063c57b2a8ae21b259bcfa7690e2eb56dd9 ] Independent builds of the vm selftests is currently broken because commit 7549b3364201 ("selftests: vm: Build/Run 64bit tests only on 64bit arch") overrides the value of ARCH with the machine name from uname. This does not always match the architecture names used for tasks like header installation. E.g. for building tests on powerpc64, we need ARCH=powerpc and not ARCH=ppc64 or ARCH=ppc64le. Otherwise, the build fails as shown below. $ uname -m ppc64le $ make -C tools/testing/selftests/vm make: Entering directory '/home/sandipan/linux/tools/testing/selftests/vm' make --no-builtin-rules ARCH=ppc64le -C ../../../.. headers_install make[1]: Entering directory '/home/sandipan/linux' Makefile:653: arch/ppc64le/Makefile: No such file or directory make[1]: *** No rule to make target 'arch/ppc64le/Makefile'. Stop. make[1]: Leaving directory '/home/sandipan/linux' ../lib.mk:50: recipe for target 'khdr' failed make: *** [khdr] Error 2 make: Leaving directory '/home/sandipan/linux/tools/testing/selftests/vm' Fixes: 7549b3364201 ("selftests: vm: Build/Run 64bit tests only on 64bit arch") Signed-off-by: Sandipan Das Tested-by: Michael Ellerman Signed-off-by: Shuah Khan Signed-off-by: Sasha Levin commit b508b3442416186adf5359f4e298a7553858357f Author: Yihao Wu Date: Mon Apr 6 01:57:22 2020 +0800 SUNRPC/cache: Fix unsafe traverse caused double-free in cache_purge [ Upstream commit 43e33924c38e8faeb0c12035481cb150e602e39d ] Deleting list entry within hlist_for_each_entry_safe is not safe unless next pointer (tmp) is protected too. It's not, because once hash_lock is released, cache_clean may delete the entry that tmp points to. Then cache_purge can walk to a deleted entry and tries to double free it. Fix this bug by holding only the deleted entry's reference. Suggested-by: NeilBrown Signed-off-by: Yihao Wu Reviewed-by: NeilBrown [ cel: removed unused variable ] Signed-off-by: Chuck Lever Signed-off-by: Sasha Levin commit 06f47d75e4e316658f94f73534a9436969119fa2 Author: Amadeusz Sławiński Date: Fri Mar 27 16:47:29 2020 -0400 ASoC: topology: Check return value of soc_tplg_dai_config [ Upstream commit dd8e871d4e560eeb8d22af82dde91457ad835a63 ] Function soc_tplg_dai_config can fail, check for and handle possible failure. Signed-off-by: Amadeusz Sławiński Reviewed-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200327204729.397-7-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 2751ee29744e07417d2c3522cdc52a67bcd36243 Author: Amadeusz Sławiński Date: Fri Mar 27 16:47:28 2020 -0400 ASoC: topology: Check return value of pcm_new_ver [ Upstream commit b3677fc3d68dd942c92de52f0bd9dd8b472a40e6 ] Function pcm_new_ver can fail, so we should check it's return value and handle possible error. Signed-off-by: Amadeusz Sławiński Reviewed-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200327204729.397-6-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit a65227855e00e7eac6de44ecc219e1d1cb79f7cb Author: Amadeusz Sławiński Date: Fri Mar 27 16:47:27 2020 -0400 ASoC: topology: Check soc_tplg_add_route return value [ Upstream commit 6856e887eae3efc0fe56899cb3f969fe063171c5 ] Function soc_tplg_add_route can propagate error code from callback, we should check its return value and handle fail in correct way. Signed-off-by: Amadeusz Sławiński Reviewed-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200327204729.397-5-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit ce6786add7b6e295c8ab887ea55c96993093e337 Author: Amadeusz Sławiński Date: Fri Mar 27 16:47:26 2020 -0400 ASoC: topology: Check return value of soc_tplg_*_create [ Upstream commit 2ae548f30d7f6973388fc3769bb3c2f6fd13652b ] Functions soc_tplg_denum_create, soc_tplg_dmixer_create, soc_tplg_dbytes_create can fail, so their return values should be checked and error should be propagated. Signed-off-by: Amadeusz Sławiński Reviewed-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200327204729.397-4-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 66472b3ae184c6bdb1bb672d3c9273f27bad3547 Author: Amadeusz Sławiński Date: Fri Mar 27 16:47:25 2020 -0400 ASoC: topology: Check return value of soc_tplg_create_tlv [ Upstream commit 482db55ae87f3749db05810a38b1d618dfd4407c ] Function soc_tplg_create_tlv can fail, so we should check if it succeded or not and proceed appropriately. Signed-off-by: Amadeusz Sławiński Reviewed-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200327204729.397-3-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit e83efd0a2565823bfcdd8ddf548340bc10662019 Author: Amadeusz Sławiński Date: Fri Mar 27 16:47:24 2020 -0400 ASoC: topology: Add missing memory checks [ Upstream commit abc3caac24501008465fdb55c5e89e16d58d5a3d ] kstrdup is an allocation function and it can fail, so its return value should be checked and handled appropriately. In order to check all cases, we need to modify set_stream_info to return a value, so check that everything went correctly when doing kstrdup(). Later add proper checks and error handlers. Signed-off-by: Amadeusz Sławiński Reviewed-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20200327204729.397-2-amadeuszx.slawinski@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 1c416944adfcde8767d12c2fa804bf49e54e0ffd Author: Marek Szyprowski Date: Tue Mar 10 11:34:27 2020 +0100 drm/bridge: analogix_dp: Split bind() into probe() and real bind() [ Upstream commit 83a196773b8bc6702f49df1eddc848180e350340 ] Analogix_dp driver acquires all its resources in the ->bind() callback, what is a bit against the component driver based approach, where the driver initialization is split into a probe(), where all resources are gathered, and a bind(), where all objects are created and a compound driver is initialized. Extract all the resource related operations to analogix_dp_probe() and analogix_dp_remove(), then call them before/after registration of the device components from the main Exynos DP and Rockchip DP drivers. Also move the plat_data initialization to the probe() to make it available for the analogix_dp_probe() function. This fixes the multiple calls to the bind() of the DRM compound driver when the DP PHY driver is not yet loaded/probed: [drm] Exynos DRM: using 14400000.fimd device for DMA mapping operations exynos-drm exynos-drm: bound 14400000.fimd (ops fimd_component_ops [exynosdrm]) exynos-drm exynos-drm: bound 14450000.mixer (ops mixer_component_ops [exynosdrm]) exynos-dp 145b0000.dp-controller: no DP phy configured exynos-drm exynos-drm: failed to bind 145b0000.dp-controller (ops exynos_dp_ops [exynosdrm]): -517 exynos-drm exynos-drm: master bind failed: -517 ... [drm] Exynos DRM: using 14400000.fimd device for DMA mapping operations exynos-drm exynos-drm: bound 14400000.fimd (ops hdmi_enable [exynosdrm]) exynos-drm exynos-drm: bound 14450000.mixer (ops hdmi_enable [exynosdrm]) exynos-drm exynos-drm: bound 145b0000.dp-controller (ops hdmi_enable [exynosdrm]) exynos-drm exynos-drm: bound 14530000.hdmi (ops hdmi_enable [exynosdrm]) [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). Console: switching to colour frame buffer device 170x48 exynos-drm exynos-drm: fb0: exynosdrmfb frame buffer device [drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1 ... Signed-off-by: Marek Szyprowski Acked-by: Andy Yan Reviewed-by: Andrzej Hajda Signed-off-by: Andrzej Hajda Link: https://patchwork.freedesktop.org/patch/msgid/20200310103427.26048-1-m.szyprowski@samsung.com Signed-off-by: Sasha Levin commit d662c04426c0490ff47765c08e2a3f945aba7b0d Author: Jia He Date: Fri May 1 12:38:40 2020 +0800 vhost: vsock: kick send_pkt worker once device is started commit 0b841030625cde5f784dd62aec72d6a766faae70 upstream. Ning Bo reported an abnormal 2-second gap when booting Kata container [1]. The unconditional timeout was caused by VSOCK_DEFAULT_CONNECT_TIMEOUT of connecting from the client side. The vhost vsock client tries to connect an initializing virtio vsock server. The abnormal flow looks like: host-userspace vhost vsock guest vsock ============== =========== ============ connect() --------> vhost_transport_send_pkt_work() initializing | vq->private_data==NULL | will not be queued V schedule_timeout(2s) vhost_vsock_start() <--------- device ready set vq->private_data wait for 2s and failed connect() again vq->private_data!=NULL recv connecting pkt Details: 1. Host userspace sends a connect pkt, at that time, guest vsock is under initializing, hence the vhost_vsock_start has not been called. So vq->private_data==NULL, and the pkt is not been queued to send to guest 2. Then it sleeps for 2s 3. After guest vsock finishes initializing, vq->private_data is set 4. When host userspace wakes up after 2s, send connecting pkt again, everything is fine. As suggested by Stefano Garzarella, this fixes it by additional kicking the send_pkt worker in vhost_vsock_start once the virtio device is started. This makes the pending pkt sent again. After this patch, kata-runtime (with vsock enabled) boot time is reduced from 3s to 1s on a ThunderX2 arm64 server. [1] https://github.com/kata-containers/runtime/issues/1917 Reported-by: Ning Bo Suggested-by: Stefano Garzarella Signed-off-by: Jia He Link: https://lore.kernel.org/r/20200501043840.186557-1-justin.he@arm.com Signed-off-by: Michael S. Tsirkin Reviewed-by: Stefano Garzarella Signed-off-by: Greg Kroah-Hartman