commit b0c8835fc649454c33371f4617111cb5d60463e1 Author: Greg Kroah-Hartman Date: Sun Feb 7 15:37:17 2021 +0100 Linux 5.10.14 Tested-by: Igor Matheus Andrade Torrente Tested-by: Pavel Machek (CIP) Tested-by: Linux Kernel Functional Testing Tested-by: Guenter Roeck Tested-by: Jean-Denis Girard Tested-by: Jason Self Tested-by: Jon Hunter Link: https://lore.kernel.org/r/20210205140655.982616732@linuxfoundation.org Signed-off-by: Greg Kroah-Hartman commit b80df6517d350df10449a8fff755f24e847214db Author: Peter Zijlstra Date: Fri Jan 15 19:08:36 2021 +0100 workqueue: Restrict affinity change to rescuer [ Upstream commit 640f17c82460e9724fd256f0a1f5d99e7ff0bda4 ] create_worker() will already set the right affinity using kthread_bind_mask(), this means only the rescuer will need to change it's affinity. Howveer, while in cpu-hot-unplug a regular task is not allowed to run on online&&!active as it would be pushed away quite agressively. We need KTHREAD_IS_PER_CPU to survive in that environment. Therefore set the affinity after getting that magic flag. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Valentin Schneider Tested-by: Valentin Schneider Link: https://lkml.kernel.org/r/20210121103506.826629830@infradead.org Signed-off-by: Sasha Levin commit b20475a80b4bd2c7bc720c3a9a8337c36b20dd8c Author: Peter Zijlstra Date: Tue Jan 12 11:24:04 2021 +0100 kthread: Extract KTHREAD_IS_PER_CPU [ Upstream commit ac687e6e8c26181a33270efd1a2e2241377924b0 ] There is a need to distinguish geniune per-cpu kthreads from kthreads that happen to have a single CPU affinity. Geniune per-cpu kthreads are kthreads that are CPU affine for correctness, these will obviously have PF_KTHREAD set, but must also have PF_NO_SETAFFINITY set, lest userspace modify their affinity and ruins things. However, these two things are not sufficient, PF_NO_SETAFFINITY is also set on other tasks that have their affinities controlled through other means, like for instance workqueues. Therefore another bit is needed; it turns out kthread_create_per_cpu() already has such a bit: KTHREAD_IS_PER_CPU, which is used to make kthread_park()/kthread_unpark() work correctly. Expose this flag and remove the implicit setting of it from kthread_create_on_cpu(); the io_uring usage of it seems dubious at best. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Valentin Schneider Tested-by: Valentin Schneider Link: https://lkml.kernel.org/r/20210121103506.557620262@infradead.org Signed-off-by: Sasha Levin commit d8649eb8e3521c39781aebf0597baee560ef7b79 Author: Gayatri Kammela Date: Thu Jan 21 13:50:04 2021 -0800 x86/cpu: Add another Alder Lake CPU to the Intel family [ Upstream commit 6e1239c13953f3c2a76e70031f74ddca9ae57cd3 ] Add Alder Lake mobile CPU model number to Intel family. Signed-off-by: Gayatri Kammela Signed-off-by: Tony Luck Signed-off-by: Borislav Petkov Link: https://lkml.kernel.org/r/20210121215004.11618-1-tony.luck@intel.com Signed-off-by: Sasha Levin commit 9c8bb3eac07de8834d012e12ff0185a9dcc01331 Author: Josh Poimboeuf Date: Thu Jan 14 16:32:42 2021 -0600 objtool: Don't fail the kernel build on fatal errors [ Upstream commit 655cf86548a3938538642a6df27dd359e13c86bd ] This is basically a revert of commit 644592d32837 ("objtool: Fail the kernel build on fatal errors"). That change turned out to be more trouble than it's worth. Failing the build is an extreme measure which sometimes gets too much attention and blocks CI build testing. These fatal-type warnings aren't yet as rare as we'd hope, due to the ever-increasing matrix of supported toolchains/plugins and their fast-changing nature as of late. Also, there are more people (and bots) looking for objtool warnings than ever before, so even non-fatal warnings aren't likely to be ignored for long. Suggested-by: Nick Desaulniers Reviewed-by: Miroslav Benes Reviewed-by: Nick Desaulniers Reviewed-by: Kamalesh Babulal Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit 4587cb6f27a6f3518aa5195e6a2676ac02dac5aa Author: Oded Gabbay Date: Mon Jan 18 21:39:46 2021 +0200 habanalabs: disable FW events on device removal [ Upstream commit 2dc4a6d79168e7e426e8ddf8e7219c9ffd13b2b1 ] When device is removed, we need to make sure the F/W won't send us any more events because during the remove process we disable the interrupts. Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit 90981a2171b9fdb6d20046f7ce3d70f8c460e53e Author: Oded Gabbay Date: Mon Jan 18 13:19:51 2021 +0200 habanalabs: fix backward compatibility of idle check [ Upstream commit f8abaf379bfe19600f96ae79a6759eb37039ae05 ] Need to take the lower 32 bits of the driver's 64-bit idle mask and put it in the legacy 32-bit variable that the userspace reads to know the idle mask. Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit 4439d22c3758df25bb70243e0171e9728582f2a8 Author: Ofir Bitton Date: Sun Jan 17 09:39:37 2021 +0200 habanalabs: zero pci counters packet before submit to FW [ Upstream commit 9354f1b421f76f8368be13954f87d07bcbd6fffe ] Driver does not zero some pci counters packets before sending to FW. This causes an out of sync PI/CI between driver and FW. Signed-off-by: Ofir Bitton Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit e8911b02ccb635d6d12166c27ddeb010cf391d39 Author: Vladimir Stempen Date: Mon Jan 4 12:05:26 2021 -0500 drm/amd/display: Fixed corruptions on HPDRX link loss restore [ Upstream commit 4b08d8c78360241d270396a9de6eb774e88acd00 ] [why] Heavy corruption or blank screen reported on wake, with 6k display connected and FEC enabled [how] When Disable/Enable stream for display pipes on HPDRX, DC should take into account ODM split pipes. Tested-by: Daniel Wheeler Signed-off-by: Vladimir Stempen Reviewed-by: Aric Cyr Acked-by: Anson Jacob Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 932ab13b8af3e46551869478a2dc03d11c8ba0a3 Author: Nicholas Kazlauskas Date: Sun Dec 13 10:59:01 2020 -0500 drm/amd/display: Use hardware sequencer functions for PG control [ Upstream commit c74f865f14318217350aa33363577cb95b06eb82 ] [Why & How] These can differ per ASIC or not be present. Don't call the dcn20 ones directly but rather the ones defined by the ASIC init table. Tested-by: Daniel Wheeler Signed-off-by: Nicholas Kazlauskas Reviewed-by: Eric Yang Acked-by: Anson Jacob Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 95850b9d0b23c2a3a5b7bc0dc636aba95df182d3 Author: Bing Guo Date: Mon Jan 4 14:09:41 2021 -0500 drm/amd/display: Change function decide_dp_link_settings to avoid infinite looping [ Upstream commit 4716a7c50c5c66d6ddc42401e1e0ba13b492e105 ] Why: Function decide_dp_link_settings() loops infinitely when required bandwidth can't be supported. How: Check the required bandwidth against verified_link_cap before trying to find a link setting for it. Tested-by: Daniel Wheeler Signed-off-by: Bing Guo Reviewed-by: Jun Lei Acked-by: Anson Jacob Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit a2245a995563ff684aa5cbeb25aea2fb157c3675 Author: Aric Cyr Date: Thu Oct 29 17:45:19 2020 -0400 drm/amd/display: Allow PSTATE chnage when no displays are enabled [ Upstream commit 8bc3d461d0a95bbcc2a0a908bbadc87e198a86a8 ] [Why] When no displays are currently enabled, display driver should not disallow PSTATE switching. [How] Allow PSTATE switching if either the active configuration supports it, or there are no active displays. Tested-by: Daniel Wheeler Signed-off-by: Aric Cyr Reviewed-by: Jun Lei Acked-by: Anson Jacob Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit af2fc0f4acb618ac66c0820ad84c9da1a8e95d95 Author: Jake Wang Date: Fri Jan 8 12:27:51 2021 -0500 drm/amd/display: Update dram_clock_change_latency for DCN2.1 [ Upstream commit 901c1ec05ef277ce9d43cb806a225b28b3efe89a ] [WHY] dram clock change latencies get updated using ddr4 latency table, but does that update does not happen before validation. This value should not be the default and should be number received from df for better mode support. This may cause a PState hang on high refresh panels with short vblanks such as on 1080p 360hz or 300hz panels. [HOW] Update latency from 23.84 to 11.72. Signed-off-by: Sung Lee Reviewed-by: Tony Cheng Acked-by: Aurabindo Pillai Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin commit 89ca15b71b9148b9d6af42bb84173150167bca8a Author: Michael Ellerman Date: Tue Jan 19 15:18:00 2021 +1100 selftests/powerpc: Only test lwm/stmw on big endian [ Upstream commit dd3a44c06f7b4f14e90065bf05d62c255b20005f ] Newer binutils (>= 2.36) refuse to assemble lmw/stmw when building in little endian mode. That breaks compilation of our alignment handler test: /tmp/cco4l14N.s: Assembler messages: /tmp/cco4l14N.s:1440: Error: `lmw' invalid when little-endian /tmp/cco4l14N.s:1814: Error: `stmw' invalid when little-endian make[2]: *** [../../lib.mk:139: /output/kselftest/powerpc/alignment/alignment_handler] Error 1 These tests do pass on little endian machines, as the kernel will still emulate those instructions even when running little endian (which is arguably a kernel bug). But we don't really need to test that case, so ifdef those instructions out to get the alignment test building again. Reported-by: Libor Pechacek Signed-off-by: Michael Ellerman Tested-by: Libor Pechacek Link: https://lore.kernel.org/r/20210119041800.3093047-1-mpe@ellerman.id.au Signed-off-by: Sasha Levin commit 713373080c7ec02fdeeb81028913f6abdca16742 Author: Jeannie Stevenson Date: Fri Jan 15 16:06:30 2021 +0000 platform/x86: thinkpad_acpi: Add P53/73 firmware to fan_quirk_table for dual fan control [ Upstream commit 173aac2fef96972e42d33c0e1189e6f756a0d719 ] This commit enables dual fan control for the new Lenovo P53 and P73 laptop models. Signed-off-by: Jeannie Stevenson Link: https://lore.kernel.org/r/Pn_Xii4XYpQRFtgkf4PbNgieE89BAkHgLI1kWIq-zFudwh2A1DY5J_DJVHK06rMW_hGPHx_mPE33gd8mg9-8BxqJTaSC6hhPqAsfZlcNGH0=@protonmail.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit f243b5dd9837c89300fa1131624120567b0b26f5 Author: Chaitanya Kulkarni Date: Wed Jan 13 17:33:51 2021 -0800 nvmet: set right status on error in id-ns handler [ Upstream commit bffcd507780ea614b5543c66f2e37ce0d55cd449 ] The function nvmet_execute_identify_ns() doesn't set the status if call to nvmet_find_namespace() fails. In that case we set the status of the request to the value return by the nvmet_copy_sgl(). Set the status to NVME_SC_INVALID_NS and adjust the code such that request will have the right status on nvmet_find_namespace() failure. Without this patch :- NVME Identify Namespace 3: nsze : 0 ncap : 0 nuse : 0 nsfeat : 0 nlbaf : 0 flbas : 0 mc : 0 dpc : 0 dps : 0 nmic : 0 rescap : 0 fpi : 0 dlfeat : 0 nawun : 0 nawupf : 0 nacwu : 0 nabsn : 0 nabo : 0 nabspf : 0 noiob : 0 nvmcap : 0 mssrl : 0 mcl : 0 msrc : 0 nsattr : 0 nvmsetid: 0 anagrpid: 0 endgid : 0 nguid : 00000000000000000000000000000000 eui64 : 0000000000000000 lbaf 0 : ms:0 lbads:0 rp:0 (in use) With this patch-series :- feb3b88b501e (HEAD -> nvme-5.11) nvmet: remove extra variable in identify ns 6302aa67210a nvmet: remove extra variable in id-desclist ed57951da453 nvmet: remove extra variable in smart log nsid be384b8c24dc nvmet: set right status on error in id-ns handler NVMe status: INVALID_NS: The namespace or the format of that namespace is invalid(0xb) Signed-off-by: Chaitanya Kulkarni Reviewed-by: Sagi Grimberg Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 3e554aa3d08a1d319b60c8e8db31dcdd97f3b945 Author: Klaus Jensen Date: Fri Jan 15 07:30:46 2021 +0100 nvme-pci: allow use of cmb on v1.4 controllers [ Upstream commit 20d3bb92e84d417b0494a3b6867f0c86713db257 ] Since NVMe v1.4 the Controller Memory Buffer must be explicitly enabled by the host. Signed-off-by: Klaus Jensen [hch: avoid a local variable and add a comment] Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 82ae0714c344ac707900aacd9805773474059282 Author: Chao Leng Date: Thu Jan 14 17:09:26 2021 +0800 nvme-tcp: avoid request double completion for concurrent nvme_tcp_timeout [ Upstream commit 9ebbfe495ecd2e51bc92ac21ed5817c3b9e223ce ] Each name space has a request queue, if complete request long time, multi request queues may have time out requests at the same time, nvme_tcp_timeout will execute concurrently. Multi requests in different request queues may be queued in the same tcp queue, multi nvme_tcp_timeout may call nvme_tcp_stop_queue at the same time. The first nvme_tcp_stop_queue will clear NVME_TCP_Q_LIVE and continue stopping the tcp queue(cancel io_work), but the others check NVME_TCP_Q_LIVE is already cleared, and then directly complete the requests, complete request before the io work is completely canceled may lead to a use-after-free condition. Add a multex lock to serialize nvme_tcp_stop_queue. Signed-off-by: Chao Leng Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 3b87f9b0624595ec452154efcdca38ddc195147a Author: Chao Leng Date: Thu Jan 14 17:09:25 2021 +0800 nvme-rdma: avoid request double completion for concurrent nvme_rdma_timeout [ Upstream commit 7674073b2ed35ac951a49c425dec6b39d5a57140 ] A crash happens when inject completing request long time(nearly 30s). Each name space has a request queue, when inject completing request long time, multi request queues may have time out requests at the same time, nvme_rdma_timeout will execute concurrently. Multi requests in different request queues may be queued in the same rdma queue, multi nvme_rdma_timeout may call nvme_rdma_stop_queue at the same time. The first nvme_rdma_timeout will clear NVME_RDMA_Q_LIVE and continue stopping the rdma queue(drain qp), but the others check NVME_RDMA_Q_LIVE is already cleared, and then directly complete the requests, complete request before the qp is fully drained may lead to a use-after-free condition. Add a multex lock to serialize nvme_rdma_stop_queue. Signed-off-by: Chao Leng Tested-by: Israel Rukshin Reviewed-by: Israel Rukshin Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit 57f26d9d09d64e0b31bedffdd0de460215675ca9 Author: Revanth Rajashekar Date: Thu Jan 14 18:55:07 2021 -0700 nvme: check the PRINFO bit before deciding the host buffer length [ Upstream commit 4d6b1c95b974761c01cbad92321b82232b66d2a2 ] According to NVMe spec v1.4, section 8.3.1, the PRINFO bit and the metadata size play a vital role in deteriming the host buffer size. If PRIFNO bit is set and MS==8, the host doesn't add the metadata buffer, instead the controller adds it. Signed-off-by: Revanth Rajashekar Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin commit a9fd4ef6e50c22a303afaa9ebfd7e0fea0d5d1ff Author: lianzhi chang Date: Thu Jan 14 15:57:41 2021 +0800 udf: fix the problem that the disc content is not displayed [ Upstream commit 5cdc4a6950a883594e9640b1decb3fcf6222a594 ] When the capacity of the disc is too large (assuming the 4.7G specification), the disc (UDF file system) will be burned multiple times in the windows (Multisession Usage). When the remaining capacity of the CD is less than 300M (estimated value, for reference only), open the CD in the Linux system, the content of the CD is displayed as blank (the kernel will say "No VRS found"). Windows can display the contents of the CD normally. Through analysis, in the "fs/udf/super.c": udf_check_vsd function, the actual value of VSD_MAX_SECTOR_OFFSET may be much larger than 0x800000. According to the current code logic, it is found that the type of sbi->s_session is "__s32", when the remaining capacity of the disc is less than 300M (take a set of test values: sector=3154903040, sbi->s_session=1540464, sb->s_blocksize_bits=11 ), the calculation result of "sbi->s_session << sb->s_blocksize_bits" will overflow. Therefore, it is necessary to convert the type of s_session to "loff_t" (when udf_check_vsd starts, assign a value to _sector, which is also converted in this way), so that the result will not overflow, and then the content of the disc can be displayed normally. Link: https://lore.kernel.org/r/20210114075741.30448-1-changlianzhi@uniontech.com Signed-off-by: lianzhi chang Signed-off-by: Jan Kara Signed-off-by: Sasha Levin commit 40545c4dd90c96f8f4ecd7eac7b107e14f467619 Author: Sowjanya Komatineni Date: Tue Jan 12 11:02:41 2021 -0800 i2c: tegra: Create i2c_writesl_vi() to use with VI I2C for filling TX FIFO [ Upstream commit 2f3a0828d46166d4e7df227479ed31766ee67e4a ] VI I2C controller has known hardware bug where immediate multiple writes to TX_FIFO register gets stuck. Recommended software work around is to read I2C register after each write to TX_FIFO register to flush out the data. This patch implements this work around for VI I2C controller. Signed-off-by: Sowjanya Komatineni Reviewed-by: Dmitry Osipenko Acked-by: Thierry Reding Signed-off-by: Wolfram Sang Signed-off-by: Sasha Levin commit 6826f0b4a1591291e0a52d4138bfec8c1fc5e083 Author: Kai-Chuan Hsieh Date: Fri Jan 15 11:15:15 2021 +0800 ALSA: hda: Add Cometlake-R PCI ID [ Upstream commit f84d3a1ec375e46a55cc3ba85c04272b24bd3921 ] Add HD Audio Device PCI ID for the Intel Cometlake-R platform Reviewed-by: Kai Vehmanen Signed-off-by: Kai-Chuan Hsieh Link: https://lore.kernel.org/r/20210115031515.13100-1-kaichuan.hsieh@canonical.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit b45a47e9adfc8fb902acb1f2747e6c0c94af633d Author: Brian King Date: Tue Jan 12 09:06:38 2021 -0600 scsi: ibmvfc: Set default timeout to avoid crash during migration [ Upstream commit 764907293edc1af7ac857389af9dc858944f53dc ] While testing live partition mobility, we have observed occasional crashes of the Linux partition. What we've seen is that during the live migration, for specific configurations with large amounts of memory, slow network links, and workloads that are changing memory a lot, the partition can end up being suspended for 30 seconds or longer. This resulted in the following scenario: CPU 0 CPU 1 ------------------------------- ---------------------------------- scsi_queue_rq migration_store -> blk_mq_start_request -> rtas_ibm_suspend_me -> blk_add_timer -> on_each_cpu(rtas_percpu_suspend_me _______________________________________V | V -> IPI from CPU 1 -> rtas_percpu_suspend_me -> __rtas_suspend_last_cpu -- Linux partition suspended for > 30 seconds -- -> for_each_online_cpu(cpu) plpar_hcall_norets(H_PROD -> scsi_dispatch_cmd -> scsi_times_out -> scsi_abort_command -> queue_delayed_work -> ibmvfc_queuecommand_lck -> ibmvfc_send_event -> ibmvfc_send_crq - returns H_CLOSED <- returns SCSI_MLQUEUE_HOST_BUSY -> __blk_mq_requeue_request -> scmd_eh_abort_handler -> scsi_try_to_abort_cmd - returns SUCCESS -> scsi_queue_insert Normally, the SCMD_STATE_COMPLETE bit would protect against the command completion and the timeout, but that doesn't work here, since we don't check that at all in the SCSI_MLQUEUE_HOST_BUSY path. In this case we end up calling scsi_queue_insert on a request that has already been queued, or possibly even freed, and we crash. The patch below simply increases the default I/O timeout to avoid this race condition. This is also the timeout value that nearly all IBM SAN storage recommends setting as the default value. Link: https://lore.kernel.org/r/1610463998-19791-1-git-send-email-brking@linux.vnet.ibm.com Signed-off-by: Brian King Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit cedc60fbd7a1e0ed045325cb91c184a5771ec026 Author: Felix Fietkau Date: Fri Dec 18 19:47:16 2020 +0100 mac80211: fix encryption key selection for 802.3 xmit [ Upstream commit b101dd2d22f45d203010b40c739df346a0cbebef ] When using WEP, the default unicast key needs to be selected, instead of the STA PTK. Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20201218184718.93650-4-nbd@nbd.name Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 20790b2534f2057345ffd75e77c9758e4d94407e Author: Felix Fietkau Date: Fri Dec 18 19:47:17 2020 +0100 mac80211: fix fast-rx encryption check [ Upstream commit 622d3b4e39381262da7b18ca1ed1311df227de86 ] When using WEP, the default unicast key needs to be selected, instead of the STA PTK. Signed-off-by: Felix Fietkau Link: https://lore.kernel.org/r/20201218184718.93650-5-nbd@nbd.name Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit c2601c9c2a96bcb74e523382c870eb833ec5e2c9 Author: Shayne Chen Date: Tue Jan 12 11:20:28 2021 +0800 mac80211: fix incorrect strlen of .write in debugfs [ Upstream commit 6020d534fa012b80c6d13811dc4d2dfedca2e403 ] This fixes strlen mismatch problems happening in some .write callbacks of debugfs. When trying to configure airtime_flags in debugfs, an error appeared: ash: write error: Invalid argument The error is returned from kstrtou16() since a wrong length makes it miss the real end of input string. To fix this, use count as the string length, and set proper end of string for a char buffer. The debug print is shown - airtime_flags_write: count = 2, len = 8, where the actual length is 2, but "len = strlen(buf)" gets 8. Also cleanup the other similar cases for the sake of consistency. Signed-off-by: Sujuan Chen Signed-off-by: Ryder Lee Signed-off-by: Shayne Chen Link: https://lore.kernel.org/r/20210112032028.7482-1-shayne.chen@mediatek.com Signed-off-by: Johannes Berg Signed-off-by: Sasha Levin commit 9d6dbf4e37218aa0be3b2a751789abfa6ad039c0 Author: Josh Poimboeuf Date: Tue Jan 5 18:04:20 2021 -0600 objtool: Don't add empty symbols to the rbtree [ Upstream commit a2e38dffcd93541914aba52b30c6a52acca35201 ] Building with the Clang assembler shows the following warning: arch/x86/kernel/ftrace_64.o: warning: objtool: missing symbol for insn at offset 0x16 The Clang assembler strips section symbols. That ends up giving objtool's find_func_containing() much more test coverage than normal. Turns out, find_func_containing() doesn't work so well for overlapping symbols: 2: 000000000000000e 0 NOTYPE LOCAL DEFAULT 2 fgraph_trace 3: 000000000000000f 0 NOTYPE LOCAL DEFAULT 2 trace 4: 0000000000000000 165 FUNC GLOBAL DEFAULT 2 __fentry__ 5: 000000000000000e 0 NOTYPE GLOBAL DEFAULT 2 ftrace_stub The zero-length NOTYPE symbols are inside __fentry__(), confusing the rbtree search for any __fentry__() offset coming after a NOTYPE. Try to avoid this problem by not adding zero-length symbols to the rbtree. They're rare and aren't needed in the rbtree anyway. One caveat, this actually might not end up being the right fix. Non-empty overlapping symbols, if they exist, could have the same problem. But that would need bigger changes, let's see if we can get away with the easy fix for now. Reported-by: Arnd Bergmann Acked-by: Peter Zijlstra (Intel) Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin commit 91a585783dff06c1745af3e28ebba0ddc76e3c0e Author: Kai Vehmanen Date: Wed Jan 13 17:56:29 2021 +0200 ALSA: hda: Add AlderLake-P PCI ID and HDMI codec vid [ Upstream commit 5e941fc033e411118fb3a7d9e0b97f8cf702cd39 ] Add HD Audio PCI ID and HDMI codec vendor ID for Intel AlderLake-P. Signed-off-by: Kai Vehmanen Reviewed-by: Ranjani Sridharan Reviewed-by: Pierre-Louis Bossart Reviewed-by: Guennadi Liakhovetski Link: https://lore.kernel.org/r/20210113155629.4097057-1-kai.vehmanen@linux.intel.com Signed-off-by: Takashi Iwai Signed-off-by: Sasha Levin commit 1fe0ce2f9afda114675079125922850095792ee3 Author: Kai-Heng Feng Date: Wed Jan 13 02:11:23 2021 +0800 ASoC: SOF: Intel: hda: Resume codec to do jack detection [ Upstream commit bcd7059abc19e6ec5b2260dff6a008fb99c4eef9 ] Instead of queueing jackpoll_work, runtime resume the codec to let it use different jack detection methods based on jackpoll_interval. This partially matches SOF driver's behavior with commit a6e7d0a4bdb0 ("ALSA: hda: fix jack detection with Realtek codecs when in D3"), the difference is SOF unconditionally resumes the codec. Signed-off-by: Kai-Heng Feng Link: https://lore.kernel.org/r/20210112181128.1229827-1-kai.heng.feng@canonical.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin commit 946d15aa09d3c6b3414f54ada1879217aca03088 Author: Dinghao Liu Date: Fri Dec 25 16:35:20 2020 +0800 scsi: fnic: Fix memleak in vnic_dev_init_devcmd2 [ Upstream commit d6e3ae76728ccde49271d9f5acfebbea0c5625a3 ] When ioread32() returns 0xFFFFFFFF, we should execute cleanup functions like other error handling paths before returning. Link: https://lore.kernel.org/r/20201225083520.22015-1-dinghao.liu@zju.edu.cn Acked-by: Karan Tilak Kumar Signed-off-by: Dinghao Liu Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 47daa439c3892d676e0d3b6a89bfcd22b93d9c17 Author: Javed Hasan Date: Tue Dec 15 11:47:31 2020 -0800 scsi: libfc: Avoid invoking response handler twice if ep is already completed [ Upstream commit b2b0f16fa65e910a3ec8771206bb49ee87a54ac5 ] A race condition exists between the response handler getting called because of exchange_mgr_reset() (which clears out all the active XIDs) and the response we get via an interrupt. Sequence of events: rport ba0200: Port timeout, state PLOGI rport ba0200: Port entered PLOGI state from PLOGI state xid 1052: Exchange timer armed : 20000 msecs  xid timer armed here rport ba0200: Received LOGO request while in state PLOGI rport ba0200: Delete port rport ba0200: work event 3 rport ba0200: lld callback ev 3 bnx2fc: rport_event_hdlr: event = 3, port_id = 0xba0200 bnx2fc: ba0200 - rport not created Yet!! /* Here we reset any outstanding exchanges before freeing rport using the exch_mgr_reset() */ xid 1052: Exchange timer canceled /* Here we got two responses for one xid */ xid 1052: invoking resp(), esb 20000000 state 3 xid 1052: invoking resp(), esb 20000000 state 3 xid 1052: fc_rport_plogi_resp() : ep->resp_active 2 xid 1052: fc_rport_plogi_resp() : ep->resp_active 2 Skip the response if the exchange is already completed. Link: https://lore.kernel.org/r/20201215194731.2326-1-jhasan@marvell.com Signed-off-by: Javed Hasan Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 28693cc0fc0d45d771820cd54f16f4aed6c1790c Author: Martin Wilck Date: Mon Jan 11 15:25:41 2021 +0100 scsi: scsi_transport_srp: Don't block target in failfast state [ Upstream commit 72eeb7c7151302ef007f1acd018cbf6f30e50321 ] If the port is in SRP_RPORT_FAIL_FAST state when srp_reconnect_rport() is entered, a transition to SDEV_BLOCK would be illegal, and a kernel WARNING would be triggered. Skip scsi_target_block() in this case. Link: https://lore.kernel.org/r/20210111142541.21534-1-mwilck@suse.com Reviewed-by: Bart Van Assche Signed-off-by: Martin Wilck Signed-off-by: Martin K. Petersen Signed-off-by: Sasha Levin commit 5929bcb4a49d6a863c8c2400847d2a241dc9414c Author: Peter Zijlstra Date: Thu Jan 7 11:14:25 2021 +0100 x86: __always_inline __{rd,wr}msr() [ Upstream commit 66a425011c61e71560c234492d204e83cfb73d1d ] When the compiler choses to not inline the trivial MSR helpers: vmlinux.o: warning: objtool: __sev_es_nmi_complete()+0xce: call to __wrmsr.constprop.14() leaves .noinstr.text section Reported-by: Randy Dunlap Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Acked-by: Randy Dunlap # build-tested Link: https://lore.kernel.org/r/X/bf3gV+BW7kGEsB@hirez.programming.kicks-ass.net Signed-off-by: Sasha Levin commit d2c880ed2cffa50c20a02a70cc41861cf85ff5ef Author: Peter Zijlstra Date: Wed Jan 6 15:36:23 2021 +0100 locking/lockdep: Avoid noinstr warning for DEBUG_LOCKDEP [ Upstream commit 77ca93a6b1223e210e58e1000c09d8d420403c94 ] vmlinux.o: warning: objtool: lock_is_held_type()+0x60: call to check_flags.part.0() leaves .noinstr.text section Signed-off-by: Peter Zijlstra (Intel) Signed-off-by: Thomas Gleixner Link: https://lore.kernel.org/r/20210106144017.652218215@infradead.org Signed-off-by: Sasha Levin commit 2f2a4c04b8893de70f9d6ccc3fe9e2ccad9eb209 Author: Oded Gabbay Date: Mon Jan 11 13:49:38 2021 +0200 habanalabs: fix dma_addr passed to dma_mmap_coherent [ Upstream commit a9d4ef643430d638de1910377f50e0d492d85a43 ] When doing dma_alloc_coherent in the driver, we add a certain hard-coded offset to the DMA address before returning to the callee function. This offset is needed when our device use this DMA address to perform outbound transactions to the host. However, if we want to map the DMA'able memory to the user via dma_mmap_coherent(), we need to pass the original dma address, without this offset. Otherwise, we will get erronouos mapping. Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin commit a55c4bf2c8f0363a55c307ecc181466a7916c3ba Author: Arnold Gozum Date: Sat Dec 26 15:53:06 2020 -0500 platform/x86: intel-vbtn: Support for tablet mode on Dell Inspiron 7352 [ Upstream commit fcd38f178b785623c0325958225744f0d8a075c0 ] The Dell Inspiron 7352 is a 2-in-1 model that has chassis-type "Notebook". Add this model to the dmi_switches_allow_list. Signed-off-by: Arnold Gozum Link: https://lore.kernel.org/r/20201226205307.249659-1-arngozum@gmail.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit a8f69a32ee913906c401ee6ee67930f96fbd4edc Author: Hans de Goede Date: Thu Dec 24 14:51:58 2020 +0100 platform/x86: touchscreen_dmi: Add swap-x-y quirk for Goodix touchscreen on Estar Beauty HD tablet [ Upstream commit 46c54cf2706122c37497896d56d67b0c0aca2ede ] The Estar Beauty HD (MID 7316R) tablet uses a Goodix touchscreen, with the X and Y coordinates swapped compared to the LCD panel. Add a touchscreen_dmi entry for this adding a "touchscreen-swapped-x-y" device-property to the i2c-client instantiated for this device before the driver binds. This is the first entry of a Goodix touchscreen to touchscreen_dmi.c, so far DMI quirks for Goodix touchscreen's have been added directly to drivers/input/touchscreen/goodix.c. Currently there are 3 DMI tables in goodix.c: 1. rotated_screen[] for devices where the touchscreen is rotated 180 degrees vs the LCD panel 2. inverted_x_screen[] for devices where the X axis is inverted 3. nine_bytes_report[] for devices which use a non standard touch report size Arguably only 3. really needs to be inside the driver and the other 2 cases are better handled through the generic touchscreen DMI quirk mechanism from touchscreen_dmi.c, which allows adding device-props to any i2c-client. Esp. now that goodix.c is using the generic touchscreen_properties code. Alternative to the approach from this patch we could add a 4th dmi_system_id table for devices with swapped-x-y axis to goodix.c, but that seems undesirable. Cc: Bastien Nocera Cc: Dmitry Torokhov Signed-off-by: Hans de Goede Link: https://lore.kernel.org/r/20201224135158.10976-1-hdegoede@redhat.com Signed-off-by: Sasha Levin commit 4d06445ad762c4a740868a0ce263abf2d4d55727 Author: Srinivas Pandruvada Date: Sun Dec 20 23:18:59 2020 -0800 tools/power/x86/intel-speed-select: Set higher of cpuinfo_max_freq or base_frequency [ Upstream commit bbaa2e95e23e74791dd75b90d5ad9aad535acc6e ] In some case when BIOS disabled turbo, cpufreq cpuinfo_max_freq can be lower than base_frequency at higher config level. So, in that case set scaling_min_freq to base_frequency. Signed-off-by: Srinivas Pandruvada Link: https://lore.kernel.org/r/20201221071859.2783957-3-srinivas.pandruvada@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit f667433cb379ab9ee1cbefbfee09d4c8a3459563 Author: Srinivas Pandruvada Date: Sun Dec 20 23:18:58 2020 -0800 tools/power/x86/intel-speed-select: Set scaling_max_freq to base_frequency [ Upstream commit f981dc171c04c6cf5a35c712543b231ebf805832 ] When BIOS disables turbo, The scaling_max_freq in cpufreq sysfs will be limited to config level 0 base frequency. But when user selects a higher config levels, this will result in higher base frequency. But since scaling_max_freq is still old base frequency, the performance will still be limited. So when the turbo is disabled and cpufreq base_frequency is higher than scaling_max_freq, update the scaling_max_freq to the base_frequency. Signed-off-by: Srinivas Pandruvada Link: https://lore.kernel.org/r/20201221071859.2783957-2-srinivas.pandruvada@linux.intel.com Signed-off-by: Hans de Goede Signed-off-by: Sasha Levin commit 0c1a24a098a8d7340cb86e0a3b0ceb6ced2a11a2 Author: Tony Lindgren Date: Wed Dec 30 12:21:05 2020 +0200 phy: cpcap-usb: Fix warning for missing regulator_disable [ Upstream commit 764257d9069a9c19758b626cc1ba4ae079335d9e ] On deferred probe, we will get the following splat: cpcap-usb-phy cpcap-usb-phy.0: could not initialize VBUS or ID IIO: -517 WARNING: CPU: 0 PID: 21 at drivers/regulator/core.c:2123 regulator_put+0x68/0x78 ... (regulator_put) from [] (release_nodes+0x1b4/0x1fc) (release_nodes) from [] (really_probe+0x104/0x4a0) (really_probe) from [] (driver_probe_device+0x58/0xb4) Signed-off-by: Tony Lindgren Link: https://lore.kernel.org/r/20201230102105.11826-1-tony@atomide.com Signed-off-by: Vinod Koul Signed-off-by: Sasha Levin commit c4e8fa21a30be4656c58c209038b8f4270bf972a Author: Nadav Amit Date: Wed Jan 27 09:53:17 2021 -0800 iommu/vt-d: Do not use flush-queue when caching-mode is on commit 29b32839725f8c89a41cb6ee054c85f3116ea8b5 upstream. When an Intel IOMMU is virtualized, and a physical device is passed-through to the VM, changes of the virtual IOMMU need to be propagated to the physical IOMMU. The hypervisor therefore needs to monitor PTE mappings in the IOMMU page-tables. Intel specifications provide "caching-mode" capability that a virtual IOMMU uses to report that the IOMMU is virtualized and a TLB flush is needed after mapping to allow the hypervisor to propagate virtual IOMMU mappings to the physical IOMMU. To the best of my knowledge no real physical IOMMU reports "caching-mode" as turned on. Synchronizing the virtual and the physical IOMMU tables is expensive if the hypervisor is unaware which PTEs have changed, as the hypervisor is required to walk all the virtualized tables and look for changes. Consequently, domain flushes are much more expensive than page-specific flushes on virtualized IOMMUs with passthrough devices. The kernel therefore exploited the "caching-mode" indication to avoid domain flushing and use page-specific flushing in virtualized environments. See commit 78d5f0f500e6 ("intel-iommu: Avoid global flushes with caching mode.") This behavior changed after commit 13cf01744608 ("iommu/vt-d: Make use of iova deferred flushing"). Now, when batched TLB flushing is used (the default), full TLB domain flushes are performed frequently, requiring the hypervisor to perform expensive synchronization between the virtual TLB and the physical one. Getting batched TLB flushes to use page-specific invalidations again in such circumstances is not easy, since the TLB invalidation scheme assumes that "full" domain TLB flushes are performed for scalability. Disable batched TLB flushes when caching-mode is on, as the performance benefit from using batched TLB invalidations is likely to be much smaller than the overhead of the virtual-to-physical IOMMU page-tables synchronization. Fixes: 13cf01744608 ("iommu/vt-d: Make use of iova deferred flushing") Signed-off-by: Nadav Amit Cc: David Woodhouse Cc: Lu Baolu Cc: Joerg Roedel Cc: Will Deacon Cc: stable@vger.kernel.org Acked-by: Lu Baolu Link: https://lore.kernel.org/r/20210127175317.1600473-1-namit@vmware.com Signed-off-by: Joerg Roedel Signed-off-by: Greg Kroah-Hartman commit c7cd7a3b5076eab7f04e0365b401420cee2ce4e3 Author: Nick Desaulniers Date: Tue Nov 17 00:46:39 2020 +0100 ARM: 9025/1: Kconfig: CPU_BIG_ENDIAN depends on !LD_IS_LLD commit 28187dc8ebd938d574edfc6d9e0f9c51c21ff3f4 upstream. LLD does not yet support any big endian architectures. Make this config non-selectable when using LLD until LLD is fixed. Link: https://github.com/ClangBuiltLinux/linux/issues/965 Signed-off-by: Nick Desaulniers Tested-by: Nathan Chancellor Reviewed-by: Nathan Chancellor Reported-by: kbuild test robot Signed-off-by: Russell King Signed-off-by: Greg Kroah-Hartman commit d9655c6854a64924f4e08918b7a7fb7a7c16c94f Author: Mike Rapoport Date: Thu Feb 4 20:12:37 2021 +0200 Revert "x86/setup: don't remove E820_TYPE_RAM for pfn 0" commit 5c279c4cf206e03995e04fd3404fa95ffd243a97 upstream. This reverts commit bde9cfa3afe4324ec251e4af80ebf9b7afaf7afe. Changing the first memory page type from E820_TYPE_RESERVED to E820_TYPE_RAM makes it a part of "System RAM" resource rather than a reserved resource and this in turn causes devmem_is_allowed() to treat is as area that can be accessed but it is filled with zeroes instead of the actual data as previously. The change in /dev/mem output causes lilo to fail as was reported at slakware users forum, and probably other legacy applications will experience similar problems. Link: https://www.linuxquestions.org/questions/slackware-14/slackware-current-lilo-vesa-warnings-after-recent-updates-4175689617/#post6214439 Signed-off-by: Mike Rapoport Cc: stable@kernel.org Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman commit a2c7d0667cf3adb94b3b7e96dbc03151e97ab32e Author: Catalin Marinas Date: Mon Feb 1 19:06:33 2021 +0000 arm64: Do not pass tagged addresses to __is_lm_address() commit 91cb2c8b072e00632adf463b78b44f123d46a0fa upstream. Commit 519ea6f1c82f ("arm64: Fix kernel address detection of __is_lm_address()") fixed the incorrect validation of addresses below PAGE_OFFSET. However, it no longer allowed tagged addresses to be passed to virt_addr_valid(). Fix this by explicitly resetting the pointer tag prior to invoking __is_lm_address(). This is consistent with the __lm_to_phys() macro. Fixes: 519ea6f1c82f ("arm64: Fix kernel address detection of __is_lm_address()") Signed-off-by: Catalin Marinas Acked-by: Ard Biesheuvel Cc: # 5.4.x Cc: Will Deacon Cc: Vincenzo Frascino Cc: Mark Rutland Link: https://lore.kernel.org/r/20210201190634.22942-2-catalin.marinas@arm.com Signed-off-by: Greg Kroah-Hartman commit 25fd5f8f8a234d6ca0c7f71b65a59092b6d4a5f7 Author: Vincenzo Frascino Date: Tue Jan 26 13:40:56 2021 +0000 arm64: Fix kernel address detection of __is_lm_address() commit 519ea6f1c82fcdc9842908155ae379de47818778 upstream. Currently, the __is_lm_address() check just masks out the top 12 bits of the address, but if they are 0, it still yields a true result. This has as a side effect that virt_addr_valid() returns true even for invalid virtual addresses (e.g. 0x0). Fix the detection checking that it's actually a kernel address starting at PAGE_OFFSET. Fixes: 68dd8ef32162 ("arm64: memory: Fix virt_addr_valid() using __is_lm_address()") Cc: # 5.4.x Cc: Will Deacon Suggested-by: Catalin Marinas Reviewed-by: Catalin Marinas Acked-by: Mark Rutland Signed-off-by: Vincenzo Frascino Link: https://lore.kernel.org/r/20210126134056.45747-1-vincenzo.frascino@arm.com Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman commit beba2ac6b1205e614b7a39c3f9b0718c38fa57e7 Author: Robin Murphy Date: Tue Sep 22 15:16:50 2020 +0100 arm64: dts: meson: Describe G12b GPU as coherent commit 03544505cb10ddc73df3b6176e71cdb366834134 upstream. According to a downstream commit I found in the Khadas vendor kernel, the GPU on G12b is wired up for ACE-lite, so (now that Panfrost knows how to handle this properly) we should describe it as such. Otherwise the mismatch leads to all manner of fun with mismatched attributes and inadvertently snooping stale data from caches, which would account for at least some of the brokenness observed on this platform. Signed-off-by: Robin Murphy Tested-by: Neil Armstrong Reviewed-by: Neil Armstrong Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/765446e529e50b304af63432da7836c4d31eb8d4.1600780574.git.robin.murphy@arm.com Signed-off-by: Greg Kroah-Hartman commit 9e96f711171c689963b4232102b60dc4bf7ad6a4 Author: Robin Murphy Date: Tue Sep 22 15:16:49 2020 +0100 drm/panfrost: Support cache-coherent integrations commit 268af50f38b1f2199a2e85e38073d7a25c20190c upstream. When the GPU's ACE-Lite interface is fully wired up and capable of snooping CPU caches, it may be described as "dma-coherent" in devicetree, which will already inform the DMA layer not to perform unnecessary cache maintenance. However, we still need to ensure that the GPU uses the appropriate cacheable outer-shareable attributes in order to generate the requisite snoop signals, and that CPU mappings don't create a mismatch by using a non-cacheable type either. Signed-off-by: Robin Murphy Tested-by: Neil Armstrong Reviewed-by: Steven Price Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/7024ce18c1cb1a226e918037d49175571db0b436.1600780574.git.robin.murphy@arm.com Signed-off-by: Greg Kroah-Hartman commit b584862004020b3a555c48b549ed445d0a27e7e5 Author: Robin Murphy Date: Tue Sep 22 15:16:48 2020 +0100 iommu/io-pgtable-arm: Support coherency for Mali LPAE commit 728da60da7c1ec1e21ae64648e376666de3c279c upstream. Midgard GPUs have ACE-Lite master interfaces which allows systems to integrate them in an I/O-coherent manner. It seems that from the GPU's viewpoint, the rest of the system is its outer shareable domain, and so even when snoop signals are wired up, they are only emitted for outer shareable accesses. As such, setting the TTBR_SHARE_OUTER bit does indeed get coherent pagetable walks working nicely for the coherent T620 in the Arm Juno SoC. Signed-off-by: Robin Murphy Tested-by: Neil Armstrong Reviewed-by: Steven Price Acked-by: Will Deacon Signed-off-by: Neil Armstrong Link: https://patchwork.freedesktop.org/patch/msgid/8df778355378127ea7eccc9521d6427e3e48d4f2.1600780574.git.robin.murphy@arm.com Signed-off-by: Greg Kroah-Hartman commit 3766a00d765dca6e2c05b18ab95c39fb2d00802c Author: Lijun Pan Date: Wed Jan 27 19:34:42 2021 -0600 ibmvnic: Ensure that CRQ entry read are correctly ordered commit e41aec79e62fa50f940cf222d1e9577f14e149dc upstream. Ensure that received Command-Response Queue (CRQ) entries are properly read in order by the driver. dma_rmb barrier has been added before accessing the CRQ descriptor to ensure the entire descriptor is read before processing. Fixes: 032c5e82847a ("Driver for IBM System i/p VNIC protocol") Signed-off-by: Lijun Pan Link: https://lore.kernel.org/r/20210128013442.88319-1-ljp@linux.ibm.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit c71bfc5f13c363cbf03a4623b8bf2836d321a4ff Author: Rasmus Villemoes Date: Mon Jan 25 13:41:16 2021 +0100 net: switchdev: don't set port_obj_info->handled true when -EOPNOTSUPP commit 20776b465c0c249f5e5b5b4fe077cd24ef1cda86 upstream. It's not true that switchdev_port_obj_notify() only inspects the ->handled field of "struct switchdev_notifier_port_obj_info" if call_switchdev_blocking_notifiers() returns 0 - there's a WARN_ON() triggering for a non-zero return combined with ->handled not being true. But the real problem here is that -EOPNOTSUPP is not being properly handled. The wrapper functions switchdev_handle_port_obj_add() et al change a return value of -EOPNOTSUPP to 0, and the treatment of ->handled in switchdev_port_obj_notify() seems to be designed to change that back to -EOPNOTSUPP in case nobody actually acted on the notifier (i.e., everybody returned -EOPNOTSUPP). Currently, as soon as some device down the stack passes the check_cb() check, ->handled gets set to true, which means that switchdev_port_obj_notify() cannot actually ever return -EOPNOTSUPP. This, for example, means that the detection of hardware offload support in the MRP code is broken: switchdev_port_obj_add() used by br_mrp_switchdev_send_ring_test() always returns 0, so since the MRP code thinks the generation of MRP test frames has been offloaded, no such frames are actually put on the wire. Similarly, br_mrp_switchdev_set_ring_role() also always returns 0, causing mrp->ring_role_offloaded to be set to 1. To fix this, continue to set ->handled true if any callback returns success or any error distinct from -EOPNOTSUPP. But if all the callbacks return -EOPNOTSUPP, make sure that ->handled stays false, so the logic in switchdev_port_obj_notify() can propagate that information. Fixes: 9a9f26e8f7ea ("bridge: mrp: Connect MRP API with the switchdev API") Fixes: f30f0601eb93 ("switchdev: Add helpers to aid traversal through lower devices") Reviewed-by: Petr Machata Signed-off-by: Rasmus Villemoes Link: https://lore.kernel.org/r/20210125124116.102928-1-rasmus.villemoes@prevas.dk Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 370ce41d2e5847f120e251067e4943e5fd1a3541 Author: Pan Bian Date: Thu Jan 21 04:33:43 2021 -0800 net: dsa: bcm_sf2: put device node before return commit cf3c46631e1637582f517a574c77cd6c05793817 upstream. Put the device node dn before return error code on failure path. Fixes: 461cd1b03e32 ("net: dsa: bcm_sf2: Register our slave MDIO bus") Signed-off-by: Pan Bian Link: https://lore.kernel.org/r/20210121123343.26330-1-bianpan2016@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit a555c2faf02e116a9be2413962114ff548684de5 Author: Ido Schimmel Date: Thu Jan 28 16:48:20 2021 +0200 mlxsw: spectrum_span: Do not overwrite policer configuration commit b6f6881aaf2344bf35a4221810737abe5fd210af upstream. The purpose of the delayed work in the SPAN module is to potentially update the destination port and various encapsulation parameters of SPAN agents that point to a VLAN device or a GRE tap. The destination port can change following the insertion of a new route, for example. SPAN agents that point to a physical port or the CPU port are static and never change throughout the lifetime of the SPAN agent. Therefore, skip over them in the delayed work. This fixes an issue where the delayed work overwrites the policer that was set on a SPAN agent pointing to the CPU. Modifying the delayed work to inherit the original policer configuration is error-prone, as the same will be needed for any new parameter. Fixes: 4039504e6a0c ("mlxsw: spectrum_span: Allow setting policer on a SPAN agent") Reviewed-by: Petr Machata Signed-off-by: Ido Schimmel Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 3c564a9f9e4378a7c8b18f4281cd42e1665f0aa4 Author: Voon Weifeng Date: Tue Jan 26 18:08:44 2021 +0800 stmmac: intel: Configure EHL PSE0 GbE and PSE1 GbE to 32 bits DMA addressing commit 7cfc4486e7ea25bd405df162d9c131ee5d4c6c93 upstream. Fix an issue where dump stack is printed and Reset Adapter occurs when PSE0 GbE or/and PSE1 GbE is/are enabled. EHL PSE0 GbE and PSE1 GbE use 32 bits DMA addressing whereas EHL PCH GbE uses 64 bits DMA addressing. [ 25.535095] ------------[ cut here ]------------ [ 25.540276] NETDEV WATCHDOG: enp0s29f2 (intel-eth-pci): transmit queue 2 timed out [ 25.548749] WARNING: CPU: 2 PID: 0 at net/sched/sch_generic.c:443 dev_watchdog+0x259/0x260 [ 25.558004] Modules linked in: 8021q bnep bluetooth ecryptfs snd_hda_codec_hdmi intel_gpy marvell intel_ishtp_loader intel_ishtp_hid iTCO_wdt mei_hdcp iTCO_vendor_support x86_pkg_temp_thermal kvm_intel dwmac_intel stmmac kvm igb pcs_xpcs irqbypass phylink snd_hda_intel intel_rapl_msr pcspkr dca snd_hda_codec i915 i2c_i801 i2c_smbus libphy intel_ish_ipc snd_hda_core mei_me intel_ishtp mei spi_dw_pci 8250_lpss spi_dw thermal dw_dmac_core parport_pc tpm_crb tpm_tis parport tpm_tis_core tpm intel_pmc_core sch_fq_codel uhid fuse configfs snd_sof_pci snd_sof_intel_byt snd_sof_intel_ipc snd_sof_intel_hda_common snd_sof_xtensa_dsp snd_sof snd_soc_acpi_intel_match snd_soc_acpi snd_intel_dspcfg ledtrig_audio snd_soc_core snd_compress ac97_bus snd_pcm snd_timer snd soundcore [ 25.633795] CPU: 2 PID: 0 Comm: swapper/2 Tainted: G U 5.11.0-rc4-intel-lts-MISMAIL5+ #5 [ 25.644306] Hardware name: Intel Corporation Elkhart Lake Embedded Platform/ElkhartLake LPDDR4x T4 RVP1, BIOS EHLSFWI1.R00.2434.A00.2010231402 10/23/2020 [ 25.659674] RIP: 0010:dev_watchdog+0x259/0x260 [ 25.664650] Code: e8 3b 6b 60 ff eb 98 4c 89 ef c6 05 ec e7 bf 00 01 e8 fb e5 fa ff 89 d9 4c 89 ee 48 c7 c7 78 31 d2 9e 48 89 c2 e8 79 1b 18 00 <0f> 0b e9 77 ff ff ff 0f 1f 44 00 00 48 c7 47 08 00 00 00 00 48 c7 [ 25.685647] RSP: 0018:ffffb7ca80160eb8 EFLAGS: 00010286 [ 25.691498] RAX: 0000000000000000 RBX: 0000000000000002 RCX: 0000000000000103 [ 25.699483] RDX: 0000000080000103 RSI: 00000000000000f6 RDI: 00000000ffffffff [ 25.707465] RBP: ffff985709ce0440 R08: 0000000000000000 R09: c0000000ffffefff [ 25.715455] R10: ffffb7ca80160cf0 R11: ffffb7ca80160ce8 R12: ffff985709ce039c [ 25.723438] R13: ffff985709ce0000 R14: 0000000000000008 R15: ffff9857068af940 [ 25.731425] FS: 0000000000000000(0000) GS:ffff985864300000(0000) knlGS:0000000000000000 [ 25.740481] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 25.746913] CR2: 00005567f8bb76b8 CR3: 00000001f8e0a000 CR4: 0000000000350ee0 [ 25.754900] Call Trace: [ 25.757631] [ 25.759891] ? qdisc_put_unlocked+0x30/0x30 [ 25.764565] ? qdisc_put_unlocked+0x30/0x30 [ 25.769245] call_timer_fn+0x2e/0x140 [ 25.773346] run_timer_softirq+0x1f3/0x430 [ 25.777932] ? __hrtimer_run_queues+0x12c/0x2c0 [ 25.783005] ? ktime_get+0x3e/0xa0 [ 25.786812] __do_softirq+0xa6/0x2ef [ 25.790816] asm_call_irq_on_stack+0xf/0x20 [ 25.795501] [ 25.797852] do_softirq_own_stack+0x5d/0x80 [ 25.802538] irq_exit_rcu+0x94/0xb0 [ 25.806475] sysvec_apic_timer_interrupt+0x42/0xc0 [ 25.811836] asm_sysvec_apic_timer_interrupt+0x12/0x20 [ 25.817586] RIP: 0010:cpuidle_enter_state+0xd9/0x370 [ 25.823142] Code: 85 c0 0f 8f 0a 02 00 00 31 ff e8 22 d5 7e ff 45 84 ff 74 12 9c 58 f6 c4 02 0f 85 47 02 00 00 31 ff e8 7b a0 84 ff fb 45 85 f6 <0f> 88 ab 00 00 00 49 63 ce 48 2b 2c 24 48 89 c8 48 6b d1 68 48 c1 [ 25.844140] RSP: 0018:ffffb7ca800f7e80 EFLAGS: 00000206 [ 25.849996] RAX: ffff985864300000 RBX: 0000000000000003 RCX: 000000000000001f [ 25.857975] RDX: 00000005f2028ea8 RSI: ffffffff9ec5907f RDI: ffffffff9ec62a5d [ 25.865961] RBP: 00000005f2028ea8 R08: 0000000000000000 R09: 0000000000029d00 [ 25.873947] R10: 000000137b0e0508 R11: ffff9858643294e4 R12: ffff9858643336d0 [ 25.881935] R13: ffffffff9ef74b00 R14: 0000000000000003 R15: 0000000000000000 [ 25.889918] cpuidle_enter+0x29/0x40 [ 25.893922] do_idle+0x24a/0x290 [ 25.897536] cpu_startup_entry+0x19/0x20 [ 25.901930] start_secondary+0x128/0x160 [ 25.906326] secondary_startup_64_no_verify+0xb0/0xbb [ 25.911983] ---[ end trace b4c0c8195d0ba61f ]--- [ 25.917193] intel-eth-pci 0000:00:1d.2 enp0s29f2: Reset adapter. Fixes: 67c08ac4140a ("net: stmmac: add EHL PSE0 & PSE1 1Gbps PCI info and PCI ID") Signed-off-by: Voon Weifeng Co-developed-by: Mohammad Athari Bin Ismail Signed-off-by: Mohammad Athari Bin Ismail Link: https://lore.kernel.org/r/20210126100844.30326-1-mohammad.athari.ismail@intel.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit fb8e6a0b3c660a4f935d1d45d71a7169f869f521 Author: Kevin Hao Date: Thu Jan 21 15:09:06 2021 +0800 net: octeontx2: Make sure the buffer is 128 byte aligned commit db2805150a0f27c00ad286a29109397a7723adad upstream. The octeontx2 hardware needs the buffer to be 128 byte aligned. But in the current implementation of napi_alloc_frag(), it can't guarantee the return address is 128 byte aligned even the request size is a multiple of 128 bytes, so we have to request an extra 128 bytes and use the PTR_ALIGN() to make sure that the buffer is aligned correctly. Fixes: 7a36e4918e30 ("octeontx2-pf: Use the napi_alloc_frag() to alloc the pool buffers") Reported-by: Subbaraya Sundeep Signed-off-by: Kevin Hao Tested-by: Subbaraya Sundeep Link: https://lore.kernel.org/r/20210121070906.25380-1-haokexin@gmail.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit d51f7ff5413bc18cb7936f21d19eed2829f28d6d Author: Pan Bian Date: Wed Jan 20 04:20:37 2021 -0800 net: fec: put child node on error path commit 0607a2cddb60f4548b55e28ac56a8d73493a45bb upstream. Also decrement the reference count of child device on error path. Fixes: 3e782985cb3c ("net: ethernet: fec: Allow configuration of MDIO bus speed") Signed-off-by: Pan Bian Link: https://lore.kernel.org/r/20210120122037.83897-1-bianpan2016@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit cedbfddf4dabafe3b5ae0124cc6f91ef0eae2b46 Author: Pan Bian Date: Wed Jan 20 03:07:44 2021 -0800 net: stmmac: dwmac-intel-plat: remove config data on error commit 3765d86ffcd346913c372d69cdc05dc8d56119ac upstream. Remove the config data when rate setting fails. Fixes: 9efc9b2b04c7 ("net: stmmac: Add dwmac-intel-plat for GBE driver") Signed-off-by: Pan Bian Link: https://lore.kernel.org/r/20210120110745.36412-1-bianpan2016@163.com Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman commit 1aa4ee0ec7fe929bd46ae20d9457f0a242115643 Author: Marek Vasut Date: Wed Jan 20 04:05:02 2021 +0100 net: dsa: microchip: Adjust reset release timing to match reference reset circuit commit 1c45ba93d34cd6af75228f34d0675200c81738b5 upstream. KSZ8794CNX datasheet section 8.0 RESET CIRCUIT describes recommended circuit for interfacing with CPU/FPGA reset consisting of 10k pullup resistor and 10uF capacitor to ground. This circuit takes ~100 ms to rise enough to release the reset. For maximum supply voltage VDDIO=3.3V VIH=2.0V R=10kR C=10uF that is VDDIO - VIH t = R * C * -ln( ------------- ) = 10000*0.00001*-(-0.93)=0.093 s VDDIO so we need ~95 ms for the reset to really de-assert, and then the original 100us for the switch itself to come out of reset. Simply msleep() for 100 ms which fits the constraint with a bit of extra space. Fixes: 5b797980908a ("net: dsa: microchip: Implement recommended reset timing") Reviewed-by: Florian Fainelli Signed-off-by: Marek Vasut Cc: Michael Grzeschik Reviewed-by: Paul Barker Reviewed-by: Andrew Lunn Link: https://lore.kernel.org/r/20210120030502.617185-1-marex@denx.de Signed-off-by: Jakub Kicinski Signed-off-by: Greg Kroah-Hartman