Tech/bus/usb/gadget #422
Open
Tech/bus/usb/gadget #422
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…m/linux/kernel/git/sunxi/linux into clk-fixes Pull Allwinner clk driver fixes from Chen-Yu Tsai: Just a couple fixes for the A523 family. A couple clocks are marked as critical, and the lower bound of the audio PLL was lowered to match the datasheet. * tag 'sunxi-clk-fixes-for-6.18' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: clk: sunxi-ng: sun55i-a523-ccu: Lower audio0 pll minimum rate clk: sunxi-ng: sun55i-a523-r-ccu: Mark bus-r-dma as critical clk: sunxi-ng: Mark A523 bus-r-cpucfg clock as critical
In commit 0345691 ("tick/rcu: Stop allowing RCU_SOFTIRQ in idle") the new function report_idle_softirq() was created by breaking code out of the existing can_stop_idle_tick() for kernels v5.18 and newer. In doing so, the code essentially went from this form: if (A) { static int ratelimit; if (ratelimit < 10 && !C && A&D) { pr_warn("NOHZ tick-stop error: ..."); ratelimit++; } return false; } to a new function: static bool report_idle_softirq(void) { static int ratelimit; if (likely(!A)) return false; if (ratelimit < 10) return false; ... pr_warn("NOHZ tick-stop error: local softirq work is pending, handler #%02x!!!\n", pending); ratelimit++; return true; } commit a7e282c ("tick/rcu: Fix bogus ratelimit condition") realized ratelimit was essentially set to zero instead of ten, and hence *no* softirq pending messages would ever be issued, but "fixed" it as: - if (ratelimit < 10) + if (ratelimit >= 10) return false; However, this fix introduced another issue: When ratelimit is greater than or equal 10, even if A is true, it will directly return false. While ratelimit in the original code was only used to control printing and will not affect the return value. Restore the original logic and restrict ratelimit to control the printk and not the return value. Fixes: 0345691 ("tick/rcu: Stop allowing RCU_SOFTIRQ in idle") Fixes: a7e282c ("tick/rcu: Fix bogus ratelimit condition") Signed-off-by: Wen Yang <wen.yang@linux.dev> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Link: https://patch.msgid.link/20251119174525.29470-1-wen.yang@linux.dev
During the suspend sequence VPE is already going to be power gated as part of vpe_suspend(). It's unnecessary to call during calls to amdgpu_device_set_pg_state(). It actually can expose a race condition with the firmware if s0i3 sequence starts as well. Drop these calls. Cc: Peyton.Lee@amd.com Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 2a6c826) Cc: stable@vger.kernel.org
[Why] Accoreding to CP updated to RS64 on gfx11, WRITE_DATA with PREEMPTION_META_MEMORY(dst_sel=8) is illegal for CP FW. That packet is used for MCBP on F32 based system. So it would lead to incorrect GRBM write and FW is not handling that extra case correctly. [How] With gfx11 rs64 enabled, skip emit de meta data. Signed-off-by: Yifan Zha <Yifan.Zha@amd.com> Acked-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8366cd442d226463e673bed5d199df916f4ecbcf) Cc: stable@vger.kernel.org
This fixes sparse mappings (aka. partially resident textures). Check the correct flags. Since a recent refactor, the code works with uAPI flags (for mapping buffer objects), and not PTE (page table entry) flags. Fixes: 6716a82 ("drm/amdgpu: rework how PTE flags are generated v3") Signed-off-by: Timur Kristóf <timur.kristof@gmail.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 8feeab2)
The MMIO_REMAP BO is a special 4K IO page that does not have a ttm_tt behind it. However, amdgpu_ttm_tt_pde_flags() was treating it like normal TT/doorbell/preempt memory and unconditionally accessed ttm->caching. For the MMIO_REMAP BO, ttm is NULL, so this leads to a NULL pointer dereference when computing PDE flags. Fix this by checking that ttm is non-NULL before reading ttm->caching. This prevents the crash for MMIO_REMAP and also makes the code more defensive if other BOs ever come through without a ttm_tt. Fixes: fb5a52d ("drm/amdgpu: Implement TTM handling for MMIO_REMAP placement") Suggested-by: Jesse Zhang <Jesse.Zhang@amd.com> Suggested-by: Christian König <christian.koenig@amd.com> Cc: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Srinivasan Shanmugam <srinivasan.shanmugam@amd.com> Reviewed-by: Jesse Zhang <Jesse.Zhang@amd.com> Tested-by: Jesse Zhang <Jesse.Zhang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit 0db94da5a0a1cacda080b9ec8425fcbe4babc141)
Add SRIOV check when setting VCN ring's supported reset mask. Signed-off-by: Shikang Fan <shikang.fan@amd.com> Reviewed-by: Lijo Lazar <lijo.lazar@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> (cherry picked from commit ee9b603) Cc: stable@vger.kernel.org
Commit f1eb4e7 ("spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance") relocated code but missed updating the error handling path associated with it. Prior to the relocation, runtime pm was enabled after the code-block associated with 'cqspi_request_mmap_dma()', due to which, the error handling for the same didn't require invoking 'pm_runtime_disable()'. Post refactoring, runtime pm has been enabled before the code-block and when an error is encountered, jumping to 'probe_dma_failed' doesn't invoke 'pm_runtime_disable()'. This leads to a race condition wherein 'cqspi_runtime_suspend()' is invoked while the error handling path executes in parallel. The resulting error is the following: clk:103:0 already disabled WARNING: drivers/clk/clk.c:1188 at clk_core_disable+0x80/0xa0, CPU#1: kworker/u8:0/12 [TRIMMED] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : clk_core_disable+0x80/0xa0 lr : clk_core_disable+0x80/0xa0 [TRIMMED] Call trace: clk_core_disable+0x80/0xa0 (P) clk_core_disable_lock+0x88/0x10c clk_disable+0x24/0x30 cqspi_probe+0xa3c/0xae8 [TRIMMED] The error is due to the second invocation of 'clk_disable_unprepare()' on 'cqspi->clk' in the error handling within 'cqspi_probe()', with the first invocation being within 'cqspi_runtime_suspend()'. Fix this by correcting the error handling. Fixes: f1eb4e7 ("spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance") Signed-off-by: Siddharth Vadapalli <s-vadapalli@ti.com> Link: https://patch.msgid.link/20251119152545.2591651-1-s-vadapalli@ti.com Signed-off-by: Mark Brown <broonie@kernel.org>
Scanning can be offloaded to the firmware. To that end, the driver prepares a list of channels to scan, including periodic visits back to the operating channel, and sends the list to the firmware. When the channel list is too long to fit in a single H2C message, the driver splits the list, sends the first part, and tells the firmware to scan. When the scan is complete, the driver sends the next part of the list and tells the firmware to scan. When the last channel that fit in the H2C message is the operating channel something seems to go wrong in the firmware. It will acknowledge receiving the list of channels but apparently it will not do anything more. The AP can't be pinged anymore. The driver still receives beacons, though. One way to avoid this is to split the list of channels before the operating channel. Affected devices: * RTL8851BU with firmware 0.29.41.3 * RTL8832BU with firmware 0.29.29.8 * RTL8852BE with firmware 0.29.29.8 The commit 57a5fbe ("wifi: rtw89: refactor flow that hw scan handles channel list") is found by git blame, but it is actually to refine the scan flow, but not a culprit, so skip Fixes tag. Reported-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Closes: https://lore.kernel.org/linux-wireless/0abbda91-c5c2-4007-84c8-215679e652e1@gmail.com/ Cc: stable@vger.kernel.org # 6.16+ Signed-off-by: Bitterblue Smith <rtl8821cerfe2@gmail.com> Acked-by: Ping-Ke Shih <pkshih@realtek.com> Signed-off-by: Ping-Ke Shih <pkshih@realtek.com> Link: https://patch.msgid.link/c1e61744-8db4-4646-867f-241b47d30386@gmail.com
sg_finish_rem_req() calls blk_rq_unmap_user(). The latter function may sleep. Hence, call sg_finish_rem_req() with interrupts enabled instead of disabled. Reported-by: syzbot+c01f8e6e73f20459912e@syzkaller.appspotmail.com Closes: https://lore.kernel.org/linux-scsi/691560c4.a70a0220.3124cb.001a.GAE@google.com/ Cc: Hannes Reinecke <hare@suse.de> Cc: stable@vger.kernel.org Fixes: 97d27b0 ("scsi: sg: close race condition in sg_remove_sfp_usercontext()") Signed-off-by: Bart Van Assche <bvanassche@acm.org> Link: https://patch.msgid.link/20251113181643.1108973-1-bvanassche@acm.org Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
mptcp_cleanup_rbuf() needs to know the last most recent, mptcp-level rcv_wnd sent, and such information is tracked into the msk->old_wspace field, updated at ack transmission time by mptcp_write_options(). Fallback socket do not add any mptcp options, such helper is never invoked, and msk->old_wspace value remain stale. That in turn makes ack generation at recvmsg() time quite random. Address the issue ensuring mptcp_write_options() is invoked even for fallback sockets, and just update the needed info in such a case. The issue went unnoticed for a long time, as mptcp currently overshots the fallback socket receive buffer autotune significantly. It is going to change in the near future. Fixes: e385960 ("mptcp: better msk receive window updates") Cc: stable@vger.kernel.org Closes: multipath-tcp/mptcp_net-next#594 Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Geliang Tang <geliang@kernel.org> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-1-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The rcv window is shared among all the subflows. Currently, MPTCP sync the TCP-level rcv window with the MPTCP one at tcp_transmit_skb() time. The above means that incoming data may sporadically observe outdated TCP-level rcv window and being wrongly dropped by TCP. Address the issue checking for the edge condition before queuing the data at TCP level, and eventually syncing the rcv window as needed. Note that the issue is actually present from the very first MPTCP implementation, but backports older than the blamed commit below will range from impossible to useless. Before: $ nstat -n; sleep 1; nstat -z TcpExtBeyondWindow TcpExtBeyondWindow 14 0.0 After: $ nstat -n; sleep 1; nstat -z TcpExtBeyondWindow TcpExtBeyondWindow 0 0.0 Fixes: fa3fe2b ("mptcp: track window announced to peer") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-2-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
I'm observing very frequent self-tests failures in case of fallback when running on a CONFIG_PREEMPT kernel. The root cause is that subflow_sched_work_if_closed() closes any subflow as soon as it is half-closed and has no incoming data pending. That works well for regular subflows - MPTCP needs bi-directional connectivity to operate on a given subflow - but for fallback socket is race prone. When TCP peer closes the connection before the MPTCP one, subflow_sched_work_if_closed() will schedule the MPTCP worker to gracefully close the subflow, and shortly after will do another schedule to inject and process a dummy incoming DATA_FIN. On CONFIG_PREEMPT kernel, the MPTCP worker can kick-in and close the fallback subflow before subflow_sched_work_if_closed() is able to create the dummy DATA_FIN, unexpectedly interrupting the transfer. Address the issue explicitly avoiding closing fallback subflows on when the peer is only half-closed. Note that, when the subflow is able to create the DATA_FIN before the worker invocation, the worker will change the msk state before trying to close the subflow and will skip the latter operation as the msk will not match anymore the precondition in __mptcp_close_subflow(). Fixes: f09b0ad ("mptcp: close subflow when receiving TCP+FIN") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-3-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In case of DSS corruption, the MPTCP protocol tries to avoid the subflow reset if fallback is possible. Such corruptions happen in the receive path; to ensure fallback is possible the stack additionally needs to check for OoO data, otherwise the fallback will break the data stream. Fixes: e32d262 ("mptcp: handle consistently DSS corruption") Cc: stable@vger.kernel.org Closes: multipath-tcp/mptcp_net-next#598 Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-4-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
With the current fastclose implementation, the mptcp_do_fastclose() helper is in charge of two distinct actions: send the fastclose reset and cleanup the subflows. Formally decouple the two steps, ensuring that mptcp explicitly closes all the subflows after the mentioned helper. This will make the upcoming fix simpler, and allows dropping the 2nd argument from mptcp_destroy_common(). The Fixes tag is then the same as in the next commit to help with the backports. Fixes: d21f834 ("mptcp: use fastclose on more edge scenarios") Cc: stable@vger.kernel.org Signed-off-by: Paolo Abeni <pabeni@redhat.com> Reviewed-by: Geliang Tang <geliang@kernel.org> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-5-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The CI reports sporadic failures of the fastclose self-tests. The root
cause is a duplicate reset, not carrying the relevant MPTCP option.
In the failing scenario the bad reset is received by the peer before
the fastclose one, preventing the reception of the latter.
Indeed there is window of opportunity at fastclose time for the
following race:
mptcp_do_fastclose
__mptcp_close_ssk
__tcp_close()
tcp_set_state() [1]
tcp_send_active_reset() [2]
After [1] the stack will send reset to in-flight data reaching the now
closed port. Such reset may race with [2].
Address the issue explicitly sending a single reset on fastclose before
explicitly moving the subflow to close status.
Fixes: d21f834 ("mptcp: use fastclose on more edge scenarios")
Cc: stable@vger.kernel.org
Closes: multipath-tcp/mptcp_net-next#596
Signed-off-by: Paolo Abeni <pabeni@redhat.com>
Reviewed-by: Geliang Tang <geliang@kernel.org>
Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org>
Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-6-806d3781c95f@kernel.org
Signed-off-by: Jakub Kicinski <kuba@kernel.org>
After recent fixes like the parent commit, and "selftests: mptcp: connect: trunc: read all recv data", the two fastclose subtests no longer look flaky any more. It then feels fine to remove these flaky marks, to no longer ignore these subtests in case of errors. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-7-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In rare cases, when the test environment is very slow, some endpoints tests can fail because some expected events have not been seen. Because the tests are expecting a long on-going connection, and they are not waiting for the end of the transfer, it is fine to have a longer timeout, and even go over the default one. This connection will be killed at the end, after the verifications: increasing the timeout doesn't change anything, apart from avoiding it to end before the end of the verifications. To play it safe, all endpoints tests not waiting for the end of the transfer are now having a longer timeout: 2 minutes. The Fixes commit was making the connection longer, but still, the default timeout would have stopped it after 1 minute, which might not be enough in very slow environments. Fixes: 6457595 ("selftests: mptcp: join: endpoints: longer transfer") Cc: stable@vger.kernel.org Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Reviewed-by: Geliang Tang <geliang@kernel.org> Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-8-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
In rare cases, when the test environment is very slow, some userspace tests can fail because some expected events have not been seen. Because the tests are expecting a long on-going connection, and they are not waiting for the end of the transfer, it is fine to have a longer timeout, and even go over the default one. This connection will be killed at the end, after the verifications: increasing the timeout doesn't change anything, apart from avoiding it to end before the end of the verifications. To play it safe, all userspace tests not waiting for the end of the transfer are now having a longer timeout: 2 minutes. The Fixes commit was making the connection longer, but still, the default timeout would have stopped it after 1 minute, which might not be enough in very slow environments. Fixes: 2904930 ("selftests: mptcp: join: userspace: longer transfer") Cc: stable@vger.kernel.org Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Reviewed-by: Geliang Tang <geliang@kernel.org> Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-9-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Fix inverted WARN_ON_ONCE condition that prevented normal address removal counter updates. The current code only executes decrement logic when the counter is already 0 (abnormal state), while normal removals (counter > 0) are ignored. Signed-off-by: Gang Yan <yangang@kylinos.cn> Fixes: 6361139 ("mptcp: pm: remove '_nl' from mptcp_pm_nl_rm_addr_received") Cc: stable@vger.kernel.org Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-10-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The previous patch fixed an issue with the 'add_addr_accepted' counter. This was not spot by the test suite. Check this counter and 'add_addr_signal' in MPTCP Join 'delete re-add signal' test. This should help spotting similar regressions later on. These counters are crucial for ensuring the MPTCP path manager correctly handles the subflow creation via 'ADD_ADDR'. Signed-off-by: Gang Yan <yangang@kylinos.cn> Reviewed-by: Geliang Tang <geliang@kernel.org> Reviewed-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-11-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Matthieu Baerts says: ==================== mptcp: misc fixes for v6.18-rc7 Here are various unrelated fixes: - Patch 1: Fix window space computation for fallback connections which can affect ACK generation. A fix for v5.11. - Patch 2: Avoid unneeded subflow-level drops due to unsynced received window. A fix for v5.11. - Patch 3: Avoid premature close for fallback connections with PREEMPT kernels. A fix for v5.12. - Patch 4: Reset instead of fallback in case of data in the MPTCP out-of-order queue. A fix for v5.7. - Patches 5-7: Avoid also sending "plain" TCP reset when closing with an MP_FASTCLOSE. A fix for v6.1. - Patches 8-9: Longer timeout for background connections in MPTCP Join selftests. An additional fix for recent patches for v5.13/v6.1. - Patches 10-11: Fix typo in a check introduce in a recent refactoring. A fix for v6.15. ==================== Link: https://patch.msgid.link/20251118-net-mptcp-misc-fixes-6-18-rc6-v1-0-806d3781c95f@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
…t/tnguy/net-queue Tony Nguyen says: ==================== Intel Wired LAN Driver Updates 2025-11-18 (idpf, ice) This series contains updates to idpf and ice drivers. Emil adds a check for NULL vport_config during removal to avoid NULL pointer dereference in idpf. Grzegorz fixes PTP teardown paths to account for some missed cleanups for ice driver. * '200GbE' of git://git.kernel.org/pub/scm/linux/kernel/git/tnguy/net-queue: ice: fix PTP cleanup on driver removal in error path idpf: fix possible vport_config NULL pointer deref in remove ==================== Link: https://patch.msgid.link/20251118235207.2165495-1-anthony.l.nguyen@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
The kernel UAPI headers already contain fixed-width integer types, there is no need to rely on the libc types. There may not be a libc available or the libc may not provides the <stdint.h>, like for example on nolibc. This also aligns the header with the rest of the LoongArch UAPI headers. Fixes: 803b0fc ("LoongArch: Add process management") Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Some processors have no IOCSR.VENDOR and IOCSR.CPUNAME, some processors have these registers but there is no valid information. Consolidate CPU names in /proc/cpuinfo: 1. Add "PRID" to display the PRID & Core-Name; 2. Let "Model Name" display "Unknown" if no valid name. Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
On physical machine, NUMA node id comes from high bit 44:48 of physical address. However it is not true on virt machine. With general method, it comes from ACPI SRAT table. Here the common function numa_memblks_init() is used to parse NUMA node information with numa_memblks. Cc: <stable@vger.kernel.org> Signed-off-by: Bibo Mao <maobibo@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
If the default state of the interrupt controllers in the first kernel don't mask any interrupts, it may cause the second kernel to potentially receive interrupts (which were previously allocated by the first kernel) immediately after a CPU becomes online during its boot process. These interrupts cannot be properly routed, leading to bad IRQ issues. This patch calls machine_kexec_mask_interrupts() to mask all interrupts during the kexec/kdump process. Signed-off-by: Tianyang Zhang <zhangtianyang@loongson.cn> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
If there is no valid cache info detected (may happen in virtual machine) for pci_dfl_cache_line_size, kernel shouldn't panic. Because in the PCI core it will be evaluated to (L1_CACHE_BYTES >> 2). Cc: <stable@vger.kernel.org> Signed-off-by: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
The current LoongArch BPF trampoline implementation is incompatible with tracing functions in kernel modules. This causes several severe and user-visible problems: * The `bpf_selftests/module_attach` test fails consistently. * Kernel lockup when a BPF program is attached to a module function [1]. * Critical kernel modules like WireGuard experience traffic disruption when their functions are traced with fentry [2]. Given the severity and the potential for other unknown side-effects, it is safest to disable the feature entirely for now. This patch prevents the BPF subsystem from allowing trampoline attachments to kernel module functions on LoongArch. This is a temporary mitigation until the core issues in the trampoline code for kernel module handling can be identified and fixed. [root@fedora bpf]# ./test_progs -a module_attach -v bpf_testmod.ko is already unloaded. Loading bpf_testmod.ko... Successfully loaded bpf_testmod.ko. test_module_attach:PASS:skel_open 0 nsec test_module_attach:PASS:set_attach_target 0 nsec test_module_attach:PASS:set_attach_target_explicit 0 nsec test_module_attach:PASS:skel_load 0 nsec libbpf: prog 'handle_fentry': failed to attach: -ENOTSUPP libbpf: prog 'handle_fentry': failed to auto-attach: -ENOTSUPP test_module_attach:FAIL:skel_attach skeleton attach failed: -524 Summary: 0/0 PASSED, 0 SKIPPED, 1 FAILED Successfully unloaded bpf_testmod.ko. [1]: https://lore.kernel.org/loongarch/CAK3+h2wDmpC-hP4u4pJY8T-yfKyk4yRzpu2LMO+C13FMT58oqQ@mail.gmail.com/ [2]: https://lore.kernel.org/loongarch/CAK3+h2wYcpc+OwdLDUBvg2rF9rvvyc5amfHT-KcFaK93uoELPg@mail.gmail.com/ Cc: stable@vger.kernel.org Fixes: f9b6b41 ("LoongArch: BPF: Add basic bpf trampoline support") Acked-by: Hengqi Chen <hengqi.chen@gmail.com> Signed-off-by: Vincent Li <vincent.mc.li@gmail.com> Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
Ping-Ke Shih says: ================== rtw patches for v6.18-rc7 Fix firmware goes wrong and causes device unusable after scanning. This issue presents under certain regulatory domain reported from end users. ================== Link: https://patch.msgid.link/8217bee0-96c4-44c1-9593-2e9ca12eccc5@RTKEXHMBS03.realtek.com.tw Signed-off-by: Johannes Berg <johannes.berg@intel.com>
…rg/drm/misc/kernel into drm-fixes Short summary of fixes pull: bridge: - sil902x: Fix HDMI detection imagination: - Update documentation sti: - Fix leaks in probe vga_switcheroo: - Avoid race condition during fbcon initialization Signed-off-by: Dave Airlie <airlied@redhat.com> From: Thomas Zimmermann <tzimmermann@suse.de> Link: https://patch.msgid.link/20251127081007.GA13578@2a02-2454-fd5e-fd00-689d-32c0-780c-bb87.dyn6.pyur.net
…/drm/xe/kernel into drm-fixes Driver Changes: - Fix resource leak in xe_guc_ct_init_noalloc()'s error path (Shuicheng Lin) - Fix stack_depot usage without STACKDEPOT_ALWAYS_INIT (Lucas) - Fix overflow in conversion from clock tics to msec (Harish Chegondi) Signed-off-by: Dave Airlie <airlied@redhat.com> From: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://patch.msgid.link/7ejiqjgthpqybg5svmkind2pszk4fqadxuq7rngchaaw76iept@5pn6sngqj6lk
…m/kernel Pull drm fixes from Dave Airlie: "Last one for this round hopefully, mostly the usual suspects, xe/amdgpu, with some single fixes otherwise. There is one amdgpu HDMI blackscreen bug that came in late in the cycle, but it was bisected and the revert is in here. i915: - Reject async flips when PSR's selective fetch is enabled xe: - Fix resource leak in xe_guc_ct_init_noalloc()'s error path - Fix stack_depot usage without STACKDEPOT_ALWAYS_INIT - Fix overflow in conversion from clock tics to msec amdgpu: - Unified MES fix - HDMI fix - Cursor fix - Bightness fix - EDID reading improvement - UserQ fix - Cyan Skillfish IP discovery fix bridge: - sil902x: Fix HDMI detection imagination: - Update documentation sti: - Fix leaks in probe vga_switcheroo: - Avoid race condition during fbcon initialization" * tag 'drm-fixes-2025-11-28' of https://gitlab.freedesktop.org/drm/kernel: drm/amdgpu: fix cyan_skillfish2 gpu info fw handling drm/amdgpu: attach tlb fence to the PTs update drm/amd/display: Increase EDID read retries drm/amd/display: Don't change brightness for disabled connectors drm/amd/display: Check NULL before accessing Revert "drm/amd/display: Move setup_stream_attribute" drm/xe: Fix conversion from clock ticks to milliseconds drm/xe/guc: Fix stack_depot usage drm/xe/guc: Fix resource leak in xe_guc_ct_init_noalloc() drm/i915/psr: Reject async flips when selective fetch is enabled drm, fbcon, vga_switcheroo: Avoid race condition in fbcon setup drm/amd/amdgpu: reserve vm invalidation engine for uni_mes drm: sti: fix device leaks at component probe drm/imagination: Document pvr_device.power member drm/bridge: sii902x: Fix HDMI detection with DRM_BRIDGE_ATTACH_NO_CONNECTOR
As well as checking that the parent hasn't changed after getting the lock we need to check that the dentry hasn't been unhashed. Otherwise we might try to rename something that has been removed. Reported-by: syzbot+bfc9a0ccf0de47d04e8c@syzkaller.appspotmail.com Fixes: d2c9955 ("ovl: Call ovl_create_temp() without lock held.") Signed-off-by: NeilBrown <neil@brown.name> Link: https://patch.msgid.link/176429295510.634289.1552337113663461690@noble.neil.brown.name Tested-by: syzbot+bfc9a0ccf0de47d04e8c@syzkaller.appspotmail.com Reviewed-by: Amir Goldstein <amir73il@gmail.com> Signed-off-by: Christian Brauner <brauner@kernel.org>
The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. In the reported bug, this is triggered by afs_parse_source() parsing the device name given to mount() and calling afs_lookup_cell() with the name of the cell. The normal key lookup then tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set and so an oops can happen. This has been made more likely to happen by the fix for dynamic lookup failure. Fix this by firstly allocating a reference name and attaching it to the afs_cell record when the record is created. It can share the memory allocation with the cell name (unfortunately it can't just overlap the cell name by prepending it with "afs@" as the cell name already has a '.' prepended for other purposes). This reference name is then passed to request_key(). Secondly, the anon key is now allocated on demand at the point a key is requested in afs_request_key() if it is not already allocated. A mutex is used to prevent multiple allocation for a cell. Thirdly, make afs_request_key_rcu() return NULL if the anonymous key isn't yet allocated (if we need it) and then the caller can return -ECHILD to drop out of RCU-mode and afs_request_key() can be called. Note that the anonymous key is kind of necessary to make the key lookup cache work as that doesn't currently cache a negative lookup, but it's probably worth some investigation to see if NULL can be used instead. Fixes: 330e2c5 ("afs: Fix dynamic lookup to fail on cell lookup failure") Reported-by: syzbot+41c68824eefb67cdf00c@syzkaller.appspotmail.com Signed-off-by: David Howells <dhowells@redhat.com> Link: https://patch.msgid.link/800328.1764325145@warthog.procyon.org.uk cc: Marc Dionne <marc.dionne@auristor.com> cc: linux-afs@lists.infradead.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Christian Brauner <brauner@kernel.org>
…sive On TI K3 devices, the mailbox resides in the Always-On power domain (LPSC_main_alwayson) and is shared among multiple processors. The mailbox is not solely exclusive to Linux. Currently, the suspend path checks all FIFO queues for pending messages and blocks suspend if any are present. This behavior is unnecessary for K3 devices, since some of the FIFOs are used for RTOS<->RTOS communication and are independent of Linux. For FIFOs used in Linux<->RTOS communication, any pending message would trigger an interrupt, which naturally prevents suspend from completing. Hence, there is no need for the mailbox driver to explicitly check for pending messages on K3 platforms. Introduce a device match flag to indicate whether the mailbox instance is exclusive to Linux, and skip the pending message check for non-exclusive instances (such as in K3). Fixes: a49f991 ("arm64: dts: ti: k3-am62-verdin: Add missing cfg for TI IPC Firmware") Closes: https://lore.kernel.org/all/sid7gtg5vay5qgicsl6smnzwg5mnneoa35cempt5ddwjvedaio@hzsgcx6oo74l/ Signed-off-by: Beleswar Padhi <b-padhi@ti.com> Tested-by: Hiago De Franco <hiago.franco@toradex.com> Reviewed-by: Andrew Davis <afd@ti.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
The debugfs_create_dir() function returns ERR_PTR() on error, not NULL. The current null-check fails to catch errors. Use IS_ERR() to correctly check for errors. Fixes: 8ea4484 ("mailbox: Add generic mechanism for testing Mailbox Controllers") Signed-off-by: Haotian Zhang <vulab@iscas.ac.cn> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
GCE can only fetch the command buffer address from a 32-bit register. Some SoCs support a 35-bit command buffer address for GCE, which requires a right shift of 3 bits before setting the address into the 32-bit register. A comment has been added to the header of cmdq_get_shift_pa() to explain this requirement. To prevent the GCE command buffer address from being DMA mapped beyond its supported bit range, the DMA bit mask for the device is set during initialization. Additionally, to ensure the correct shift is applied when setting or reading the register that stores the GCE command buffer address, new APIs, cmdq_convert_gce_addr() and cmdq_revert_gce_addr(), have been introduced for consistent operations on this register. The variable type for the command buffer address has been standardized to dma_addr_t to prevent handling issues caused by type mismatches. Fixes: 0858fde ("mailbox: cmdq: variablize address shift in platform") Signed-off-by: Jason-JH Lin <jason-jh.lin@mediatek.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
mtk_gpueb_mbox_ops should be declared static. However, due to its const nature, this specifier was missed, as it compiled fine without it and with no warning by the compiler. arc-linux-gcc (GCC) 12.5.0 doesn't seem to like it however, so add the static to fix that. Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202510100629.3nGvrhEU-lkp@intel.com/ Fixes: dbca0ea ("mailbox: add MediaTek GPUEB IPI mailbox") Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
The error status mask for a type 3/4 subspace is used for reading the error status, and the bitwise inverse is used for clearing the error with the intent being to preserve any of the non-error bits. However, we were previously applying the mask to extract the status and then applying the inverse to the result which ended up clearing all bits. Instead, store the inverse mask in the preserve mask and then use that on the original value read from the error status so that only the error is cleared. Fixes: c45ded7 ("mailbox: pcc: Add support for PCCT extended PCC subspaces(type 3/4)") Signed-off-by: Jamie Iles <jamie.iles@oss.qualcomm.com> Signed-off-by: Punit Agrawal <punit.agrawal@oss.qualcomm.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
The purpose of the devm_add_action_or_reset() helper is to call the action function in case adding an action ever fails so drop the clock disable from the error path to avoid disabling the clocks twice. Fixes: 5d4d263 ("mailbox: Introduce support for T-head TH1520 Mailbox driver") Cc: Michal Wilczynski <m.wilczynski@samsung.com> Signed-off-by: Johan Hovold <johan@kernel.org> Reviewed-by: Michal Wilczynski <m.wilczynski@samsung.com> Signed-off-by: Jassi Brar <jassisinghbrar@gmail.com>
…kernel/git/ulfh/linux-pm Pull pmdomain fixes from Ulf Hansson: - mediatek: Fix spinlock recursion in probe - tegra: Use GENPD_FLAG_NO_STAY_ON to restore old behaviour * tag 'pmdomain-v6.18-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/linux-pm: pmdomain: tegra: Add GENPD_FLAG_NO_STAY_ON flag pmdomains: mtk-pm-domains: Fix spinlock recursion in probe
…nel/git/ulfh/mmc Pull MMC fix from Ulf Hansson: - sdhci-of-dwcmshc: Fix reset handling for some variants * tag 'mmc-v6.18-rc2-2' of git://git.kernel.org/pub/scm/linux/kernel/git/ulfh/mmc: mmc: sdhci-of-dwcmshc: Promote the th1520 reset handling to ip level
…/pub/scm/linux/kernel/git/khilman/linux-omap into arm/fixes MAINTAINERS: Add entry for TQ-Systems AM335 device trees * tag 'omap-for-v6.19/maintainers-signed' of git://git.kernel.org/pub/scm/linux/kernel/git/khilman/linux-omap: MAINTAINERS: Add entry for TQ-Systems AM335 device trees
…nux/kernel/git/sunxi/linux into arm/fixes Allwinner fixes for 6.18 Just one fix to correct the "thead,vlenb" property for the RISC-V based D1 SoC family. * tag 'sunxi-fixes-for-6.18' of https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux: riscv: dts: allwinner: d1: fix vlenb property
…inux/kernel/git/jassibrar/mailbox
Pull mailbox fixes from Jassi Brar:
- omap: check for pending msgs only when mbox is exclusive
- mailbox-test: debugfs_create_dir error checking
- mtk:
- cmdq: fix DMA address handling
- gpueb: Add missing 'static' to mailbox ops struct
- pcc: don't zero error register
- th1520: fix clock imbalance on probe failure
* tag 'mailbox-fixes-v6.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/jassibrar/mailbox:
mailbox: th1520: fix clock imbalance on probe failure
mailbox: pcc: don't zero error register
mailbox: mtk-gpueb: Add missing 'static' to mailbox ops struct
mailbox: mtk-cmdq: Refine DMA address handling for the command buffer
mailbox: mailbox-test: Fix debugfs_create_dir error checking
mailbox: omap-mailbox: Check for pending msgs only when mbox is exclusive
…/git/gregkh/usb Pull USB/Thunderbolt fixes from Greg KH: "Here are some last-minutes USB and Thunderbolt driver fixes and new device ids for 6.18-rc8. Included in here are: - usb storage quirk fixup - xhci driver fixes for reported issues - usb gadget driver fixes - dwc3 driver fixes - UAS driver fixup - thunderbolt new device ids - usb-serial driver new ids All of these have been in linux-next with no reported issues, many for many weeks" * tag 'usb-6.18-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (21 commits) usb: gadget: renesas_usbf: Handle devm_pm_runtime_enable() errors USB: storage: Remove subclass and protocol overrides from Novatek quirk usb: uas: fix urb unmapping issue when the uas device is remove during ongoing data transfer usb: dwc3: Fix race condition between concurrent dwc3_remove_requests() call paths xhci: dbgtty: fix device unregister usb: storage: sddr55: Reject out-of-bound new_pba USB: serial: option: add support for Rolling RW101R-GL usb: typec: ucsi: psy: Set max current to zero when disconnected usb: gadget: f_eem: Fix memory leak in eem_unwrap usb: dwc3: pci: Sort out the Intel device IDs usb: dwc3: pci: add support for the Intel Nova Lake -S drivers/usb/dwc3: fix PCI parent check usb: storage: Fix memory leak in USB bulk transport xhci: sideband: Fix race condition in sideband unregister xhci: dbgtty: Fix data corruption when transmitting data form DbC to host xhci: fix stale flag preventig URBs after link state error is cleared USB: serial: ftdi_sio: add support for u-blox EVK-M101 usb: cdns3: Fix double resource release in cdns3_pci_probe usb: gadget: udc: fix use-after-free in usb_gadget_state_work usb: renesas_usbhs: Fix synchronous external abort on unbind ...
…/git/gregkh/tty
Pull serial driver fixes from Greg KH:
"Here are two serial driver fixes for reported issues for 6.18-rc8.
These are:
- fix for a much reported symbol build loop that broke the build for
some kernel configurations
- amba-pl011 driver bugfix for a reported issue
Both have been in linux next (the last for weeks, the first for a
shorter amount of time), with no reported issues"
* tag 'tty-6.18-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty:
serial: 8250: Fix 8250_rsa symbol loop
serial: amba-pl011: prefer dma_mapping_error() over explicit address checking
…kernel/git/gregkh/char-misc Pull char / misc / IIO fixes from Greg KH: "Here are some much-delayed char/misc/iio driver fixes for 6.18-rc8. Fixes in here include: - lots of iio driver bugfixes for reported issues. - counter driver bugfix - slimbus driver bugfix - mei tiny bugfix - nvmem layout uevent bugfix All of these have been in linux-next for a while, but due to travel on my side, I haven't had a chance to get them to you" * tag 'char-misc-6.18-rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/char-misc: (23 commits) nvmem: layouts: fix nvmem_layout_bus_uevent iio: accel: bmc150: Fix irq assumption regression most: usb: fix double free on late probe failure slimbus: ngd: Fix reference count leak in qcom_slim_ngd_notify_slaves firmware: stratix10-svc: fix bug in saving controller data mei: fix error flow in probe iio: st_lsm6dsx: Fixed calibrated timestamp calculation iio: humditiy: hdc3020: fix units for thresholds and hysteresis iio: humditiy: hdc3020: fix units for temperature and humidity measurement iio: imu: st_lsm6dsx: fix array size for st_lsm6dsx_settings fields iio: accel: fix ADXL355 startup race condition iio: adc: ad7124: fix temperature channel iio:common:ssp_sensors: Fix an error handling path ssp_probe() iio: adc: ad7280a: fix ad7280_store_balance_timer() iio: buffer-dmaengine: enable .get_dma_dev() iio: buffer-dma: support getting the DMA channel iio: buffer: support getting dma channel from the buffer iio: pressure: bmp280: correct meas_time_us calculation iio: adc: stm32-dfsdm: fix st,adc-alt-channel property handling iio: adc: ad7380: fix SPI offload trigger rate ...
…rnel/git/soc/soc
Pull SoC fixes from Arnd Bergmann:
"A few last minute fixes came in this week:
- interrupt and gpio numbers in foud separate i.MX8 specific
devicetree files were wrong
- The vector length property in the C906 CPU description used the
wrong unit
- Two bugs with uninitialized stack variables in the tee subsystem
- Alexander Stein now maintains additional devicetree files"
* tag 'soc-fixes-6.18-4' of git://git.kernel.org/pub/scm/linux/kernel/git/soc/soc:
riscv: dts: allwinner: d1: fix vlenb property
MAINTAINERS: Add entry for TQ-Systems AM335 device trees
tee: qcomtee: initialize result before use in release worker
arm64: dts: imx8qm-mek: fix mux-controller select/enable-gpios polarity
tee: qcomtee: fix uninitialized pointers with free attribute
ARM: dts: nxp: imx6ul: correct SAI3 interrupt line
arm64: dts: imx8dxl-ss-conn: swap interrupts number of eqos
arm64: dts: imx8dxl: Correct pcie-ep interrupt number
…kernel/git/vfs/vfs Pull vfs fixes from Christian Brauner: - afs: Fix delayed allocation of a cell's anonymous key The allocation of a cell's anonymous key is done in a background thread along with other cell setup such as doing a DNS upcall. The normal key lookup tries to use the key description on the anonymous authentication key as the reference for request_key() - but it may not yet be set, causing an oops - ovl: fail ovl_lock_rename_workdir() if either target is unhashed As well as checking that the parent hasn't changed after getting the lock, the code needs to check that the dentry hasn't been unhashed. Otherwise overlayfs might try to rename something that has been removed - namespace: fix a reference leak in grab_requested_mnt_ns lookup_mnt_ns() already takes a reference on mnt_ns, and so grab_requested_mnt_ns() doesn't need to take an extra reference * tag 'vfs-6.18-rc8.fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/vfs/vfs: afs: Fix delayed allocation of a cell's anonymous key ovl: fail ovl_lock_rename_workdir() if either target is unhashed fs/namespace: fix reference leak in grab_requested_mnt_ns
…nux/kernel/git/axboe/linux Pull io_uring fixes from Jens Axboe: - Ensure that vectored registered buffer imports ties the lifetime of those to the zero-copy send notification, not the parent request - Fix a bug introduced in this merge window, with the introduction of mixed sized CQE support * tag 'io_uring-6.18-20251128' of git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux: io_uring: fix mixed cqe overflow handling io_uring/net: ensure vectored buffer node import is tied to notification
…inux/kernel/git/broonie/regulator Pull regulator fixes from Mark Brown: "A couple of fixes for incorrect device descriptions in the rtq2208 driver" * tag 'regulator-fix-v6.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator: regulator: rtq2208: Correct LDO2 logic judgment bits regulator: rtq2208: Correct buck group2 phase mapping logic
…ernel/git/broonie/spi Pull spi fixes from Mark Brown: "A disappointingly large set of device specific fixes that have built up since I've been a bit tardy with sending a pull requests as people kept sending me new new fixes. The bcm63xx and lpspi issues could lead to corruption so the fixes are fairly important for the affected parts, the other issues should all be relatively minor" * tag 'spi-fix-v6.18-rc7' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi: spi: nxp-fspi: Propagate fwnode in ACPI case as well spi: tegra114: remove Kconfig dependency on TEGRA20_APB_DMA spi: amlogic-spifc-a1: Handle devm_pm_runtime_enable() errors spi: spi-fsl-lpspi: fix watermark truncation caused by type cast spi: cadence-quadspi: Fix cqspi_probe() error handling for runtime pm spi: bcm63xx: fix premature CS deassertion on RX-only transactions spi: spi-cadence-quadspi: Remove duplicate pm_runtime_put_autosuspend() call spi: spi-cadence-quadspi: Enable pm runtime earlier to avoid imbalance
Fix an uninitialised variable (key) in afs_alloc_anon_key() by setting it to cell->anonymous_key. Without this change, the error check may return a false failure with a bad error number. Most of the time this is unlikely to happen because the first encounter with afs_alloc_anon_key() will usually be from (auto)mount, for which all subsequent operations must wait - apart from other (auto)mounts. Once the call->anonymous_key is allocated, all further calls to afs_request_key() will skip the call to afs_alloc_anon_key() for that cell. Fixes: d27c712 ("afs: Fix delayed allocation of a cell's anonymous key") Reported-by: Paulo Alcantra <pc@manguebit.org> Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: Paulo Alcantara <pc@manguebit.org> cc: Marc Dionne <marc.dionne@auristor.com> cc: syzbot+41c68824eefb67cdf00c@syzkaller.appspotmail.com cc: linux-afs@lists.infradead.org cc: linux-fsdevel@vger.kernel.org Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Owing to Config4.MMUSizeExt and VTLB/FTLB MMU features later MIPSr2+ cores can have more than 64 TLB entries. Therefore allocate an array for uniquification instead of placing too an small array on the stack. Fixes: 35ad7e1 ("MIPS: mm: tlb-r4k: Uniquify TLB entries on init") Co-developed-by: Maciej W. Rozycki <macro@orcam.me.uk> Signed-off-by: Maciej W. Rozycki <macro@orcam.me.uk> Cc: stable@vger.kernel.org # v6.17+: 9f048fa: MIPS: mm: Prevent a TLB shutdown on initial uniquification Cc: stable@vger.kernel.org # v6.17+ Tested-by: Gregory CLEMENT <gregory.clement@bootlin.com> Tested-by: Klara Modin <klarasmodin@gmail.com> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
…ernel/git/mips/linux Pull MIPS fix from Thomas Bogendoerfer: "Fix TLB unification for cores with more than 64 TLB entries" * tag 'mips-fixes_6.18_2' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux: MIPS: mm: kmalloc tlb_vpn array to avoid stack overflow
…cm/linux/kernel/git/tip/tip Pull timer fix from Borislav Petkov: - Have timekeeping aux clocks sysfs interface setup function return an error code on failure instead of success * tag 'timers_urgent_for_v6.18_rc8' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: timekeeping: Fix error code in tk_aux_sysfs_init()
|
I don't think you need to have a pull request to rebase the topic branch, you can just do it directly. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Rebase gadget branch to tip