Update to 6.4.12 (#16) * crypto, cifs: fix error handling in extract_iter_to_sg() [ Upstream commit f443fd5af5dbd531f880d3645d5dd36976cf087f ] Fix error handling in extract_iter_to_sg(). Pages need to be unpinned, not put in extract_user_to_sg() when handling IOVEC/UBUF sources. The bug may result in a warning like the following: WARNING: CPU: 1 PID: 20384 at mm/gup.c:229 __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:27 [inline] WARNING: CPU: 1 PID: 20384 at mm/gup.c:229 arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline] WARNING: CPU: 1 PID: 20384 at mm/gup.c:229 raw_atomic_add include/linux/atomic/atomic-arch-fallback.h:537 [inline] WARNING: CPU: 1 PID: 20384 at mm/gup.c:229 atomic_add include/linux/atomic/atomic-instrumented.h:105 [inline] WARNING: CPU: 1 PID: 20384 at mm/gup.c:229 try_grab_page+0x108/0x160 mm/gup.c:252 ... pc : try_grab_page+0x108/0x160 mm/gup.c:229 lr : follow_page_pte+0x174/0x3e4 mm/gup.c:651 ... Call trace: __lse_atomic_add arch/arm64/include/asm/atomic_lse.h:27 [inline] arch_atomic_add arch/arm64/include/asm/atomic.h:28 [inline] raw_atomic_add include/linux/atomic/atomic-arch-fallback.h:537 [inline] atomic_add include/linux/atomic/atomic-instrumented.h:105 [inline] try_grab_page+0x108/0x160 mm/gup.c:252 follow_pmd_mask mm/gup.c:734 [inline] follow_pud_mask mm/gup.c:765 [inline] follow_p4d_mask mm/gup.c:782 [inline] follow_page_mask+0x12c/0x2e4 mm/gup.c:839 __get_user_pages+0x174/0x30c mm/gup.c:1217 __get_user_pages_locked mm/gup.c:1448 [inline] __gup_longterm_locked+0x94/0x8f4 mm/gup.c:2142 internal_get_user_pages_fast+0x970/0xb60 mm/gup.c:3140 pin_user_pages_fast+0x4c/0x60 mm/gup.c:3246 iov_iter_extract_user_pages lib/iov_iter.c:1768 [inline] iov_iter_extract_pages+0xc8/0x54c lib/iov_iter.c:1831 extract_user_to_sg lib/scatterlist.c:1123 [inline] extract_iter_to_sg lib/scatterlist.c:1349 [inline] extract_iter_to_sg+0x26c/0x6fc lib/scatterlist.c:1339 hash_sendmsg+0xc0/0x43c crypto/algif_hash.c:117 sock_sendmsg_nosec net/socket.c:725 [inline] sock_sendmsg+0x54/0x60 net/socket.c:748 ____sys_sendmsg+0x270/0x2ac net/socket.c:2494 ___sys_sendmsg+0x80/0xdc net/socket.c:2548 __sys_sendmsg+0x68/0xc4 net/socket.c:2577 __do_sys_sendmsg net/socket.c:2586 [inline] __se_sys_sendmsg net/socket.c:2584 [inline] __arm64_sys_sendmsg+0x24/0x30 net/socket.c:2584 __invoke_syscall arch/arm64/kernel/syscall.c:38 [inline] invoke_syscall+0x48/0x114 arch/arm64/kernel/syscall.c:52 el0_svc_common.constprop.0+0x44/0xe4 arch/arm64/kernel/syscall.c:142 do_el0_svc+0x38/0xa4 arch/arm64/kernel/syscall.c:191 el0_svc+0x2c/0xb0 arch/arm64/kernel/entry-common.c:647 el0t_64_sync_handler+0xc0/0xc4 arch/arm64/kernel/entry-common.c:665 el0t_64_sync+0x19c/0x1a0 arch/arm64/kernel/entry.S:591 Link: https://lkml.kernel.org/r/20571.1690369076@warthog.procyon.org.uk Fixes: 018584697533 ("netfs: Add a function to extract an iterator into a scatterlist") Reported-by: syzbot+9b82859567f2e50c123e@syzkaller.appspotmail.com Link: https://lore.kernel.org/linux-mm/000000000000273d0105ff97bf56@google.com/ Signed-off-by: David Howells Reviewed-by: David Hildenbrand Acked-by: Steve French Cc: Sven Schnelle Cc: Herbert Xu Cc: Jeff Layton Cc: Shyam Prasad N Cc: Rohith Surabattula Cc: Jens Axboe Cc: "David S. Miller" Cc: Eric Dumazet Cc: Jakub Kicinski Cc: Paolo Abeni Cc: Matthew Wilcox Cc: Signed-off-by: Andrew Morton Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman * net: phy: at803x: Use devm_regulator_get_enable_optional() [ Upstream commit 988e8d90b3dc482637532e61bc2d58bfc4af5167 ] Use devm_regulator_get_enable_optional() instead of hand writing it. It saves some line of code. Signed-off-by: Christophe JAILLET Reviewed-by: Andrew Lunn Signed-off-by: David S. Miller Stable-dep-of: e58f30246c35 ("net: phy: at803x: fix the wol setting functions") Signed-off-by: Sasha Levin * net: phy: at803x: fix the wol setting functions [ Upstream commit e58f30246c35c126c7571065b33bee4b3b1d2ef8 ] In commit 7beecaf7d507 ("net: phy: at803x: improve the WOL feature"), it seems not correct to use a wol_en bit in a 1588 Control Register which is only available on AR8031/AR8033(share the same phy_id) to determine if WoL is enabled. Change it back to use AT803X_INTR_ENABLE_WOL for determining the WoL status which is applicable on all chips supporting wol. Also update the at803x_set_wol() function to only update the 1588 register on chips having it. After this change, disabling wol at probe from commit d7cd5e06c9dd ("net: phy: at803x: disable WOL at probe") is no longer needed. Change it to just disable the WoL bit in 1588 register for AR8031/AR8033 to be aligned with AT803X_INTR_ENABLE_WOL in probe. Fixes: 7beecaf7d507 ("net: phy: at803x: improve the WOL feature") Signed-off-by: Li Yang Reviewed-by: Viorel Suman Reviewed-by: Wei Fang Reviewed-by: Russell King (Oracle) Signed-off-by: David S. Miller Signed-off-by: Sasha Levin * drm/amd/display: Update DTBCLK for DCN32 [ Upstream commit 128c1ca0303fe764a4cde5f761e72810d9e40b6e ] [Why&How] - Implement interface to program DTBCLK DTO’s according to reference DTBCLK returned by PMFW - This is required because DTO programming requires exact DTBCLK reference freq or it could result in underflow Acked-by: Aurabindo Pillai Signed-off-by: Alvin Lee Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin * drm/scheduler: set entity to NULL in drm_sched_entity_pop_job() [ Upstream commit 96c7c2f4d5bd94b15fe63448c087f01607b56f4a ] It already happend a few times that patches slipped through which implemented access to an entity through a job that was already removed from the entities queue. Since jobs and entities might have different lifecycles, this can potentially cause UAF bugs. In order to make it obvious that a jobs entity pointer shouldn't be accessed after drm_sched_entity_pop_job() was called successfully, set the jobs entity pointer to NULL once the job is removed from the entity queue. Moreover, debugging a potential NULL pointer dereference is way easier than potentially corrupted memory through a UAF. Signed-off-by: Danilo Krummrich Link: https://lore.kernel.org/r/20230418100453.4433-1-dakr@redhat.com Reviewed-by: Luben Tuikov Signed-off-by: Luben Tuikov Signed-off-by: Sasha Levin * drm/amdgpu: fix calltrace warning in amddrm_buddy_fini [ Upstream commit 01382501509871d0799bab6bd412c228486af5bf ] The following call trace is observed when removing the amdgpu driver, which is caused by that BOs allocated for psp are not freed until removing. [61811.450562] RIP: 0010:amddrm_buddy_fini.cold+0x29/0x47 [amddrm_buddy] [61811.450577] Call Trace: [61811.450577] [61811.450579] amdgpu_vram_mgr_fini+0x135/0x1c0 [amdgpu] [61811.450728] amdgpu_ttm_fini+0x207/0x290 [amdgpu] [61811.450870] amdgpu_bo_fini+0x27/0xa0 [amdgpu] [61811.451012] gmc_v9_0_sw_fini+0x4a/0x60 [amdgpu] [61811.451166] amdgpu_device_fini_sw+0x117/0x520 [amdgpu] [61811.451306] amdgpu_driver_release_kms+0x16/0x30 [amdgpu] [61811.451447] devm_drm_dev_init_release+0x4d/0x80 [drm] [61811.451466] devm_action_release+0x15/0x20 [61811.451469] release_nodes+0x40/0xb0 [61811.451471] devres_release_all+0x9b/0xd0 [61811.451473] __device_release_driver+0x1bb/0x2a0 [61811.451476] driver_detach+0xf3/0x140 [61811.451479] bus_remove_driver+0x6c/0xf0 [61811.451481] driver_unregister+0x31/0x60 [61811.451483] pci_unregister_driver+0x40/0x90 [61811.451486] amdgpu_exit+0x15/0x447 [amdgpu] For smu v13_0_2, if the GPU supports xgmi, refer to commit f5c7e7797060 ("drm/amdgpu: Adjust removal control flow for smu v13_0_2"), it will run gpu recover in AMDGPU_RESET_FOR_DEVICE_REMOVE mode when removing, which makes all devices in hive list have hw reset but no resume except the basic ip blocks, then other ip blocks will not call .hw_fini according to ip_block.status.hw. Since psp_free_shared_bufs just includes some software operations, so move it to psp_sw_fini. Reviewed-by: Guchun Chen Reviewed-by: Feifei Xu Signed-off-by: Longlong Yao Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin * drm/amdgpu: Fix integer overflow in amdgpu_cs_pass1 [ Upstream commit 87c2213e85bd81e4a9a4d0880c256568794ae388 ] The type of size is unsigned int, if size is 0x40000000, there will be an integer overflow, size will be zero after size *= sizeof(uint32_t), will cause uninitialized memory to be referenced later. Reviewed-by: Christian König Signed-off-by: hackyzh002 Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin * drm/amdgpu: fix memory leak in mes self test [ Upstream commit 31d7c3a4fc3d312a0646990767647925d5bde540 ] The fences associated with mes queue have to be freed up during amdgpu_ring_fini. Signed-off-by: Jack Xiao Reviewed-by: Hawking Zhang Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin * Revert "drm/amd/display: disable SubVP + DRR to prevent underflow" [ Upstream commit f38129bb081758176dd78304faaee95007fb8838 ] This reverts commit 80c6d6804f31451848a3956a70c2bcb1f07cfcb0. The orignal commit was intended as a workaround to prevent underflow and flickering when using one normal monitor and the other high refresh rate monitor (> 120Hz). This patch is being reverted in favour of a software solution to enable SubVP+DRR Signed-off-by: Aurabindo Pillai Reviewed-by: Rodrigo Siqueira Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin * ASoC: Intel: sof_sdw: add quirk for MTL RVP [ Upstream commit 289e1df00e49a229a1c924c059242e759a552f01 ] We should use RT711_JD2_100K for on board rt711. Signed-off-by: Bard Liao * ASoC: Intel: sof_sdw: add quirk for LNL RVP [ Upstream commit dfe25fea968dc4884e12d471c8263f0f611b380a ] We should use RT711_JD2_100K for on board rt711 Signed-off-by: Peter Ujfalusi Signed-off-by: Pierre-Louis Bossart Reviewed-by: Bard Liao Link: https://lore.kernel.org/r/20230512173305.65399-9-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin * PCI: tegra194: Fix possible array out of bounds access [ Upstream commit 205b3d02d57ce6dce96f6d2b9c230f56a9bf9817 ] Add check to fix the possible array out of bounds violation by making speed equal to GEN1_CORE_CLK_FREQ when its value is more than the size of "pcie_gen_freq" array. This array has size of four but possible speed (CLS) values are from "0 to 0xF". So, "speed - 1" values are "-1 to 0xE". Suggested-by: Bjorn Helgaas Signed-off-by: Sumit Gupta Link: https://lore.kernel.org/lkml/72b9168b-d4d6-4312-32ea-69358df2f2d0@nvidia.com/ Acked-by: Lorenzo Pieralisi Signed-off-by: Thierry Reding Signed-off-by: Sasha Levin * ASoC: cs35l56: Move DSP part string generation so that it is done only once [ Upstream commit 608f1b0dbddec6b2fd766c10bcce2b651995e936 ] Each time we go through dsp_work() it does a devm_kasprintf() to allocate memory to hold the part name string. It's not strictly a memory leak because devm will free it all if the driver is removed. But we keep allocating more and more memory to hold the same string. Move the allocation so that it is performed after the version and secured state information is gathered and handle allocation errors. Signed-off-by: Simon Trimmer Signed-off-by: Richard Fitzgerald Link: https://lore.kernel.org/r/Message-Id: <20230518150250.1121006-2-rf@opensource.cirrus.com> Signed-off-by: Mark Brown Signed-off-by: Sasha Levin * ASoC: SOF: amd: Add pci revision id check [ Upstream commit 1d4a84632b90d88316986b05bcdfe715399a33db ] Add pci revision id check for renoir and rembrandt platforms. Signed-off-by: Venkata Prasad Potturu Link: https://lore.kernel.org/r/20230523072009.2379198-1-venkataprasad.potturu@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin * drm/stm: ltdc: fix late dereference check [ Upstream commit 898a9e3f56db9860ab091d4bf41b6caa99aafc3d ] In ltdc_crtc_set_crc_source(), struct drm_crtc was dereferenced in a container_of() before the pointer check. This could cause a kernel panic. Fix this smatch warning: drivers/gpu/drm/stm/ltdc.c:1124 ltdc_crtc_set_crc_source() warn: variable dereferenced before check 'crtc' (see line 1119) Reported-by: kernel test robot Closes: https://lore.kernel.org/lkml/202212241802.zeLFZCXB-lkp@intel.com/ Reported-by: Dan Carpenter Closes: https://lore.kernel.org/lkml/202212241802.zeLFZCXB-lkp@intel.com/ Signed-off-by: Raphael Gallais-Pou Acked-by: Philippe Cornu Signed-off-by: Philippe Cornu Link: https://patchwork.freedesktop.org/patch/msgid/20230515123818.93971-1-raphael.gallais-pou@foss.st.com Signed-off-by: Sasha Levin * arm64: dts: qcom: ipq5332: add QFPROM node [ Upstream commit 2f34a2aa4c88f4882e3c5df8c9b78f8bbd3f564f ] IPQ5332 has efuse region to determine the various HW quirks. Lets add the initial support and the individual fuses will be added as they are required. Reviewed-by: Konrad Dybcio Signed-off-by: Kathiravan T Signed-off-by: Bjorn Andersson Link: https://lore.kernel.org/r/20230526125305.19626-3-quic_kathirav@quicinc.com Signed-off-by: Sasha Levin * drm: rcar-du: remove R-Car H3 ES1.* workarounds [ Upstream commit 2da4b728f994a1f9189a8066b0be90b615768764 ] R-Car H3 ES1.* was only available to an internal development group and needed a lot of quirks and workarounds. These become a maintenance burden now, so our development group decided to remove upstream support for this SoC and prevent booting it. Public users only have ES2 onwards. Signed-off-by: Wolfram Sang Reviewed-by: Kieran Bingham Reviewed-by: Laurent Pinchart Signed-off-by: Laurent Pinchart Signed-off-by: Sasha Levin * ASoC: amd: vangogh: Add check for acp config flags in vangogh platform [ Upstream commit e89f45edb747ed88e97a5771dd6d3dd1eb517873 ] We have SOF and generic ACP support enabled for Vangogh platform on some machines. Since we have same PCI id used for probing, add check for machine configuration flag to avoid conflict with newer pci drivers. Such machine flag has been initialized via dmi match on few Vangogh based machines. If no flag is specified probe and register older platform device. Signed-off-by: Venkata Prasad Potturu Link: https://lore.kernel.org/r/20230530110802.674939-1-venkataprasad.potturu@amd.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin * RDMA/mana_ib: Use v2 version of cfg_rx_steer_req to enable RX coalescing [ Upstream commit 2145328515c8fa9b8a9f7889250bc6c032f2a0e6 ] With RX coalescing, one CQE entry can be used to indicate multiple packets on the receive queue. This saves processing time and PCI bandwidth over the CQ. The MANA Ethernet driver also uses the v2 version of the protocol. It doesn't use RX coalescing and its behavior is not changed. Link: https://lore.kernel.org/r/1684045095-31228-1-git-send-email-longli@linuxonhyperv.com Signed-off-by: Long Li Signed-off-by: Jason Gunthorpe Signed-off-by: Sasha Levin * ARM: dts: imx6dl: prtrvt, prtvt7, prti6q, prtwd2: fix USB related warnings [ Upstream commit 1d14bd943fa2bbdfda1efbcc080b298fed5f1803 ] Fix USB-related warnings in prtrvt, prtvt7, prti6q and prtwd2 device trees by disabling unused usbphynop1 and usbphynop2 USB PHYs and providing proper configuration for the over-current detection. This fixes the following warnings with the current kernel: usb_phy_generic usbphynop1: dummy supplies not allowed for exclusive requests usb_phy_generic usbphynop2: dummy supplies not allowed for exclusive requests imx_usb 2184200.usb: No over current polarity defined By the way, fix over-current detection on usbotg port for prtvt7, prti6q and prtwd2 boards. Only prtrvt do not have OC on USB OTG port. Signed-off-by: Oleksij Rempel Signed-off-by: Shawn Guo Signed-off-by: Sasha Levin * ASoC: Intel: sof_sdw_rt_sdca_jack_common: test SOF_JACK_JDSRC in _exit [ Upstream commit 526a1876fc48e2d0c0ea8ad63b58bdb2cc13047f ] if (!SOF_RT711_JDSRC(sof_sdw_quirk)) is tested in rt711_sdca_add_codec_ device_props(), and we don't add software node to the device if jack source is not set. We need to do the same test in sof_sdw_rt711_sdca_exit(), and avoid removing software node if jack source is not set. Signed-off-by: Bard Liao Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20230602202225.249209-8-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin * ASoC: Intel: sof_sdw: add quick for Dell SKU 0BDA [ Upstream commit 3daf02819ac3fd8d7605804a00213cf123ac880d ] The SKU numbering isn't quite consistent with the existing RaptorLake SKUs but the PCI ID is definitively RaptorLake. Closes: https://github.com/thesofproject/linux/issues/4380 Reviewed-by: Bard Liao Reviewed-by: Ranjani Sridharan Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20230602202225.249209-17-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin * ASoC: Intel: sof_sdw: Add support for Rex soundwire [ Upstream commit 164e5dc17525181c05563f0a06796f1a363801d5 ] Add rex entry in the soundwire quirk table Reviewed-by: Ranjani Sridharan Signed-off-by: Bard Liao Signed-off-by: Yong Zhi Signed-off-by: Uday M Bhat Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20230602202225.249209-28-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin * iopoll: Call cpu_relax() in busy loops [ Upstream commit b407460ee99033503993ac7437d593451fcdfe44 ] It is considered good practice to call cpu_relax() in busy loops, see Documentation/process/volatile-considered-harmful.rst. This can not only lower CPU power consumption or yield to a hyperthreaded twin processor, but also allows an architecture to mitigate hardware issues (e.g. ARM Erratum 754327 for Cortex-A9 prior to r2p0) in the architecture-specific cpu_relax() implementation. In addition, cpu_relax() is also a compiler barrier. It is not immediately obvious that the @op argument "function" will result in an actual function call (e.g. in case of inlining). Where a function call is a C sequence point, this is lost on inlining. Therefore, with agressive enough optimization it might be possible for the compiler to hoist the: (val) = op(args); "load" out of the loop because it doesn't see the value changing. The addition of cpu_relax() would inhibit this. As the iopoll helpers lack calls to cpu_relax(), people are sometimes reluctant to use them, and may fall back to open-coded polling loops (including cpu_relax() calls) instead. Fix this by adding calls to cpu_relax() to the iopoll helpers: - For the non-atomic case, it is sufficient to call cpu_relax() in case of a zero sleep-between-reads value, as a call to usleep_range() is a safe barrier otherwise. However, it doesn't hurt to add the call regardless, for simplicity, and for similarity with the atomic case below. - For the atomic case, cpu_relax() must be called regardless of the sleep-between-reads value, as there is no guarantee all architecture-specific implementations of udelay() handle this. Signed-off-by: Geert Uytterhoeven Acked-by: Peter Zijlstra (Intel) Acked-by: Arnd Bergmann Reviewed-by: Tony Lindgren Reviewed-by: Ulf Hansson Link: https://lore.kernel.org/r/45c87bec3397fdd704376807f0eec5cc71be440f.1685692810.git.geert+renesas@glider.be Signed-off-by: Sasha Levin * ASoC: SOF: Intel: fix SoundWire/HDaudio mutual exclusion [ Upstream commit f751b99255cacd9ffe8c4bbf99767ad670cee1f7 ] The functionality described in Commit 61bef9e68dca ("ASoC: SOF: Intel: hda: enforce exclusion between HDaudio and SoundWire") does not seem to be properly implemented with two issues that need to be corrected. a) The test used is incorrect when DisplayAudio codecs are not supported. b) Conversely when only Display Audio codecs can be found, we do want to start the SoundWire links, if any. That will help add the relevant topologies and machine descriptors, and identify cases where the SoundWire information in ACPI needs to be modified with a quirk. Signed-off-by: Pierre-Louis Bossart Reviewed-by: Bard Liao Reviewed-by: Ranjani Sridharan Link: https://lore.kernel.org/r/20230606222529.57156-2-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin * dma-remap: use kvmalloc_array/kvfree for larger dma memory remap [ Upstream commit 51ff97d54f02b4444dfc42e380ac4c058e12d5dd ] If dma_direct_alloc() alloc memory in size of 64MB, the inner function dma_common_contiguous_remap() will allocate 128KB memory by invoking the function kmalloc_array(). and the kmalloc_array seems to fail to try to allocate 128KB mem. Call trace: [14977.928623] qcrosvm: page allocation failure: order:5, mode:0x40cc0 [14977.928638] dump_backtrace.cfi_jt+0x0/0x8 [14977.928647] dump_stack_lvl+0x80/0xb8 [14977.928652] warn_alloc+0x164/0x200 [14977.928657] __alloc_pages_slowpath+0x9f0/0xb4c [14977.928660] __alloc_pages+0x21c/0x39c [14977.928662] kmalloc_order+0x48/0x108 [14977.928666] kmalloc_order_trace+0x34/0x154 [14977.928668] __kmalloc+0x548/0x7e4 [14977.928673] dma_direct_alloc+0x11c/0x4f8 [14977.928678] dma_alloc_attrs+0xf4/0x138 [14977.928680] gh_vm_ioctl_set_fw_name+0x3c4/0x610 [gunyah] [14977.928698] gh_vm_ioctl+0x90/0x14c [gunyah] [14977.928705] __arm64_sys_ioctl+0x184/0x210 work around by doing kvmalloc_array instead. Signed-off-by: Gao Xu Reviewed-by: Suren Baghdasaryan Signed-off-by: Christoph Hellwig Signed-off-by: Sasha Levin * accel/habanalabs: add pci health check during heartbeat [ Upstream commit d8b9cea584661b30305cf341bf9f675dc0a25471 ] Currently upon a heartbeat failure, we don't know if the failure is due to firmware hang or due to a bad PCI link. Hence, we are reading a PCI config space register with a known value (vendor ID) so we will know which of the two possibilities caused the heartbeat failure. Signed-off-by: Ofir Bitton Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin * accel/habanalabs: fix mem leak in capture user mappings [ Upstream commit 314a7ffd7c196b27eedd50cb7553029e17789b55 ] This commit fixes a memory leak caused when clearing the user_mappings info when a new context is opened immediately after user_mapping is captured and a hard reset is performed. Signed-off-by: Moti Haimovski Reviewed-by: Dani Liberman Reviewed-by: Oded Gabbay Signed-off-by: Oded Gabbay Signed-off-by: Sasha Levin * dt-bindings: input: goodix: Add "goodix,no-reset-during-suspend" property [ Upstream commit 359ed24a0dd3802e703ec8071dc3b6ed446de5f0 ] We observed that on Chromebook device Steelix, if Goodix GT7375P touchscreen is powered in suspend (because, for example, it connects to an always-on regulator) and with the reset GPIO asserted, it will introduce about 14mW power leakage. To address that, we add this property to skip reset during suspend. If it's set, the driver will stop asserting the reset GPIO during power-down. Refer to the comments in the driver for details. Signed-off-by: Fei Shao Suggested-by: Jeff LaBundy Reviewed-by: Douglas Anderson Reviewed-by: Matthias Brugger Reviewed-by: Jeff LaBundy Acked-by: Rob Herring Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin * HID: i2c-hid: goodix: Add support for "goodix,no-reset-during-suspend" property [ Upstream commit 7607f12ba735f04e0ef8718dabadf3a765c9a477 ] In the beginning, commit 18eeef46d359 ("HID: i2c-hid: goodix: Tie the reset line to true state of the regulator") introduced a change to tie the reset line of the Goodix touchscreen to the state of the regulator to fix a power leakage issue in suspend. After some time, the change was deemed unnecessary and was reverted in commit 557e05fa9fdd ("HID: i2c-hid: goodix: Stop tying the reset line to the regulator") due to difficulties in managing regulator notifiers for designs like Evoker, which provides a second power rail to touchscreen. However, the revert caused a power regression on another Chromebook device Steelix in the field, which has a dedicated always-on regulator for touchscreen and was covered by the workaround in the first commit. To address both cases, this patch adds the support for the new "goodix,no-reset-during-suspend" property in the driver: - When set to true, the driver does not assert the reset GPIO during power-down. Instead, the GPIO will be asserted during power-up to ensure the touchscreen always has a clean start and consistent behavior after resuming. This is for designs with a dedicated always-on regulator. - When set to false or unset, the driver uses the original control flow and asserts GPIO and disables regulators normally. This is for the two-regulator and shared-regulator designs. Signed-off-by: Fei Shao Suggested-by: Douglas Anderson Reviewed-by: Douglas Anderson Reviewed-by: Jeff LaBundy Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin * HID: logitech-hidpp: Add USB and Bluetooth IDs for the Logitech G915 TKL Keyboard [ Upstream commit 48aea8b445c422a372cf15915101035a47105421 ] Adds the USB and Bluetooth IDs for the Logitech G915 TKL keyboard, for device detection For this device, this provides battery reporting on top of hid-generic Reviewed-by: Bastien Nocera Signed-off-by: Stuart Hayhurst Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin * iommu/amd: Introduce Disable IRTE Caching Support [ Upstream commit 66419036f68a838c00cbccacd6cb2e99da6e5710 ] An Interrupt Remapping Table (IRT) stores interrupt remapping configuration for each device. In a normal operation, the AMD IOMMU caches the table to optimize subsequent data accesses. This requires the IOMMU driver to invalidate IRT whenever it updates the table. The invalidation process includes issuing an INVALIDATE_INTERRUPT_TABLE command following by a COMPLETION_WAIT command. However, there are cases in which the IRT is updated at a high rate. For example, for IOMMU AVIC, the IRTE[IsRun] bit is updated on every vcpu scheduling (i.e. amd_iommu_update_ga()). On system with large amount of vcpus and VFIO PCI pass-through devices, the invalidation process could potentially become a performance bottleneck. Introducing a new kernel boot option: amd_iommu=irtcachedis which disables IRTE caching by setting the IRTCachedis bit in each IOMMU Control register, and bypass the IRT invalidation process. Reviewed-by: Jerry Snitselaar Co-developed-by: Alejandro Jimenez Signed-off-by: Alejandro Jimenez Signed-off-by: Suravee Suthikulpanit Link: https://lore.kernel.org/r/20230530141137.14376-4-suravee.suthikulpanit@amd.com Signed-off-by: Joerg Roedel Signed-off-by: Sasha Levin * drm/amdgpu: install stub fence into potential unused fence pointers [ Upstream commit 187916e6ed9d0c3b3abc27429f7a5f8c936bd1f0 ] When using cpu to update page tables, vm update fences are unused. Install stub fence into these fence pointers instead of NULL to avoid NULL dereference when calling dma_fence_wait() on them. Suggested-by: Christian König Signed-off-by: Lang Yu Reviewed-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin * drm/amd/display: Remove v_startup workaround for dcn3+ [ Upstream commit 3a31e8b89b7240d9a17ace8a1ed050bdcb560f9e ] [Why] Calls to dcn20_adjust_freesync_v_startup are no longer needed as of dcn3+ and can cause underflow in some cases [How] Move calls to dcn20_adjust_freesync_v_startup up into validate_bandwidth for dcn2.x Reviewed-by: Jun Lei Acked-by: Aurabindo Pillai Signed-off-by: Daniel Miess Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin * drm/amd/display: Apply 60us prefetch for DCFCLK <= 300Mhz [ Upstream commit 7e60ab4eb3e4ba2adac46d737fdbbc5732bebd58 ] [Description] - Previously we wanted to apply extra 60us of prefetch for min DCFCLK (200Mhz), but DCFCLK can be calculated to be 201Mhz which underflows also without the extra prefetch - Instead, apply the the extra 60us prefetch for any DCFCLK freq <= 300Mhz Reviewed-by: Nevenko Stupar Reviewed-by: Jun Lei Acked-by: Tom Chung Signed-off-by: Alvin Lee Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin * drm/amdgpu: unmap and remove csa_va properly [ Upstream commit 5daff15cd013422bc6d1efcfe82b586800025384 ] Root PD BO should be reserved before unmap and remove a bo_va from VM otherwise lockdep will complain. v2: check fpriv->csa_va is not NULL instead of amdgpu_mcbp (christian) [14616.936827] WARNING: CPU: 6 PID: 1711 at drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c:1762 amdgpu_vm_bo_del+0x399/0x3f0 [amdgpu] [14616.937096] Call Trace: [14616.937097] [14616.937102] amdgpu_driver_postclose_kms+0x249/0x2f0 [amdgpu] [14616.937187] drm_file_free+0x1d6/0x300 [drm] [14616.937207] drm_close_helper.isra.0+0x62/0x70 [drm] [14616.937220] drm_release+0x5e/0x100 [drm] [14616.937234] __fput+0x9f/0x280 [14616.937239] ____fput+0xe/0x20 [14616.937241] task_work_run+0x61/0x90 [14616.937246] exit_to_user_mode_prepare+0x215/0x220 [14616.937251] syscall_exit_to_user_mode+0x2a/0x60 [14616.937254] do_syscall_64+0x48/0x90 [14616.937257] entry_SYSCALL_64_after_hwframe+0x63/0xcd Signed-off-by: Lang Yu Acked-by: Christian König Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin * RDMA/mlx5: Return the firmware result upon destroying QP/RQ [ Upstream commit 22664c06e997087fe37f9ba208008c948571214a ] Previously when destroying a QP/RQ, the result of the firmware destruction function was ignored and upper layers weren't informed about the failure. Which in turn could lead to various problems since when upper layer isn't aware of the failure it continues its operation thinking that the related QP/RQ was successfully destroyed while it actually wasn't, which could lead to the below kernel WARN. Currently, we return the correct firmware destruction status to upper layers which in case of the RQ would be mlx5_ib_destroy_wq() which was already capable of handling RQ destruction failure or in case of a QP to destroy_qp_common(), which now would actually warn upon qp destruction failure. WARNING: CPU: 3 PID: 995 at drivers/infiniband/core/rdma_core.c:940 uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs] Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xt_addrtype iptable_nat nf_nat br_netfilter rpcrdma rdma_ucm ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_umad ib_ipoib iw_cm ib_cm mlx5_ib ib_uverbs ib_core overlay mlx5_core fuse CPU: 3 PID: 995 Comm: python3 Not tainted 5.16.0-rc5+ #1 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014 RIP: 0010:uverbs_destroy_ufile_hw+0xcb/0xe0 [ib_uverbs] Code: 41 5c 41 5d 41 5e e9 44 34 f0 e0 48 89 df e8 4c 77 ff ff 49 8b 86 10 01 00 00 48 85 c0 74 a1 4c 89 e7 ff d0 eb 9a 0f 0b eb c1 <0f> 0b be 04 00 00 00 48 89 df e8 b6 f6 ff ff e9 75 ff ff ff 90 0f RSP: 0018:ffff8881533e3e78 EFLAGS: 00010287 RAX: ffff88811b2cf3e0 RBX: ffff888106209700 RCX: 0000000000000000 RDX: ffff888106209780 RSI: ffff8881533e3d30 RDI: ffff888109b101a0 RBP: 0000000000000001 R08: ffff888127cb381c R09: 0de9890000000009 R10: ffff888127cb3800 R11: 0000000000000000 R12: ffff888106209780 R13: ffff888106209750 R14: ffff888100f20660 R15: 0000000000000000 FS: 00007f8be353b740(0000) GS:ffff88852c980000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00007f8bd5b117c0 CR3: 000000012cd8a004 CR4: 0000000000370ea0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: ib_uverbs_close+0x1a/0x90 [ib_uverbs] __fput+0x82/0x230 task_work_run+0x59/0x90 exit_to_user_mode_prepare+0x138/0x140 syscall_exit_to_user_mode+0x1d/0x50 ? __x64_sys_close+0xe/0x40 do_syscall_64+0x4a/0x90 entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7f8be3ae0abb Code: 03 00 00 00 0f 05 48 3d 00 f0 ff ff 77 41 c3 48 83 ec 18 89 7c 24 0c e8 83 43 f9 ff 8b 7c 24 0c 41 89 c0 b8 03 00 00 00 0f 05 <48> 3d 00 f0 ff ff 77 35 44 89 c7 89 44 24 0c e8 c1 43 f9 ff 8b 44 RSP: 002b:00007ffdb51909c0 EFLAGS: 00000293 ORIG_RAX: 0000000000000003 RAX: 0000000000000000 RBX: 0000557bb7f7c020 RCX: 00007f8be3ae0abb RDX: 0000557bb7c74010 RSI: 0000557bb7f14ca0 RDI: 0000000000000005 RBP: 0000557bb7fbd598 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000293 R12: 0000557bb7fbd5b8 R13: 0000557bb7fbd5a8 R14: 0000000000001000 R15: 0000557bb7f7c020 Signed-off-by: Patrisious Haddad Link: https://lore.kernel.org/r/c6df677f931d18090bafbe7f7dbb9524047b7d9b.1685953497.git.leon@kernel.org Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin * RDMA/bnxt_re: consider timeout of destroy ah as success. [ Upstream commit bb8c93618fb0b8567d309f1aebc6df0cd31da1a2 ] If destroy_ah is timed out, it is likely to be destroyed by firmware but it is taking longer time due to temporary slowness in processing the rcfw command. In worst case, there might be AH resource leak in firmware. Sending timeout return value can dump warning message from ib_core which can be avoided if we map timeout of destroy_ah as success. Signed-off-by: Kashyap Desai Signed-off-by: Selvin Xavier Link: https://lore.kernel.org/r/1686308514-11996-14-git-send-email-selvin.xavier@broadcom.com Signed-off-by: Leon Romanovsky Signed-off-by: Sasha Levin * drm/amd/display: Skip DPP DTO update if root clock is gated [ Upstream commit 30f90f3c1c2c63c2fa44f61233737d27b72637c2 ] [Why] Hardware implements root clock gating by utilizing the DPP DTO registers with a special case of DTO enabled, phase = 0, modulo = 1. This conflicts with our policy to always update the DPPDTO for cases where it's expected to be disabled. The pipes unexpectedly enter a higher power state than expected because of this programming flow. [How] Guard the upper layers of HWSS against this hardware quirk with programming the register with an internal state flag in DCCG. While technically acting as global state for the DCCG, HWSS shouldn't be expected to understand the hardware quirk for having DTO disabled causing more power than DTO enabled with this specific setting. This also prevents sequencing errors from occuring in the future if we have to program DPP DTO in multiple locations. Acked-by: Stylon Wang Signed-off-by: Nicholas Kazlauskas Reviewed-by: Jun Lei Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin * drm/amd/display: Enable dcn314 DPP RCO [ Upstream commit 17fbdbda9cc87ff5a013898de506212d25323ed7 ] [Why and How] Add back debug bits enabling RCO for dcn314 as underflow associated with this change has been resolved Acked-by: Stylon Wang Signed-off-by: Daniel Miess Reviewed-by: Jun Lei Tested-by: Daniel Wheeler Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin * ASoC: SOF: core: Free the firmware trace before calling snd_sof_shutdown() [ Upstream commit d389dcb3a48cec4f03c16434c0bf98a4c635372a ] The shutdown is called on reboot/shutdown of the machine. At this point the firmware tracing cannot be used anymore but in case of IPC3 it is using and keeping a DMA channel active (dtrace). For Tiger Lake platforms we have a quirk in place to fix rare reboot issues when a DMA was active before rebooting the system. If the tracing is enabled this quirk will be always used and a print appears on the kernel log which might be misleading or not even correct. Release the fw tracing before executing the shutdown to make sure that this known DMA user is cleared away. Reviewed-by: Kai Vehmanen Reviewed-by: Daniel Baluta Reviewed-by: Ranjani Sridharan Reviewed-by: Rander Wang Reviewed-by: Bard Liao Signed-off-by: Peter Ujfalusi Signed-off-by: Pierre-Louis Bossart Link: https://lore.kernel.org/r/20230616100039.378150-4-pierre-louis.bossart@linux.intel.com Signed-off-by: Mark Brown Signed-off-by: Sasha Levin * HID: intel-ish-hid: ipc: Add Arrow Lake PCI device ID [ Upstream commit 4982126e3029cd59fbd1da0d9cc0365a0585fe64 ] Add device ID of Arrow Lake-H into ishtp support list. Signed-off-by: Even Xu Acked-by: Srinivas Pandruvada Signed-off-by: Jiri Kosina Signed-off-by: Sasha Levin * Revert "[PATCH] uml: export symbols added by GCC hardened" [ Upstream commit 8635e8df477bc77837886da206f4915576f88fec ] This reverts commit cead61a6717a9873426b08d73a34a325e3546f5d. It exported __stack_smash_handler and __guard, while they may not be defined by anyone. The code *declares* __stack_smash_handler and __guard. It does not create weak symbols. If no external library is linked, they are left undefined, but yet exported. If a loadable module tries to access non-existing symbols, bad things (a page fault, NULL pointer dereference, etc.) will happen. So, the current code is wrong and dangerous. If the code were written as follows, it would *define* them as weak symbols so modules would be able to get access to them. void (*__stack_smash_handler)(void *) __attribute__((weak)); EXPORT_SYMBOL(__stack_smash_handler); long __guard __attribute__((weak)); EXPORT_SYMBOL(__guard); In fact, modpost forbids exporting undefined symbols. It shows an error message if it detects such a mistake. ERROR: modpost: "..." [...] was exported without definition Unfortunately, it is checked only when the code is built as modular. The problem described above has been unnoticed for a long time because arch/um/os-Linux/user_syms.c is always built-in. With a planned change in Kbuild, exporting undefined symbols will always result in a build error instead of a run-time error. It is a good thing, but we need to fix the breakage in advance. One fix is to define weak symbols as shown above. An alternative is to export them conditionally as follows: #ifdef CONFIG_STACKPROTECTOR extern void __stack_smash_handler(void *); EXPORT_SYMBOL(__stack_smash_handler); external long __guard; EXPORT_SYMBOL(__guard); #endif This is what other architectures do; EXPORT_SYMBOL(__stack_chk_guard) is guarded by #ifdef CONFIG_STACKPROTECTOR. However, adding the #ifdef guard is not sensible because UML cannot enable the stack-protector in the first place! (Please note UML does not select HAVE_STACKPROTECTOR in Kconfig.) So, the code is already broken (and unused) in multiple ways. Just remove. Signed-off-by: Masahiro Yamada Reviewed-by: Nick Desaulniers Signed-off-by: Sasha Levin * smb: client: fix warning in cifs_smb3_do_mount() [ Upstream commit 12c30f33cc6769bf411088a2872843c4f9ea32f9 ] This fixes the following warning reported by kernel test robot fs/smb/client/cifsfs.c:982 cifs_smb3_do_mount() warn: possible memory leak of 'cifs_sb' Link: https://lore.kernel.org/all/202306170124.CtQqzf0I-lkp@intel.com/ Signed-off-by: Paulo Alcantara (SUSE) Signed-off-by: Steve French Signed-off-by: Sasha Levin * cifs: fix session state check in reconnect to avoid use-after-free issue [ Upstream commit 99f280700b4cc02d5f141b8d15f8e9fad0418f65 ] Don't collect exiting session in smb2_reconnect_server(), because it will be released soon. Note that the exiting session will stay in server->smb_ses_list until it complete the cifs_free_ipc() and logoff() and then delete itself from the list. Signed-off-by: Winston Wen Reviewed-by: Shyam Prasad N Signed-off-by: Steve French Signed-off-by: Sasha Levin * serial: stm32: Ignore return value of uart_remove_one_port() in .remove() [ Upstream commit 6bd6cd29c92401a101993290051fa55078238a52 ] Returning early from stm32_usart_serial_remove() results in a resource leak as several cleanup functions are not called. The driver core ignores the return value and there is no possibility to clean up later. uart_remove_one_port() only returns non-zero if there is some inconsistency (i.e. stm32_usart_driver.state[port->line].uart_port == NULL). This should never happen, and even if it does it's a bad idea to exit early in the remove callback without cleaning up. This prepares changing the prototype of struct platform_driver::remove to return void. See commit 5c5a7680e67b ("platform: Provide a remove callback that returns no value") for further details about this quest. Signed-off-by: Uwe Kleine-König Link: https://lore.kernel.org/r/20230512173810.131447-2-u.kleine-koenig@pengutronix.de Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin * led: qcom-lpg: Fix resource leaks in for_each_available_child_of_node() loops [ Upstream commit 8f38f8fa7261819eb7d4fb369dc3bfab72259033 ] Ensure child node references are decremented properly in the error path. Signed-off-by: Lu Hongfei Link: https://lore.kernel.org/r/20230525111705.3055-1-luhongfei@vivo.com Signed-off-by: Lee Jones Signed-off-by: Sasha Levin * media: v4l2-mem2mem: add lock to protect parameter num_rdy [ Upstream commit 56b5c3e67b0f9af3f45cf393be048ee8d8a92694 ] Getting below error when using KCSAN to check the driver. Adding lock to protect parameter num_rdy when getting the value with function: v4l2_m2m_num_src_bufs_ready/v4l2_m2m_num_dst_bufs_ready. kworker/u16:3: [name:report&]BUG: KCSAN: data-race in v4l2_m2m_buf_queue kworker/u16:3: [name:report&] kworker/u16:3: [name:report&]read-write to 0xffffff8105f35b94 of 1 bytes by task 20865 on cpu 7: kworker/u16:3: v4l2_m2m_buf_queue+0xd8/0x10c Signed-off-by: Pina Chen Signed-off-by: Yunfei Dong Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin * media: camss: set VFE bpl_alignment to 16 for sdm845 and sm8250 [ Upstream commit d5b7eb477c286f6ceccbb38704136eea0e6b09ca ] From the experiments with camera sensors using SGRBG10_1X10/3280x2464 and SRGGB10_1X10/3280x2464 formats, it becomes clear that on sdm845 and sm8250 VFE outputs the lines padded to a length multiple of 16 bytes. As in the current driver the value of the bpl_alignment is set to 8 bytes, the frames captured in formats with the bytes-per-line value being not a multiple of 16 get corrupted. Set the bpl_alignment of the camss video output device to 16 for sdm845 and sm8250 to fix that. Signed-off-by: Andrey Konovalov Tested-by: Bryan O'Donoghue Acked-by: Bryan O'Donoghue Signed-off-by: Hans Verkuil Signed-off-by: Sasha Levin * usb: gadget: u_serial: Avoid spinlock recursion in __gs_console_push [ Upstream commit e5990469943c711cb00bfde6338d2add6c6d0bfe ] When serial console over USB is enabled, gs_console_connect queues gs_console_work, where it acquires the spinlock and queues the usb request, and this request goes to gadget layer. Now consider a situation where gadget layer prints something to dmesg, this will eventually call gs_console_write() which requires cons->lock. And this causes spinlock recursion. Avoid this by excluding usb_ep_queue from the spinlock. spin_lock_irqsave //needs cons->lock gs_console_write . . _printk __warn_printk dev_warn/pr_err . . [USB Gadget Layer] . . usb_ep_queue gs_console_work __gs_console_push // acquires cons->lock process_one_work Signed-off-by: Prashanth K Link: https://lore.kernel.org/r/1683638872-6885-1-git-send-email-quic_prashk@quicinc.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin * usb: gadget: uvc: queue empty isoc requests if no video buffer is available [ Upstream commit c3ff12a92bd7072170978b8b41c2fa41b038139a ] ISOC transfers expect a certain cadence of requests being queued. Not keeping up with the expected rate of requests results in missed ISOC transfers (EXDEV). The application layer may or may not produce video frames to match this expectation, so uvc gadget driver must handle cases where the application is not queuing up buffers fast enough to fulfill ISOC requirements. Currently, uvc gadget driver waits for new video buffer to become available before queuing up usb requests. With this patch the gadget driver queues up 0 length usb requests whenever there are no video buffers available. The USB controller's complete callback is used as the limiter for how quickly the 0 length packets will be queued. Video buffers are still queued as soon as they become available. Link: https://lore.kernel.org/CAMHf4WKbi6KBPQztj9FA4kPvESc1fVKrC8G73-cs6tTeQby9=w@mail.gmail.com/ Signed-off-by: Avichal Rakesh Link: https://lore.kernel.org/r/20230508231103.1621375-1-arakesh@google.com Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin * media: platform: mediatek: vpu: fix NULL ptr dereference [ Upstream commit 3df55cd773e8603b623425cc97b05e542854ad27 ] If pdev is NULL, then it is still dereferenced. This fixes this smatch warning: drivers/media/platform/mediatek/vpu/mtk_vpu.c:570 vpu_load_firmware() warn: address of NULL pointer 'pdev' Signed-off-by: Hans Verkuil Cc: Yunfei Dong Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Sasha Levin * thunderbolt: Read retimer NVM authentication status prior tb_retimer_set_inbound_sbtx() [ Upstream commit 1402ba08abae5cfa583ff1a40b99c098a0532d41 ] According to the USB4 retimer guide the correct order is immediately after sending ENUMERATE_RETIMERS so update the code to follow this. Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin * xhci: get rid of XHCI_PLAT quirk that used to prevent MSI setup [ Upstream commit 0a4776205b16d038ec6fedef2094951fcb6f441b ] The XHCI_PLAT quirk was only needed to ensure non-PCI xHC host avoided setting up MSI interrupts in generic xhci codepaths. The MSI setup code is now moved to PCI specific xhci-pci.c file so the quirk is no longer needed. Remove setting the XHCI_PLAT quirk for HiSilocon SoC xHC, NVIDIA Tegra xHC, MediaTek xHC, the generic xhci-plat driver, and the checks for XHCI_PLAT in xhci-pci.c MSI setup code. Signed-off-by: Mathias Nyman Message-ID: <20230602144009.1225632-5-mathias.nyman@linux.intel.com> Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin * usb: chipidea: imx: don't request QoS for imx8ulp [ Upstream commit 9a070e8e208995a9d638b538ed7abf28bd6ea6f0 ] Use dedicated imx8ulp usb compatible to remove QoS request since imx8ulp has no such limitation of imx7ulp: DMA will not work if system enters idle. Signed-off-by: Xu Yang Signed-off-by: Li Jun Acked-by: Peter Chen Message-ID: <20230530104007.1294702-2-xu.yang_2@nxp.com> Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin * usb: chipidea: imx: turn off vbus comparator when suspend [ Upstream commit 0ac37fbdad7087bbcbbe246a602c248ccfd954ea ] As we use bvalid for vbus wakeup source, to save power when suspend, turn off the vbus comparator for imx7d and imx8mm. Below is this bit description from RM of iMX8MM "VBUS Valid Comparator Enable: This signal controls the USB OTG PHY VBUS Valid comparator which indicates whether the voltage on the USB_OTG*_VBUS pin is below the VBUS Valid threshold. The VBUS Valid threshold is nominally 4.75V on this USB PHY. The VBUS Valid threshold can be adjusted using the USBNC_OTGn_PHY_CFG1[OTGTUNE0] bit field. Status of the VBUS Valid comparator, when it is enabled, is reported on the USBNC_OTGn_PHY_STATUS[VBUS_VLD] bit. When OTGDISABLE0 (USBNC_USB_OTGx_PHY_CFG2[10])is set to 1'b0 and DRVVBUS0 is set to 1'b1, the Bandgap circuitry and VBUS Valid comparator are powered, even in Suspend or Sleep mode. DRVVBUS0 should be reset to 1'b0 when the internal VBUS Valid comparator is not required, to reduce quiescent current in Suspend or Sleep mode. - 0 The VBUS Valid comparator is disabled - 1 The VBUS Valid comparator is enabled" Signed-off-by: Li Jun Signed-off-by: Xu Yang Acked-by: Peter Chen Message-ID: <20230517081907.3410465-2-xu.yang_2@nxp.com> Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin * usb: chipidea: imx: add missing USB PHY DPDM wakeup setting [ Upstream commit 53d061c19dc4cb68409df6dc11c40389c8c42a75 ] USB PHY DPDM wakeup bit is enabled by default, when USB wakeup is not required(/sys/.../wakeup is disabled), this bit should be disabled, otherwise we will have unexpected wakeup if do USB device connect/disconnect while system sleep. This bit can be enabled for both host and device mode. Signed-off-by: Li Jun Signed-off-by: Xu Yang Acked-by: Peter Chen Message-ID: <20230517081907.3410465-3-xu.yang_2@nxp.com> Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin * gfs2: Fix possible data races in gfs2_show_options() [ Upstream commit 6fa0a72cbbe45db4ed967a51f9e6f4e3afe61d20 ] Some fields such as gt_logd_secs of the struct gfs2_tune are accessed without holding the lock gt_spin in gfs2_show_options(): val = sdp->sd_tune.gt_logd_secs; if (val != 30) seq_printf(s, ",commit=%d", val); And thus can cause data races when gfs2_show_options() and other functions such as gfs2_reconfigure() are concurrently executed: spin_lock(>->gt_spin); gt->gt_logd_secs = newargs->ar_commit; To fix these possible data races, the lock sdp->sd_tune.gt_spin is acquired before accessing the fields of gfs2_tune and released after these accesses. Further changes by Andreas: - Don't hold the spin lock over the seq_printf operations. Reported-by: BassCheck Signed-off-by: Tuo Li Signed-off-by: Andreas Gruenbacher Signed-off-by: Sasha Levin * pcmcia: rsrc_nonstatic: Fix memory leak in nonstatic_release_resource_db() [ Upstream commit c85fd9422fe0f5d667305efb27f56d09eab120b0 ] When nonstatic_release_resource_db() frees all resources associated with an PCMCIA socket, it forgets to free socket_data too, causing a memory leak observable with kmemleak: unreferenced object 0xc28d1000 (size 64): comm "systemd-udevd", pid 297, jiffies 4294898478 (age 194.484s) hex dump (first 32 bytes): 00 00 00 00 00 00 00 00 f0 85 0e c3 00 00 00 00 ................ 00 00 00 00 0c 10 8d c2 00 00 00 00 00 00 00 00 ................ backtrace: [] __kmem_cache_alloc_node+0x2d7/0x4a0 [<7e51f0c8>] kmalloc_trace+0x31/0xa4 [] nonstatic_init+0x24/0x1a4 [pcmcia_rsrc] [] pcmcia_register_socket+0x200/0x35c [pcmcia_core] [] yenta_probe+0x4d8/0xa70 [yenta_socket] [] pci_device_probe+0x99/0x194 [<84b7c690>] really_probe+0x181/0x45c [<8060fe6e>] __driver_probe_device+0x75/0x1f4 [] driver_probe_device+0x28/0xac [<648b766f>] __driver_attach+0xeb/0x1e4 [<6e9659eb>] bus_for_each_dev+0x61/0xb4 [<25a669f3>] driver_attach+0x1e/0x28 [] bus_add_driver+0x102/0x20c [] driver_register+0x5b/0x120 [<942cd8a4>] __pci_register_driver+0x44/0x4c [] __UNIQUE_ID___addressable_cleanup_module188+0x1c/0xfffff000 [iTCO_vendor_support] Fix this by freeing socket_data too. Tested on a Acer Travelmate 4002WLMi by manually binding/unbinding the yenta_cardbus driver (yenta_socket). Signed-off-by: Armin Wolf Message-ID: <20230512184529.5094-1-W_Armin@gmx.de> Signed-off-by: Greg Kroah-Hartman Signed-off-by: Sasha Levin * thunderbolt: Add Intel Barlow Ridge PCI ID [ Upstream commit 6f14a210661ce03988ef4ed3c8402037c8e06539 ] Intel Barlow Ridge is the first USB4 v2 controller from Intel. The controller exposes standard USB4 PCI class ID in typical configurations, however there is a way to configure it so that it uses a special class ID to allow using s different driver than the Windows inbox one. For this reason add the Barlow Ridge PCI ID to the Linux driver too so that the driver can attach regardless of the class ID. Tested-by: Pengfei Xu Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin * thunderbolt: Limit Intel Barlow Ridge USB3 bandwidth [ Upstream commit f2bfa944080dcbb8eb56259dfd2c07204cbee17e ] Intel Barlow Ridge discrete USB4 host router has the same limitation as the previous generations so make sure the USB3 bandwidth limitation quirk is applied to Barlow Ridge too. Signed-off-by: Gil Fine Signed-off-by: Mika Westerberg Signed-off-by: Sasha Levin * firewire: net: fix use after free in fwnet_finish_incoming_packet() [ Upstream commit 3ff256751a2853e1ffaa36958ff933ccc98c6cb5 ] The netif_rx() function frees the skb so we can't dereference it to save the skb->len. Signed-off-by: Zhang Shurong Link: https://lore.kernel.org/r/tencent_3B3D24B66ED66A6BB73CC0E63C6A14E45109@qq.com Signed-off-by: Takashi Sakamoto Signed-off-by: Sasha Levin * watchdog: sp5100_tco: support Hygon FCH/SCH (Server Controller Hub) [ Upstream commit 009637de1f65cff452ad49554d1e8ef9fda99e43 ] Add PCI_VENDOR_ID_HYGON(Hygon vendor id [0x1d94]) in this driver Signed-off-by: Yuechao Zhao Reviewed-by: Guenter Roeck Link: https://lkml.kernel.org/r/20230612031907.796461-1-a345351830@gmail.com Signed-off-by: Guenter Roeck Signed-off-by: Wim Van Sebroeck Signed-off-by: Sasha Levin * Bluetooth: L2CAP: Fix use-after-free [ Upstream commit f752a0b334bb95fe9b42ecb511e0864e2768046f ] Fix potential use-after-free in l2cap_le_command_rej. Signed-off-by: Zhengping Jiang Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin * Bluetooth: btusb: Add MT7922 bluetooth ID for the Asus Ally [ Upstream commit fa01eba11f0e57c767a5eab5291c7a01407a00be ] Adding the device ID from the Asus Ally gets the bluetooth working on the device. Signed-off-by: Matthew Anderson Signed-off-by: Luiz Augusto von Dentz Signed-off-by: Jakub Kicinski Signed-off-by: Sasha Levin * ceph: try to dump the msgs when decoding fails [ Upstream commit 8b0da5c549ae63ba1debd92a350f90773cb4bfe7 ] When the msgs are corrupted we need to dump them and then it will be easier to dig what has happened and where the issue is. Signed-off-by: Xiubo Li Reviewed-by: Milind Changire Signed-off-by: Ilya Dryomov Signed-off-by: Sasha Levin * drm/amdgpu: Fix potential fence use-after-free v2 [ Upstream commit 2e54154b9f27262efd0cb4f903cc7d5ad1fe9628 ] fence Decrements the reference count before exiting. Avoid Race Vulnerabilities for fence use-after-free. v2 (chk): actually fix the use after free and not just move it. Signed-off-by: shanzhulig Signed-off-by: Christian König Reviewed-by: Alex Deucher Signed-off-by: Alex Deucher Signed-off-by: Sasha Levin * fs/ntfs3: Enhance sanity check while generating attr_list [ Upstream commit fdec309c7672cbee4dc0229ee4cbb33c948a1bdd ] ni_create_attr_list uses WARN_ON to catch error cases while generating attribute list, which only prints out stack trace and may not be enough. This repalces them with more proper error handling flow. [ 59.666332] BUG: kernel NULL pointer dereference, address: 000000000000000e [ 59.673268] #PF: supervisor read access in kernel mode [ 59.678354] #PF: error_code(0x0000) - not-present page [ 59.682831] PGD 8000000005ff1067 P4D 8000000005ff1067 PUD 7dee067 PMD 0 [ 59.688556] Oops: 0000 [#1] PREEMPT SMP KASAN PTI [ 59.692642] CPU: 0 PID: 198 Comm: poc Tainted: G B W 6.2.0-rc1+ #4 [ 59.698868] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014 [ 59.708795] RIP: 0010:ni_create_attr_list+0x505/0x860 [ 59.713657] Code: 7e 10 e8 5e d0 d0 ff 45 0f b7 76 10 48 8d 7b 16 e8 00 d1 d0 ff 66 44 89 73 16 4d 8d 75 0e 4c 89 f7 e8 3f d0 d0 ff 4c 8d8 [ 59.731559] RSP: 0018:ffff88800a56f1e0 EFLAGS: 00010282 [ 59.735691] RAX: 0000000000000001 RBX: ffff88800b7b5088 RCX: ffffffffb83079fe [ 59.741792] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffffffffbb7f9fc0 [ 59.748423] RBP: ffff88800a56f3a8 R08: ffff88800b7b50a0 R09: fffffbfff76ff3f9 [ 59.754654] R10: ffffffffbb7f9fc7 R11: fffffbfff76ff3f8 R12: ffff88800b756180 [ 59.761552] R13: 0000000000000000 R14: 000000000000000e R15: 0000000000000050 [ 59.768323] FS: 00007feaa8c96440(0000) GS:ffff88806d400000(0000) knlGS:0000000000000000 [ 59.776027] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 59.781395] CR2: 00007f3a2e0b1000 CR3: 000000000a5bc000 CR4: 00000000000006f0 [ 59.787607] Call Trace: [ 59.790271] [ 59.792488] ? __pfx_ni_create_attr_list+0x10/0x10 [ 59.797235] ? kernel_text_address+0xd3/0xe0 [ 59.800856] ? unwind_get_return_address+0x3e/0x60 [ 59.805101] ? __kasan_check_write+0x18/0x20 [ 59.809296] ? preempt_count_sub+0x1c/0xd0 [ 59.813421] ni_ins_attr_ext+0x52c/0x5c0 [ 59.817034] ? __pfx_ni_ins_attr_ext+0x10/0x10 [ 59.821926] ? __vfs_setxattr+0x121/0x170 [ 59.825718] ? __vfs_setxattr_noperm+0x97/0x300 [ 59.829562] ? __vfs_setxattr_locked+0x145/0x170 [ 59.833987] ? vfs_setxattr+0x137/0x2a0 [ 59.836732] ? do_setxattr+0xce/0x150 [ 59.839807] ? setxattr+0x126/0x140 [ 59.842353] ? path_setxattr+0x164/0x180 [ 59.845275] ? __x64_sys_setx…

UOS-K5.10-LTS branch 在 arm64 CPU 下，无法编译成功 #4

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions