[Deepin-Kernel-SIG] [Upstream] Update kernel base to 6.6.57 #442

opsiff · 2024-10-17T14:49:37Z

Update kernel base to 6.6.57

Revert Patch for audio function of glenfly arise chip
b526d0e
24a3ef0
Included in https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.6.57&id=bd9a77a93049

This reverts commit b526d0e. Included in the v6.6.57 upstream commit. Link: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.6.57&id=bd9a77a93049

This reverts commit 24a3ef0. Included in the upstream v6.6.57 commit Link:https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=v6.6.57&id=bd9a77a93049

commit 5c26d2f1d3f5e4be3e196526bead29ecb139cf91 upstream. We don't need to handle them separately. Instead, just let them decompose/casefold to themselves. Signed-off-by: Gabriel Krisman Bertazi <krisman@suse.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit ac20736861f3c9c8e0a78273a4c57e9bcb0d8cc6)

commit 6be063071a457767ee229db13f019c2ec03bfe44 upstream. Some platforms (such as i.MX25 and i.MX27) do not support PTP, so on these platforms fec_ptp_init() is not called and the related members in fep are not initialized. However, fec_ptp_save_state() is called unconditionally, which causes the kernel to panic. Therefore, add a condition so that fec_ptp_save_state() is not called if PTP is not supported. Fixes: a1477dc87dc4 ("net: fec: Restart PPS after link state change") Reported-by: Guenter Roeck <linux@roeck-us.net> Closes: https://lore.kernel.org/lkml/353e41fe-6bb4-4ee9-9980-2da2a9c1c508@roeck-us.net/ Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Csókás, Bence <csokas.bence@prolan.hu> Reviewed-by: Simon Horman <horms@kernel.org> Tested-by: Guenter Roeck <linux@roeck-us.net> Link: https://patch.msgid.link/20241008061153.1977930-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 7745e14f4c036ce94a5eb05d06e49b0d84b306f9)

[ Upstream commit 372c669 ] This reverts commit 41efa43. IMS (Interrupt Message Store) support appeared in v6.2, but there are no users yet. Remove it for now. We can add it back when a user comes along. If this is re-added later, this could be squashed with these commits: 0194425 ("PCI/MSI: Provide IMS (Interrupt Message Store) support") c9e5bea ("PCI/MSI: Provide pci_ims_alloc/free_irq()") which added the non-stub implementations. Link: https://lore.kernel.org/r/20240410221307.2162676-2-helgaas@kernel.org Signed-off-by: Bjorn Helgaas <bhelgaas@google.com> Reviewed-by: Kevin Tian <kevin.tian@intel.com> Reviewed-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 9790a7acc3527f5cd2dd3b273f6df8e02e432793)

[ Upstream commit 245eeff ] If the "spk-id-gpios" property is present it points to GPIOs whose value must be used to select the correct bin file to match the speakers. Some manufacturers use multiple sources of speakers, which need different tunings for best performance. On these models the type of speaker fitted is indicated by the values of one or more GPIOs. The number formed by the GPIOs identifies the tuning required. The speaker ID must be used in combination with the subsystem ID (either from PCI SSID or cirrus,firmware-uid property), because the GPIOs can only indicate variants of a specific model. Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com> Fixes: 1a1c3d7 ("ASoC: cs35l56: Use PCI SSID as the firmware UID") Link: https://msgid.link/r/20240129162737.497-14-rf@opensource.cirrus.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit e905bc71e7ed093bbfe7cd15c6742afba7304c58)

[ Upstream commit 56156a7 ] There are devices in the wild, like the Sony Xperia 1 V that *require* different tuning than the base design for USB to work. Add support for overriding the necessary tuning values. Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org> Link: https://lore.kernel.org/r/20230830-topic-eusb2_override-v2-4-7d8c893d93f6@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org> Stable-dep-of: 734550d ("phy: qualcomm: eusb2-repeater: Rework init to drop redundant zero-out loop") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit fa3532b1540fa4562a941ac837158d8efcde00b4)

… loop [ Upstream commit 734550d ] Instead of incrementing the base of the global reg fields, which renders the second instance of the repeater broken due to wrong offsets, use regmap with base and offset. As for zeroing out the rest of the tuning regs, avoid looping though the table and just use the table as is, as it is already zero initialized. Fixes: 99a517a ("phy: qualcomm: phy-qcom-eusb2-repeater: Zero out untouched tuning regs") Tested-by: Elliot Berman <quic_eberman@quicinc.com> # sm8650-qrd Signed-off-by: Abel Vesa <abel.vesa@linaro.org> Link: https://lore.kernel.org/r/20240201-phy-qcom-eusb2-repeater-fixes-v4-1-cf18c8cef6d7@linaro.org Signed-off-by: Vinod Koul <vkoul@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 9060935b4b8b9ee45fa9d5fbc89f23bb2ee01a02)

[ Upstream commit 2aedfe847b4d91eabee11a44c27244055cef4eb3 ] The qd_bh_get_or_undo() helper introduced by that commit doesn't improve the code much, so revert it and clean things up in a more useful way in the next commit. This reverts commit 7dbc6ae. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Stable-dep-of: 4b4b6374dc61 ("gfs2: Revert "ignore negated quota changes"") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit e51c5aff8480f780d08945d261bb3bfbfa03a23d)

[ Upstream commit 59ebc33201237bf38e5adca3794716100660c5b4 ] Rename qd_check_sync() to qd_grab_sync() and make it return a bool. Turn the sync_gen pointer into a regular u64 and pass in U64_MAX instead of a NULL pointer when sync generation checking isn't needed. Introduce a new qd_ungrab_sync() helper for undoing the effects of qd_grab_sync() if the subsequent bh_get() on the qd object fails. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Stable-dep-of: 4b4b6374dc61 ("gfs2: Revert "ignore negated quota changes"") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 8251e3b0ce92299f461e4e83600ee57e97c060dc)

[ Upstream commit 4b4b6374dc6134849f2bdca81fa2945b6ed6d9fc ] Commit 4c6a081 ("gfs2: ignore negated quota changes") skips quota changes with qd_change == 0 instead of writing them back, which leaves behind non-zero qd_change values in the affected slots. The kernel then assumes that those slots are unused, while the qd_change values on disk indicate that they are indeed still in use. The next time the filesystem is mounted, those invalid slots are read in from disk, which will cause inconsistencies. Revert that commit to avoid filesystem corruption. This reverts commit 4c6a081. Signed-off-by: Andreas Gruenbacher <agruenba@redhat.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 50e33567bc4a1c4ed79a1d289fe93c9a26491848)

[ Upstream commit a7565f4 ] The commit be97d0d ("riscv: VMAP_STACK overflow detection thread-safe") got rid of `shadow_stack`, so SHADOW_OVERFLOW_STACK_SIZE should be removed too. Fixes: be97d0d ("riscv: VMAP_STACK overflow detection thread-safe") Signed-off-by: Song Shuai <songshuaishuai@tinylab.org> Reviewed-by: Sami Tolvanen <samitolvanen@google.com> Link: https://lore.kernel.org/r/20231211110331.359534-1-songshuaishuai@tinylab.org Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 6e0d0554d857c7cda10f11a2f3fdf0bb76e0fa3d)

[ Upstream commit ac63187 ] The recent change to allow large frames without hardware checksumming slotted in software checksumming in the driver if hardware could not do it. This will however upset TSO (TCP Segment Offloading). Typical error dumps includes this: skb len=2961 headroom=222 headlen=66 tailroom=0 (...) WARNING: CPU: 0 PID: 956 at net/core/dev.c:3259 skb_warn_bad_offload+0x7c/0x108 gemini-ethernet-port: caps=(0x0000010000154813, 0x00002007ffdd7889) And the packets do not go through. The TSO implementation is bogus: a TSO enabled driver must propagate the skb_shinfo(skb)->gso_size value to the TSO engine on the NIC. Drop the size check and TSO offloading features for now: this needs to be fixed up properly. After this ethernet works fine on Gemini devices with a direct connected PHY such as D-Link DNS-313. Also tested to still be working with a DSA switch using the Gemini ethernet as conduit interface. Link: https://lore.kernel.org/netdev/CANn89iJLfxng1sYL5Zk0mknXpyYQPCp83m3KgD2KJ2_hKCpEUg@mail.gmail.com/ Suggested-by: Eric Dumazet <edumazet@google.com> Fixes: d4d0c5b ("net: ethernet: cortina: Handle large frames") Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 452c0740d72c6a77a41f6ddc318a48f18c3d2346)

…BP (again) [ Upstream commit 9dfc46c ] The current measured frame rate is 59.95Hz, which does not meet the requirements of touch-stylus and stylus cannot work normally. After adjustment, the actual measurement is 60.001Hz. Now this panel looks like it's only used by me on the MTK platform, so let's change this set of parameters. [ dianders: Added "(again") to subject and fixed the "Fixes" line ] Fixes: cea7008 ("drm/panel: boe-tv101wum-nl6: Fine tune Himax83102-j02 panel HFP and HBP") Signed-off-by: Cong Yang <yangcong5@huaqin.corp-partner.google.com> Signed-off-by: Douglas Anderson <dianders@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20240301061128.3145982-1-yangcong5@huaqin.corp-partner.google.com Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 9dd05dac697c06c8408f8cb35c6fae6f8cb1bafc)

[ Upstream commit 5efd3e2 ] This reverts 60be76e ("tracing: Add size check when printing trace_marker output"). The only reason the precision check was added was because of a bug that miscalculated the write size of the string into the ring buffer and it truncated it removing the terminating nul byte. On reading the trace it crashed the kernel. But this was due to the bug in the code that happened during development and should never happen in practice. If anything, the precision can hide bugs where the string in the ring buffer isn't nul terminated and it will not be checked. Link: https://lore.kernel.org/all/C7E7AF1A-D30F-4D18-B8E5-AF1EF58004F5@linux.ibm.com/ Link: https://lore.kernel.org/linux-trace-kernel/20240227125706.04279ac2@gandalf.local.home Link: https://lore.kernel.org/all/20240302111244.3a1674be@gandalf.local.home/ Link: https://lore.kernel.org/linux-trace-kernel/20240304174341.2a561d9f@gandalf.local.home Cc: Masami Hiramatsu <mhiramat@kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Fixes: 60be76e ("tracing: Add size check when printing trace_marker output") Reported-by: Sachin Sant <sachinp@linux.ibm.com> Tested-by: Sachin Sant <sachinp@linux.ibm.com> Reviewed-by: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit e87cb9dd3fadc46388a3e2f6fbdb290fcb6d3096)

[ Upstream commit 852d432 ] Move entry {0x1043, 0x16a3, "ASUS UX3402VA"} following device ID order. Remove duplicate entry for device {0x1043, 0x1f62, "ASUS UX7602ZM"}. Fixes: 51d9760 ("ALSA: hda/realtek: Add quirks for ASUS Zenbook 2022 Models") Signed-off-by: Jean-Loïc Charroud <lagiraudiere+linux@free.fr> Link: https://lore.kernel.org/r/1969151851.650354669.1707867864074.JavaMail.zimbra@free.fr Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit c800174e08653226031a1180246cdeff9b3a39fd)

[ Upstream commit b910504 ] The patch 51d9760 ("ALSA: hda/realtek: Add quirks for ASUS Zenbook 2022 Models") modified the entry 1043:1e2e from "ASUS UM3402" to "ASUS UM6702RA/RC" and added another entry for "ASUS UM3402" with 104e:1ee2. The first entry was correct, while the new one corresponds to model "ASUS UM6702RA/RC" Fix the model names for both devices. Fixes: 51d9760 ("ALSA: hda/realtek: Add quirks for ASUS Zenbook 2022 Models") Signed-off-by: Jean-Loïc Charroud <lagiraudiere+linux@free.fr> Link: https://lore.kernel.org/r/1656546983.650349575.1707867732866.JavaMail.zimbra@free.fr Signed-off-by: Takashi Iwai <tiwai@suse.de> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 0d3d2236a0e092c02930638526eb675283ffe625)

[ Upstream commit b6802b6 ] DRM_MODESET_LOCK_ALL_BEGIN() has a hidden trap-door (aka retry loop), which means we can't rely too much on variable initializers. Fixes: 6e455f5 ("drm/crtc: fix uninitialized variable use") Signed-off-by: Rob Clark <robdclark@chromium.org> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Reviewed-by: Abhinav Kumar <quic_abhinavk@quicinc.com> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Tested-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> # sc7180, sdm845 Link: https://patchwork.freedesktop.org/patch/msgid/20240212215534.190682-1-robdclark@gmail.com Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit be6c52b059a28ec7f78a135061f2cc16b352ef70)

[ Upstream commit 9271052 ] In the preparation for adding async API support, let's rename the existing APIs to read_sync() and write_sync() to make it explicit that these APIs are used for synchronous read/write. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Stable-dep-of: c7d0b2db5bc5 ("bus: mhi: ep: Do not allocate memory for MHI objects from DMA zone") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit efdfa92a823a56b9a9fb4e9e9168c69b6db3b3b4)

[ Upstream commit 8b786ed ] These callbacks can be implemented by the controller drivers to perform async read/write operation that increases the throughput. For aiding the async operation, a completion callback is also introduced. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Stable-dep-of: c7d0b2db5bc5 ("bus: mhi: ep: Do not allocate memory for MHI objects from DMA zone") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit a77e5950f93fbef4d4314ffbd652fe199c6c0592)

[ Upstream commit ee08acb ] In order to optimize the data transfer, let's use the async DMA operation for writing (queuing) data to the host. In the async path, the completion event for the transfer ring will only be sent to the host when the controller driver notifies the MHI stack of the actual transfer completion using the callback (mhi_ep_skb_completion) supplied in "struct mhi_ep_buf_info". Also to accommodate the async operation, the transfer ring read offset (ring->rd_offset) is cached in the "struct mhi_ep_chan" and updated locally to let the stack queue further ring items to the controller driver. But the actual read offset of the transfer ring will only be updated in the completion callback. Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Stable-dep-of: c7d0b2db5bc5 ("bus: mhi: ep: Do not allocate memory for MHI objects from DMA zone") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit b6af3a95417b91d2fd519deb0bb7c03729012877)

[ Upstream commit 2547beb ] As like the async DMA write operation, let's add support for async DMA read operation. In the async path, the data will be read from the transfer ring continuously and when the controller driver notifies the stack using the completion callback (mhi_ep_read_completion), then the client driver will be notified with the read data and the completion event will be sent to the host for the respective ring element (if requested by the host). Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Stable-dep-of: c7d0b2db5bc5 ("bus: mhi: ep: Do not allocate memory for MHI objects from DMA zone") Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 39601f49c9e0fc4c9ecea0fe583127f1616204a5)

[ Upstream commit c7d0b2db5bc5e8c0fdc67b3c8f463c3dfec92f77 ] MHI endpoint stack accidentally started allocating memory for objects from DMA zone since commit 62210a2 ("bus: mhi: ep: Use slab allocator where applicable"). But there is no real need to allocate memory from this naturally limited DMA zone. This also causes the MHI endpoint stack to run out of memory while doing high bandwidth transfers. So let's switch over to normal memory. Cc: <stable@vger.kernel.org> # 6.8 Fixes: 62210a2 ("bus: mhi: ep: Use slab allocator where applicable") Reviewed-by: Mayank Rana <quic_mrana@quicinc.com> Link: https://lore.kernel.org/r/20240603164354.79035-1-manivannan.sadhasivam@linaro.org Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 43987659fa9c1a183af71730304f041de3fd264c)

[ Upstream commit 914d081 ] This reverts commit 482b718. The preceding commits by Nicholas Piggin enable PS3 support for ELFv2, so there's no need to disable it for PS3 anymore. Signed-off-by: Geoff Levand <geoff@infradead.org> Signed-off-by: Michael Ellerman <mpe@ellerman.id.au> Link: https://msgid.link/983836405df1b6001a2262972fb32d1aee97d6f5.1705654669.git.geoff@infradead.org Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit bd1521e0ea9a6f2425d7a1f909f2bf24f07be093)

[ Upstream commit 3e36031 ] The VFs don't run the health thread, so don't try to stop or restart the non-existent timer or work item. Fixes: d9407ff ("pds_core: Prevent health thread from running during reset/remove") Reviewed-by: Brett Creeley <brett.creeley@amd.com> Signed-off-by: Shannon Nelson <shannon.nelson@amd.com> Link: https://lore.kernel.org/r/20240210002002.49483-1-shannon.nelson@amd.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit fb90d972954929185fb31a01e964c24f2920f1bc)

[ Upstream commit 321e3c3 ] The cursor is no longer initialized in the OSD client, causing the sparse read state machine to fall into an infinite loop. The cursor should be initialized in IN_S_PREPARE_SPARSE_DATA state. [ idryomov: use msg instead of con->in_msg, changelog ] Link: https://tracker.ceph.com/issues/64607 Fixes: 8e46a2d ("libceph: just wait for more data to be available on the socket") Signed-off-by: Xiubo Li <xiubli@redhat.com> Reviewed-by: Ilya Dryomov <idryomov@gmail.com> Tested-by: Luis Henriques <lhenriques@suse.de> Signed-off-by: Ilya Dryomov <idryomov@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 26c907b8d887aee7d9bfdd373b0db88d8336af54)

[ Upstream commit 0b18c85 ] The saved_cmdlines have three arrays for mapping PIDs to COMMs: - map_pid_to_cmdline[] - map_cmdline_to_pid[] - saved_cmdlines The map_pid_to_cmdline[] is PID_MAX_DEFAULT in size and holds the index into the other arrays. The map_cmdline_to_pid[] is a mapping back to the full pid as it can be larger than PID_MAX_DEFAULT. And the saved_cmdlines[] just holds the COMMs associated to the pids. Currently the map_pid_to_cmdline[] and saved_cmdlines[] are allocated together (in reality the saved_cmdlines is just in the memory of the rounding of the allocation of the structure as it is always allocated in powers of two). The map_cmdline_to_pid[] array is allocated separately. Since the rounding to a power of two is rather large (it allows for 8000 elements in saved_cmdlines), also include the map_cmdline_to_pid[] array. (This drops it to 6000 by default, which is still plenty for most use cases). This saves even more memory as the map_cmdline_to_pid[] array doesn't need to be allocated. Link: https://lore.kernel.org/linux-trace-kernel/20240212174011.068211d9@gandalf.local.home/ Link: https://lore.kernel.org/linux-trace-kernel/20240220140703.182330529@goodmis.org Cc: Mark Rutland <mark.rutland@arm.com> Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Tim Chen <tim.c.chen@linux.intel.com> Cc: Vincent Donnefort <vdonnefort@google.com> Cc: Sven Schnelle <svens@linux.ibm.com> Cc: Mete Durlu <meted@linux.ibm.com> Fixes: 44dc5c4 ("tracing: Fix wasted memory in saved_cmdlines logic") Acked-by: Masami Hiramatsu (Google) <mhiramat@kernel.org> Signed-off-by: Steven Rostedt (Google) <rostedt@goodmis.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 5915b8981ad66a731e58c30debd67f327fcb4c28)

[ Upstream commit e482eab ] The riscv_cpuinfo struct that contains mvendorid and marchid is not populated until all harts are booted which happens after the DT parsing. Use the mvendorid/marchid from the boot hart to determine if the DT contains an invalid V. Fixes: d82f322 ("RISC-V: Ignore V from the riscv,isa DT property on older T-Head CPUs") Signed-off-by: Charlie Jenkins <charlie@rivosinc.com> Reviewed-by: Conor Dooley <conor.dooley@microchip.com> Reviewed-by: Guo Ren <guoren@kernel.org> Link: https://lore.kernel.org/r/20240502-cpufeature_fixes-v4-1-b3d1a088722d@rivosinc.com Signed-off-by: Palmer Dabbelt <palmer@rivosinc.com> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 18f3fdb1749694c4e793b262b99b33740deea994)

[ Upstream commit bff892a ] devm_spi_alloc_controller will allocate an SPI controller and automatically release a reference on it when dev is unbound from its driver. It doesn't need to call spi_controller_put explicitly to put the reference when lpspi driver failed initialization. Fixes: 2ae0ab0 ("spi: lpspi: Avoid potential use-after-free in probe()") Signed-off-by: Carlos Song <carlos.song@nxp.com> Reviewed-by: Alexander Sverdlin <alexander.sverdlin@siemens.com> Link: https://msgid.link/r/20240403084029.2000544-1-carlos.song@nxp.com Signed-off-by: Mark Brown <broonie@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 924c0af49c636da1ad577322db22233b6748024a)

[ Upstream commit 24cfd86 ] Commits 0077a50 ("ahci: asm1166: correct count of reported ports") and 9815e39 ("ahci: asm1064: correct count of reported ports") attempted to limit the ports of the ASM1166 and ASM1064 AHCI controllers to avoid long boot times caused by the fact that these adapters report a port map larger than the number of physical ports. The excess ports are "virtual" to hide port multiplier devices and probing these ports takes time. However, these commits caused a regression for users that do use PMP devices, as the ATA devices connected to the PMP cannot be scanned. These commits have thus been reverted by commit 6cd8adc ("ahci: asm1064: asm1166: don't limit reported ports") to allow the discovery of devices connected through a port multiplier. But this revert re-introduced the long boot times for users that do not use a port multiplier setup. This patch adds the mask_port_map ahci module parameter to allow users to manually specify port map masks for controllers. In the case of the ASMedia 1166 and 1064 controllers, users that do not have port multiplier devices can mask the excess virtual ports exposed by the controller to speedup port scanning, thus reducing boot time. The mask_port_map parameter accepts 2 different formats: - mask_port_map=<mask> This applies the same mask to all AHCI controllers present in the system. This format is convenient for small systems that have only a single AHCI controller. - mask_port_map=<pci_dev>=<mask>,<pci_dev>=mask,... This applies the specified masks only to the PCI device listed. The <pci_dev> field is a regular PCI device ID (domain:bus:dev.func). This ID can be seen following "ahci" in the kernel messages. E.g. for "ahci 0000:01:00.0: 2/2 ports implemented (port mask 0x3)", the <pci_dev> field is "0000:01:00.0". When used, the function ahci_save_initial_config() indicates that a port map mask was applied with the message "masking port_map ...". E.g.: without a mask: modprobe ahci dmesg | grep ahci ... ahci 0000:00:17.0: AHCI vers 0001.0301, 32 command slots, 6 Gbps, SATA mode ahci 0000:00:17.0: (0000:00:17.0) 8/8 ports implemented (port mask 0xff) With a mask: modprobe ahci mask_port_map=0000:00:17.0=0x1 dmesg | grep ahci ... ahci 0000:00:17.0: masking port_map 0xff -> 0x1 ahci 0000:00:17.0: AHCI vers 0001.0301, 32 command slots, 6 Gbps, SATA mode ahci 0000:00:17.0: (0000:00:17.0) 1/8 ports implemented (port mask 0x1) Signed-off-by: Damien Le Moal <dlemoal@kernel.org> Reviewed-by: Niklas Cassel <cassel@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> (cherry picked from commit 9c122d020a62cbc747744587554e63fcd5f4892d)

commit a99fcb0158978ed332009449b484e5f3ca2d7df4 upstream. Per Qu Wenruo in case we have a very large disk, e.g. 8TiB device, mostly empty although we will do the split according to our super block locations, the last super block ends at 256G, we can submit a huge discard for the range [256G, 8T), causing a large delay. Split the space left to discard based on BTRFS_MAX_DISCARD_CHUNK_SIZE in preparation of introduction of cancellation points to trim. The value of the chunk size is arbitrary, it can be higher or derived from actual device capabilities but we can't easily read that using bio_discard_limit(). Link: https://bugzilla.kernel.org/show_bug.cgi?id=219180 Link: https://bugzilla.suse.com/show_bug.cgi?id=1229737 CC: stable@vger.kernel.org # 5.15+ Signed-off-by: Luca Stefani <luca.stefani.ge1@gmail.com> Reviewed-by: David Sterba <dsterba@suse.com> Signed-off-by: David Sterba <dsterba@suse.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit f00545e8386e228aac739588b40a6f200e0f0ffc)

commit 214e01ad4ed7158cab66498810094fac5d09b218 upstream. Calling into kthread unparking unconditionally is mostly harmless when the kthread is already unparked. The wake up is then simply ignored because the target is not in TASK_PARKED state. However if the kthread is per CPU, the wake up is preceded by a call to kthread_bind() which expects the task to be inactive and in TASK_PARKED state, which obviously isn't the case if it is unparked. As a result, calling kthread_stop() on an unparked per-cpu kthread triggers such a warning: WARNING: CPU: 0 PID: 11 at kernel/kthread.c:525 __kthread_bind_mask kernel/kthread.c:525 <TASK> kthread_stop+0x17a/0x630 kernel/kthread.c:707 destroy_workqueue+0x136/0xc40 kernel/workqueue.c:5810 wg_destruct+0x1e2/0x2e0 drivers/net/wireguard/device.c:257 netdev_run_todo+0xe1a/0x1000 net/core/dev.c:10693 default_device_exit_batch+0xa14/0xa90 net/core/dev.c:11769 ops_exit_list net/core/net_namespace.c:178 [inline] cleanup_net+0x89d/0xcc0 net/core/net_namespace.c:640 process_one_work kernel/workqueue.c:3231 [inline] process_scheduled_works+0xa2c/0x1830 kernel/workqueue.c:3312 worker_thread+0x86d/0xd70 kernel/workqueue.c:3393 kthread+0x2f0/0x390 kernel/kthread.c:389 ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244 </TASK> Fix this with skipping unecessary unparking while stopping a kthread. Link: https://lkml.kernel.org/r/20240913214634.12557-1-frederic@kernel.org Fixes: 5c25b5f ("workqueue: Tag bound workers with KTHREAD_IS_PER_CPU") Signed-off-by: Frederic Weisbecker <frederic@kernel.org> Reported-by: syzbot+943d34fa3cf2191e3068@syzkaller.appspotmail.com Tested-by: syzbot+943d34fa3cf2191e3068@syzkaller.appspotmail.com Suggested-by: Thomas Gleixner <tglx@linutronix.de> Cc: Hillf Danton <hdanton@sina.com> Cc: Tejun Heo <tj@kernel.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 19a5029981c87c2ad0845e713837faa88f5d8e2b)

commit 3d5854d75e3187147613130561b58f0b06166172 upstream. When /proc/kcore is read an attempt to read the first two pages results in HW-specific page swap on s390 and another (so called prefix) pages are accessed instead. That leads to a wrong read. Allow architecture-specific translation of memory addresses using kc_xlate_dev_mem_ptr() and kc_unxlate_dev_mem_ptr() callbacks similarily to /dev/mem xlate_dev_mem_ptr() and unxlate_dev_mem_ptr() callbacks. That way an architecture can deal with specific physical memory ranges. Re-use the existing /dev/mem callback implementation on s390, which handles the described prefix pages swapping correctly. For other architectures the default callback is basically NOP. It is expected the condition (vaddr == __va(__pa(vaddr))) always holds true for KCORE_RAM memory type. Link: https://lkml.kernel.org/r/20240930122119.1651546-1-agordeev@linux.ibm.com Signed-off-by: Alexander Gordeev <agordeev@linux.ibm.com> Suggested-by: Heiko Carstens <hca@linux.ibm.com> Cc: Vasily Gorbik <gor@linux.ibm.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit e5a0031c7965d7b61a898146adfc4fe375742e2d)

commit 532b53cebe58f34ce1c0f34d866f5c0e335c53c6 upstream. Return -ENOSYS from memfd_secret() syscall if !can_set_direct_map(). This is the case for example on some arm64 configurations, where marking 4k PTEs in the direct map not present can only be done if the direct map is set up at 4k granularity in the first place (as ARM's break-before-make semantics do not easily allow breaking apart large/gigantic pages). More precisely, on arm64 systems with !can_set_direct_map(), set_direct_map_invalid_noflush() is a no-op, however it returns success (0) instead of an error. This means that memfd_secret will seemingly "work" (e.g. syscall succeeds, you can mmap the fd and fault in pages), but it does not actually achieve its goal of removing its memory from the direct map. Note that with this patch, memfd_secret() will start erroring on systems where can_set_direct_map() returns false (arm64 with CONFIG_RODATA_FULL_DEFAULT_ENABLED=n, CONFIG_DEBUG_PAGEALLOC=n and CONFIG_KFENCE=n), but that still seems better than the current silent failure. Since CONFIG_RODATA_FULL_DEFAULT_ENABLED defaults to 'y', most arm64 systems actually have a working memfd_secret() and aren't be affected. From going through the iterations of the original memfd_secret patch series, it seems that disabling the syscall in these scenarios was the intended behavior [1] (preferred over having set_direct_map_invalid_noflush return an error as that would result in SIGBUSes at page-fault time), however the check for it got dropped between v16 [2] and v17 [3], when secretmem moved away from CMA allocations. [1]: https://lore.kernel.org/lkml/20201124164930.GK8537@kernel.org/ [2]: https://lore.kernel.org/lkml/20210121122723.3446-11-rppt@kernel.org/#t [3]: https://lore.kernel.org/lkml/20201125092208.12544-10-rppt@kernel.org/ Link: https://lkml.kernel.org/r/20241001080056.784735-1-roypat@amazon.co.uk Fixes: 1507f51 ("mm: introduce memfd_secret system call to create "secret" memory areas") Signed-off-by: Patrick Roy <roypat@amazon.co.uk> Reviewed-by: Mike Rapoport (Microsoft) <rppt@kernel.org> Cc: Alexander Graf <graf@amazon.com> Cc: David Hildenbrand <david@redhat.com> Cc: James Gowans <jgowans@amazon.com> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 7caf966390e6e4ebf42775df54e7ee1f280ce677)

commit 2942dfab630444d46aaa37fb7d629b620abbf6ba upstream. An earlier commit deleted the TSO support in the Cortina Gemini driver because the driver was confusing gso_size and MTU, probably because what the Linux kernel calls "gso_size" was called "MTU" in the datasheet. Restore the functionality properly reading the gso_size from the skbuff. Tested with iperf3, running a server on a different machine and client on the device with the cortina gemini ethernet: Connecting to host 192.168.1.2, port 5201 60008000.ethernet-port eth0: segment offloading mss = 05ea len=1c8a 60008000.ethernet-port eth0: segment offloading mss = 05ea len=1c8a 60008000.ethernet-port eth0: segment offloading mss = 05ea len=27da 60008000.ethernet-port eth0: segment offloading mss = 05ea len=0b92 60008000.ethernet-port eth0: segment offloading mss = 05ea len=2bda (...) (The hardware MSS 0x05ea here includes the ethernet headers.) If I disable all segment offloading on the receiving host and dump packets using tcpdump -xx like this: ethtool -K enp2s0 gro off gso off tso off tcpdump -xx -i enp2s0 host 192.168.1.136 I get segmented packages such as this when running iperf3: 23:16:54.024139 IP OpenWrt.lan.59168 > Fecusia.targus-getdata1: Flags [.], seq 1486:2934, ack 1, win 4198, options [nop,nop,TS val 3886192908 ecr 3601341877], length 1448 0x0000: fc34 9701 a0c6 14d6 4da8 3c4f 0800 4500 0x0010: 05dc 16a0 4000 4006 9aa1 c0a8 0188 c0a8 0x0020: 0102 e720 1451 ff25 9822 4c52 29cf 8010 0x0030: 1066 ac8c 0000 0101 080a e7a2 990c d6a8 (...) 0x05c0: 5e49 e109 fe8c 4617 5e18 7a82 7eae d647 0x05d0: e8ee ae64 dc88 c897 3f8a 07a4 3a33 6b1b 0x05e0: 3501 a30f 2758 cc44 4b4a Several such packets often follow after each other verifying the segmentation into 0x05a8 (1448) byte packages also on the reveiving end. As can be seen, the ethernet frames are 0x05ea (1514) in size. Performance with iperf3 before this patch: ~15.5 Mbit/s Performance with iperf3 after this patch: ~175 Mbit/s This was running a 60 second test (twice) the best measurement was 179 Mbit/s. For comparison if I run iperf3 with UDP I get around 1.05 Mbit/s both before and after this patch. While this is a gigabit ethernet interface, the CPU is a cheap D-Link DIR-685 router (based on the ARMv5 Faraday FA526 at ~50 MHz), and the software is not supposed to drive traffic, as the device has a DSA chip, so this kind of numbers can be expected. Fixes: ac63187 ("net: ethernet: cortina: Drop TSO support") Reviewed-by: Eric Dumazet <edumazet@google.com> Signed-off-by: Linus Walleij <linus.walleij@linaro.org> Signed-off-by: David S. Miller <davem@davemloft.net> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 611f74b0e7fb93ee2366d9d7edca546806b220e9)

commit 76a0a3f9cc2fbd0e56671706bb74a9a988397898 upstream. Commit 861e808 ("e1000e: move force SMBUS from enable ulp function to avoid PHY loss issue") resolved a PHY access loss during suspend on Meteor Lake consumer platforms, but it affected corporate systems incorrectly. A better fix, working for both consumer and corporate systems, was proposed in commit bfd546a ("e1000e: move force SMBUS near the end of enable_ulp function"). However, it introduced a regression on older devices, such as [8086:15B8], [8086:15F9], [8086:15BE]. This patch aims to fix the secondary regression, by limiting the scope of the changes to Meteor Lake platforms only. Fixes: bfd546a ("e1000e: move force SMBUS near the end of enable_ulp function") Reported-by: Todd Brandt <todd.e.brandt@intel.com> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218940 Reported-by: Dieter Mummenschanz <dmummenschanz@web.de> Closes: https://bugzilla.kernel.org/show_bug.cgi?id=218936 Signed-off-by: Vitaly Lifshits <vitaly.lifshits@intel.com> Tested-by: Mor Bar-Gabay <morx.bar.gabay@intel.com> (A Contingent Worker at Intel) Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com> Reviewed-by: Simon Horman <horms@kernel.org> Link: https://patch.msgid.link/20240709203123.2103296-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit e6fc67c0efead79a977f850474363273e9cc5f9d)

commit da3e19ef0b3de0aa4b25595bdc214c02a04f19b8 upstream. This reverts commit 7a6bbc2829d4ab592c7e440a6f6f5deb3cd95db4. The offending commit tried to suppress a double "Starting disk" message for some drivers, but instead started spamming the log with bogus messages every five seconds: [ 311.798956] sd 0:0:0:0: [sda] Starting disk [ 316.919103] sd 0:0:0:0: [sda] Starting disk [ 322.040775] sd 0:0:0:0: [sda] Starting disk [ 327.161140] sd 0:0:0:0: [sda] Starting disk [ 332.281352] sd 0:0:0:0: [sda] Starting disk [ 337.401878] sd 0:0:0:0: [sda] Starting disk [ 342.521527] sd 0:0:0:0: [sda] Starting disk [ 345.850401] sd 0:0:0:0: [sda] Starting disk [ 350.967132] sd 0:0:0:0: [sda] Starting disk [ 356.090454] sd 0:0:0:0: [sda] Starting disk ... on machines that do not actually stop the disk on runtime suspend (e.g. the Qualcomm sc8280xp CRD with UFS). Let's just revert for now to address the regression. Fixes: 7a6bbc2829d4 ("scsi: sd: Do not repeat the starting disk message") Cc: stable@vger.kernel.org Signed-off-by: Johan Hovold <johan+linaro@kernel.org> Link: https://lore.kernel.org/r/20240716161101.30692-1-johan+linaro@kernel.org Reviewed-by: Bart Van Assche <bvanassche@acm.org> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit 8d5aebfff8462abea4eb63377ed80c405eb9aa93)

Link: https://lore.kernel.org/r/20241014141042.954319779@linuxfoundation.org Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Peter Schneider <pschneider1968@googlemail.com> Tested-by: Jon Hunter <jonathanh@nvidia.com> Tested-by: Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20241015112327.341300635@linuxfoundation.org Tested-by: Takeshi Ogasawara <takeshi.ogasawara@futuring-girl.com> Tested-by: Ron Economos <re@w6rz.net> Tested-by: Florian Fainelli <florian.fainelli@broadcom.com> Tested-by: Kexy Biscuit <kexybiscuit@aosc.io> Tested-by: Linux Kernel Functional Testing <lkft@linaro.org> Tested-by: Jon Hunter <jonathanh@nvidia.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> (cherry picked from commit e9448e371c87c76f9133bb3b27918854f4dc087b)

github-actions · 2024-10-17T14:49:50Z

Documentation/dev-tools/kselftest.rst

+    * the part of paths below tools/testing/selftests/ is preserved when
+      copying the files to the output directory
+
+   TEST_INCLUDES is meant to list dependencies located in other directories of
