summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2025-09-22rust: add dynamic ID pool abstraction for bitmapBurak Emir
This is a port of the Binder data structure introduced in commit 15d9da3f818c ("binder: use bitmap for faster descriptor lookup") to Rust. Like drivers/android/dbitmap.h, the ID pool abstraction lets clients acquire and release IDs. The implementation uses a bitmap to know what IDs are in use, and gives clients fine-grained control over the time of allocation. This fine-grained control is needed in the Android Binder. We provide an example that release a spinlock for allocation and unit tests (rustdoc examples). The implementation does not permit shrinking below capacity below BITS_PER_LONG. Suggested-by: Alice Ryhl <aliceryhl@google.com> Suggested-by: Yury Norov <yury.norov@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Burak Emir <bqe@google.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-09-22rust: add find_bit_benchmark_rust module.Burak Emir
Microbenchmark protected by a config FIND_BIT_BENCHMARK_RUST, following `find_bit_benchmark.c` but testing the Rust Bitmap API. We add a fill_random() method protected by the config in order to maintain the abstraction. The sample output from the benchmark, both C and Rust version: find_bit_benchmark.c output: ``` Start testing find_bit() with random-filled bitmap [ 438.101937] find_next_bit: 860188 ns, 163419 iterations [ 438.109471] find_next_zero_bit: 912342 ns, 164262 iterations [ 438.116820] find_last_bit: 726003 ns, 163419 iterations [ 438.130509] find_nth_bit: 7056993 ns, 16269 iterations [ 438.139099] find_first_bit: 1963272 ns, 16270 iterations [ 438.173043] find_first_and_bit: 27314224 ns, 32654 iterations [ 438.180065] find_next_and_bit: 398752 ns, 73705 iterations [ 438.186689] Start testing find_bit() with sparse bitmap [ 438.193375] find_next_bit: 9675 ns, 656 iterations [ 438.201765] find_next_zero_bit: 1766136 ns, 327025 iterations [ 438.208429] find_last_bit: 9017 ns, 656 iterations [ 438.217816] find_nth_bit: 2749742 ns, 655 iterations [ 438.225168] find_first_bit: 721799 ns, 656 iterations [ 438.231797] find_first_and_bit: 2819 ns, 1 iterations [ 438.238441] find_next_and_bit: 3159 ns, 1 iterations ``` find_bit_benchmark_rust.rs output: ``` [ 451.182459] find_bit_benchmark_rust: [ 451.186688] Start testing find_bit() Rust with random-filled bitmap [ 451.194450] next_bit: 777950 ns, 163644 iterations [ 451.201997] next_zero_bit: 918889 ns, 164036 iterations [ 451.208642] Start testing find_bit() Rust with sparse bitmap [ 451.214300] next_bit: 9181 ns, 654 iterations [ 451.222806] next_zero_bit: 1855504 ns, 327026 iterations ``` Here are the results from 32 samples, with 95% confidence interval. The microbenchmark was built with RUST_BITMAP_HARDENED=n and run on a machine that did not execute other processes. Random-filled bitmap: +-----------+-------+-----------+--------------+-----------+-----------+ | Benchmark | Lang | Mean (ms) | Std Dev (ms) | 95% CI Lo | 95% CI Hi | +-----------+-------+-----------+--------------+-----------+-----------+ | find_bit/ | C | 825.07 | 53.89 | 806.40 | 843.74 | | next_bit | Rust | 870.91 | 46.29 | 854.88 | 886.95 | +-----------+-------+-----------+--------------+-----------+-----------+ | find_zero/| C | 933.56 | 56.34 | 914.04 | 953.08 | | next_zero | Rust | 945.85 | 60.44 | 924.91 | 966.79 | +-----------+-------+-----------+--------------+-----------+-----------+ Rust appears 5.5% slower for next_bit, 1.3% slower for next_zero. Sparse bitmap: +-----------+-------+-----------+--------------+-----------+-----------+ | Benchmark | Lang | Mean (ms) | Std Dev (ms) | 95% CI Lo | 95% CI Hi | +-----------+-------+-----------+--------------+-----------+-----------+ | find_bit/ | C | 13.17 | 6.21 | 11.01 | 15.32 | | next_bit | Rust | 14.30 | 8.27 | 11.43 | 17.17 | +-----------+-------+-----------+--------------+-----------+-----------+ | find_zero/| C | 1859.31 | 82.30 | 1830.80 | 1887.83 | | next_zero | Rust | 1908.09 | 139.82 | 1859.65 | 1956.54 | +-----------+-------+-----------+--------------+-----------+-----------+ Rust appears 8.5% slower for next_bit, 2.6% slower for next_zero. In summary, taking the arithmetic mean of all slow-downs, we can say the Rust API has a 4.5% slowdown. Suggested-by: Alice Ryhl <aliceryhl@google.com> Suggested-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> Reviewed-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Burak Emir <bqe@google.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-09-22rust: add bitmap API.Burak Emir
Provides an abstraction for C bitmap API and bitops operations. This commit enables a Rust implementation of an Android Binder data structure from commit 15d9da3f818c ("binder: use bitmap for faster descriptor lookup"), which can be found in drivers/android/dbitmap.h. It is a step towards upstreaming the Rust port of Android Binder driver. We follow the C Bitmap API closely in naming and semantics, with a few differences that take advantage of Rust language facilities and idioms. The main types are `BitmapVec` for owned bitmaps and `Bitmap` for references to C bitmaps. * We leverage Rust type system guarantees as follows: * all (non-atomic) mutating operations require a &mut reference which amounts to exclusive access. * the `BitmapVec` type implements Send. This enables transferring ownership between threads and is needed for Binder. * the `BitmapVec` type implements Sync, which enables passing shared references &Bitmap between threads. Atomic operations can be used to safely modify from multiple threads (interior mutability), though without ordering guarantees. * The Rust API uses `{set,clear}_bit` vs `{set,clear}_bit_atomic` as names for clarity, which differs from the C naming convention `set_bit` for atomic vs `__set_bit` for non-atomic. * we include enough operations for the API to be useful. Not all operations are exposed yet in order to avoid dead code. The missing ones can be added later. * We take a fine-grained approach to safety: * Low-level bit-ops get a safe API with bounds checks. Calling with an out-of-bounds arguments to {set,clear}_bit becomes a no-op and get logged as errors. * We also introduce a RUST_BITMAP_HARDENED config, which causes invocations with out-of-bounds arguments to panic. * methods correspond to find_* C methods tolerate out-of-bounds since the C implementation does. Also here, out-of-bounds arguments are logged as errors, or panic in RUST_BITMAP_HARDENED mode. * We add a way to "borrow" bitmaps from C in Rust, to make C bitmaps that were allocated in C directly usable in Rust code (`Bitmap`). * the Rust API is optimized to represent the bitmap inline if it would fit into a pointer. This saves allocations which is relevant in the Binder use case. The underlying C bitmap is *not* exposed for raw access in Rust. Doing so would permit bypassing the Rust API and lose static guarantees. An alternative route of vendoring an existing Rust bitmap package was considered but suboptimal overall. Reusing the C implementation is preferable for a basic data structure like bitmaps. It enables Rust code to be a lot more similar and predictable with respect to C code that uses the same data structures and enables the use of code that has been tried-and-tested in the kernel, with the same performance characteristics whenever possible. We use the `usize` type for sizes and indices into the bitmap, because Rust generally always uses that type for indices and lengths and it will be more convenient if the API accepts that type. This means that we need to perform some casts to/from u32 and usize, since the C headers use unsigned int instead of size_t/unsigned long for these numbers in some places. Adds new MAINTAINERS section BITMAP API [RUST]. Suggested-by: Alice Ryhl <aliceryhl@google.com> Suggested-by: Yury Norov <yury.norov@gmail.com> Signed-off-by: Burak Emir <bqe@google.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-09-22rust: add bindings for bitops.hBurak Emir
Makes atomic set_bit and clear_bit inline functions as well as the non-atomic variants __set_bit and __clear_bit available to Rust. Adds a new MAINTAINERS section BITOPS API BINDINGS [RUST]. Suggested-by: Alice Ryhl <aliceryhl@google.com> Suggested-by: Yury Norov <yury.norov@gmail.com> Signed-off-by: Burak Emir <bqe@google.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-09-22rust: add bindings for bitmap.hBurak Emir
Makes the bitmap_copy_and_extend inline function available to Rust. Adds F: to existing MAINTAINERS section BITMAP API BINDINGS [RUST]. - Suggested-by: Alice Ryhl <aliceryhl@google.com> Suggested-by: Yury Norov <yury.norov@gmail.com> Signed-off-by: Burak Emir <bqe@google.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Yury Norov (NVIDIA) <yury.norov@gmail.com> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-09-22phy: rockchip-pcie: switch to FIELD_PREP_WM16 macroNicolas Frattaroli
The era of hand-rolled HIWORD_UPDATE macros is over, at least for those drivers that use constant masks. The Rockchip PCIe PHY driver, used on the RK3399, has its own definition of HIWORD_UPDATE. Remove it, and replace instances of it with hw_bitfield.h's FIELD_PREP_WM16. To achieve this, some mask defines are reshuffled, as FIELD_PREP_WM16 uses the mask as both the mask of bits to write and to derive the shift amount from in order to shift the value. In order to ensure that the mask is always a constant, the inst->index shift is performed after the FIELD_PREP_WM16, as this is a runtime value. >From this, we gain compile-time error checking, and in my humble opinion nicer code, as well as a single definition of this macro across the entire codebase to aid in code comprehension. Tested on a RK3399 ROCKPro64, where PCIe still works as expected when accessing an NVMe drive. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-09-22clk: sp7021: switch to FIELD_PREP_WM16 macroNicolas Frattaroli
The sp7021 clock driver has its own shifted high word mask macro, similar to the ones many Rockchip drivers have. Remove it, and replace instances of it with hw_bitfield.h's FIELD_PREP_WM16 macro, which does the same thing except in a common macro that also does compile-time error checking. This was compile-tested with 32-bit ARM with Clang, no runtime tests were performed as I lack the hardware. However, I verified that fix commit 5c667d5a5a3e ("clk: sp7021: Adjust width of _m in HWM_FIELD_PREP()") is not regressed. No warning is produced. Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com> Reviewed-by: Heiko Stuebner <heiko@sntech.de> Acked-by: Stephen Boyd <sboyd@kernel.org> Signed-off-by: Yury Norov (NVIDIA) <yury.norov@gmail.com>
2025-09-22soc/fsl/qbman: Use for_each_online_cpu() instead of for_each_cpu()Fushuai Wang
Replace the opencoded for_each_cpu(cpu, cpu_online_mask) loop with the more readable and equivalent for_each_online_cpu(cpu) macro. Signed-off-by: Fushuai Wang <wangfushuai@baidu.com> Link: https://lore.kernel.org/r/20250811065216.3320-1-wangfushuai@baidu.com Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
2025-09-22Merge tag 'for-net-2025-09-22' of ↵Jakub Kicinski
git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth Luiz Augusto von Dentz says: ==================== bluetooth pull request for net: - Fix build after header cleanup - hci_sync: Fix hci_resume_advertising_sync - hci_event: Fix UAF in hci_conn_tx_dequeue - hci_event: Fix UAF in hci_acl_create_conn_sync - MGMT: Fix possible UAFs * tag 'for-net-2025-09-22' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth: Bluetooth: MGMT: Fix possible UAFs Bluetooth: hci_event: Fix UAF in hci_acl_create_conn_sync Bluetooth: hci_event: Fix UAF in hci_conn_tx_dequeue Bluetooth: hci_sync: Fix hci_resume_advertising_sync Bluetooth: Fix build after header cleanup ==================== Link: https://patch.msgid.link/20250922143315.3007176-1-luiz.dentz@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22x86/topology: Implement topology_is_core_online() to address SMT regressionThomas Gleixner
Christian reported that commit a430c11f4015 ("intel_idle: Rescan "dead" SMT siblings during initialization") broke the use case in which both 'nosmt' and 'maxcpus' are on the kernel command line because it onlines primary threads, which were offline due to the maxcpus limit. The initially proposed fix to skip primary threads in the loop is inconsistent. While it prevents the primary thread to be onlined, it then onlines the corresponding hyperthread(s), which does not really make sense. The CPU iterator in cpuhp_smt_enable() contains a check which excludes all threads of a core, when the primary thread is offline. The default implementation is a NOOP and therefore not effective on x86. Implement topology_is_core_online() on x86 to address this issue. This makes the behaviour consistent between x86 and PowerPC. Fixes: a430c11f4015 ("intel_idle: Rescan "dead" SMT siblings during initialization") Fixes: f694481b1d31 ("ACPI: processor: Rescan "dead" SMT siblings during initialization") Closes: https://lore.kernel.org/linux-pm/724616a2-6374-4ba3-8ce3-ea9c45e2ae3b@arm.com/ Reported-by: Christian Loehle <christian.loehle@arm.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de> Reviewed-by: Rafael J. Wysocki (Intel) <rafael@kernel.org> Tested-by: Christian Loehle <christian.loehle@arm.com> Cc: stable@vger.kernel.org Link: https://lore.kernel.org/12740505.O9o76ZdvQC@rafael.j.wysocki
2025-09-22rust: macros: reduce collections in `quote!` macroTamir Duberstein
Remove a handful of unnecessary intermediate vectors and token streams; mainly the top-level stream can be directly extended with the notable exception of groups. Remove an unnecessary `#[allow(dead_code)]` added in commit dbd5058ba60c ("rust: make pin-init its own crate"). Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Acked-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Tamir Duberstein <tamird@gmail.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2025-09-22Merge branch 'mptcp-pm-netlink-announce-server-side-flag'Jakub Kicinski
Matthieu Baerts says: ==================== mptcp: pm: netlink: announce server-side flag Now that the 'flags' attribute is used, it seems interesting to add one flag for 'server-side', a boolean value. Here are a few patches related to the 'server-side' attribute: - Patch 1: only announce this attribute on the server side. - Patch 2: announce the 'server-side' flag when this is the case. - Patch 3: deprecate the 'server-side' attribute. - Patch 4: use the 'server-side' flag in the selftests. - Patches 5, 6: small cleanups when working on code around. ==================== Link: https://patch.msgid.link/20250919-net-next-mptcp-server-side-flag-v1-0-a97a5d561a8b@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22mptcp: remove unused returned value of check_data_finMatthieu Baerts (NGI0)
When working on a fix modifying mptcp_check_data_fin(), I noticed the returned value was no longer used. It looks like it was used for 3 days, between commit 7ed90803a213 ("mptcp: send explicit ack on delayed ack_seq incr") and commit ea4ca586b16f ("mptcp: refine MPTCP-level ack scheduling"). This returned value can be safely removed. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250919-net-next-mptcp-server-side-flag-v1-6-a97a5d561a8b@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22mptcp: use _BITUL() instead of (1 << x)Matthieu Baerts (NGI0)
Simply to use the proper way to declare bits, and to align with all other flags declared in this file. No functional changes intended. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250919-net-next-mptcp-server-side-flag-v1-5-a97a5d561a8b@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22selftests: mptcp: pm: get server-side flagMatthieu Baerts (NGI0)
server-side info linked to the MPTCP connect/established events can now come from the flags, in addition to the dedicated attribute. The attribute is now deprecated -- in favour of the new flag, and will be removed later on. Print this info only once. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250919-net-next-mptcp-server-side-flag-v1-4-a97a5d561a8b@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22mptcp: pm: netlink: deprecate server-side attributeMatthieu Baerts (NGI0)
Now that such info is in the 'flags' attribute, it is time to deprecate the dedicated 'server-side' attribute. It will be removed in a few versions. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250919-net-next-mptcp-server-side-flag-v1-3-a97a5d561a8b@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22mptcp: pm: netlink: announce server-side flagMatthieu Baerts (NGI0)
Now that the 'flags' attribute is used, it seems interesting to add one flag for 'server-side', a boolean value. This is duplicating the info from the dedicated 'server-side' attribute, but it will be deprecated in the next commit, and removed in a few versions. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250919-net-next-mptcp-server-side-flag-v1-2-a97a5d561a8b@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22mptcp: pm: netlink: only add server-side attr when trueMatthieu Baerts (NGI0)
This attribute is a boolean. No need to add it to set it to 'false'. Indeed, the default value when this attribute is not set is naturally 'false'. A few bytes can then be saved by not adding this attribute if the connection is not on the server side. This prepares the future deprecation of its attribute, in favour of a new flag. Reviewed-by: Geliang Tang <geliang@kernel.org> Signed-off-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Link: https://patch.msgid.link/20250919-net-next-mptcp-server-side-flag-v1-1-a97a5d561a8b@kernel.org Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22net: spacemit: Make stats_lock softirq-safeVivian Wang
While most of the statistics functions (emac_get_stats64() and such) are called with softirqs enabled, emac_stats_timer() is, as its name suggests, also called from a timer, i.e. called in softirq context. All of these take stats_lock. Therefore, make stats_lock softirq-safe by changing spin_lock() into spin_lock_bh() for the functions that get statistics. Also, instead of directly calling emac_stats_timer() in emac_up() and emac_resume(), set the timer to trigger instead, so that emac_stats_timer() is only called from the timer. It will keep using spin_lock(). This fixes a lockdep warning, and potential deadlock when stats_timer is triggered in the middle of getting statistics. Fixes: bfec6d7f2001 ("net: spacemit: Add K1 Ethernet MAC") Reported-by: Marek Szyprowski <m.szyprowski@samsung.com> Closes: https://lore.kernel.org/all/a52c0cf5-0444-41aa-b061-a0a1d72b02fe@samsung.com/ Signed-off-by: Vivian Wang <wangruikang@iscas.ac.cn> Tested-by: Marek Szyprowski <m.szyprowski@samsung.com> Link: https://patch.msgid.link/20250919-k1-ethernet-fix-lock-v1-1-c8b700aa4954@iscas.ac.cn Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22Merge branch 'net-enetc-improve-the-interface-for-obtaining-phc_index'Jakub Kicinski
Wei Fang says: ==================== net: enetc: improve the interface for obtaining phc_index The first patch is to fix the issue that a sleeping function is called in the context of rcu_read_lock(). The second patch is to use the generic API instead of the custom API to get phc_index. In addition, the second patch depends on the first patch to work. v1: https://lore.kernel.org/20250918074454.1742328-1-wei.fang@nxp.com ==================== Link: https://patch.msgid.link/20250919084509.1846513-1-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22net: enetc: use generic interfaces to get phc_index for ENETC v1Wei Fang
The commit 61f132ca8c46 ("ptp: add helpers to get the phc_index by of_node or dev") has added two generic interfaces to get the phc_index of the PTP clock. This eliminates the need for PTP device drivers to provide custom APIs for consumers to retrieve the phc_index. This has already been implemented for ENETC v4 and is also applicable to ENETC v1. Therefore, the global variable enetc_phc_index is removed from the driver. ENETC v1 now uses the same interface as v4 to get phc_index. Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250919084509.1846513-3-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22net: enetc: fix sleeping function called from rcu_read_lock() contextWei Fang
The rcu_read_lock() has been introduced in __ethtool_get_ts_info() since the commit 4c61d809cf60 ("net: ethtool: Fix suspicious rcu_dereference usage"). Therefore, the device drivers cannot use any sleeping functions when implementing the callback of ethtool_ops::get_ts_info(). Currently, pci_get_slot() is used in enetc_get_ts_info(), but it calls down_read() which might sleep, so this is a potential issue. Therefore, to fix this issue, pci_get_domain_bus_and_slot() is used to replace pci_get_slot() in enetc_get_ts_info(). Reported-by: Vladimir Oltean <vladimir.oltean@nxp.com> Closes: https://lore.kernel.org/netdev/20250918124823.t3xlzn7w2glzkhnx@skbuf/ Fixes: f5b9a1cde0a2 ("net: enetc: add PTP synchronization support for ENETC v4") Signed-off-by: Wei Fang <wei.fang@nxp.com> Reviewed-by: Vladimir Oltean <vladimir.oltean@nxp.com> Tested-by: Vladimir Oltean <vladimir.oltean@nxp.com> Link: https://patch.msgid.link/20250919084509.1846513-2-wei.fang@nxp.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22Merge branch 'tcp-clean-up-inet_hash-and-inet_unhash'Jakub Kicinski
Kuniyuki Iwashima says: ==================== tcp: Clean up inet_hash() and inet_unhash(). While reviewing the ehash fix series from Xuanqiang Luo [0], I noticed that inet_twsk_hashdance_schedule() checks the retval of __sk_nulls_del_node_init_rcu(), which looks confusing. The test exists from the pre-git era: $ git blame -L:tcp_tw_hashdance net/ipv4/tcp_minisocks.c e48c414ee61f4~ Patch 3 is to clarify that the retval check is unnecessary in inet_twsk_hashdance_schedule(), but I'll delegate its removal to the Xuanqiang's series. Patch 1 & 2 are minor cleanups. [0]: https://lore.kernel.org/netdev/20250916103054.719584-4-xuanqiang.luo@linux.dev/ ==================== Link: https://patch.msgid.link/20250919083706.1863217-1-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22tcp: Remove redundant sk_unhashed() in inet_unhash().Kuniyuki Iwashima
inet_unhash() checks sk_unhashed() twice at the entry and after locking ehash/lhash bucket. The former was somehow added redundantly by commit 4f9bf2a2f5aa ("tcp: Don't acquire inet_listen_hashbucket::lock with disabled BH."). inet_unhash() is called for the full socket from 4 places, and it is always under lock_sock() or the socket is not yet published to other threads: 1. __sk_prot_rehash() -> called from inet_sk_reselect_saddr(), which has lockdep_sock_is_held() 2. sk_common_release() -> called when inet_create() or inet6_create() fail, then the socket is not yet published 3. tcp_set_state() -> calls tcp_call_bpf_2arg(), and tcp_call_bpf() has sock_owned_by_me() 4. inet_ctl_sock_create() -> creates a kernel socket and unhashes it immediately, but TCP socket is not hashed in sock_create_kern() (only SOCK_RAW is) So we do not need to check sk_unhashed() twice before/after ehash/lhash lock in inet_unhash(). Let's remove the 2nd one. Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250919083706.1863217-4-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22tcp: Remove inet6_hash().Kuniyuki Iwashima
inet_hash() and inet6_hash() are exactly the same. Also, we do not need to export inet6_hash(). Let's consolidate the two into __inet_hash() and rename it to inet_hash(). Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250919083706.1863217-3-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22tcp: Remove osk from __inet_hash() arg.Kuniyuki Iwashima
__inet_hash() is called from inet_hash() and inet6_hash with osk NULL. Let's remove the 2nd arg from __inet_hash(). Signed-off-by: Kuniyuki Iwashima <kuniyu@google.com> Reviewed-by: Eric Dumazet <edumazet@google.com> Link: https://patch.msgid.link/20250919083706.1863217-2-kuniyu@google.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22selftests: forwarding: Reorder (ar)ping arguments to obey POSIX getoptDavid Yang
Quoted from musl wiki: GNU getopt permutes argv to pull options to the front, ahead of non-option arguments. musl and the POSIX standard getopt stop processing options at the first non-option argument with no permutation. Thus these scripts stop working on musl since non-option arguments for tools using getopt() (in this case, (ar)ping) do not always come last. Fix it by reordering arguments. Signed-off-by: David Yang <mmyangfl@gmail.com> Reviewed-by: Petr Machata <petrm@nvidia.com> Reviewed-by: Ido Schimmel <idosch@nvidia.com> Link: https://patch.msgid.link/20250919053538.1106753-1-mmyangfl@gmail.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22Merge branch 'broadcom-report-the-supported-flags-for-ancillary-features'Jakub Kicinski
Jacob Keller says: ==================== broadcom: report the supported flags for ancillary features James Clark reported off list that the broadcom PHY PTP driver was incorrectly handling PTP_EXTTS_REQUEST and PTP_PEROUT_REQUEST ioctls since the conversion to the .supported_*_flags fields. This series fixes the driver to correctly report its flags through the .supported_perout_flags and .supported_extts_flags fields. It also contains an update to comment the behavior of the PTP_STRICT_FLAGS being always enabled for PTP_EXTTS_REQUEST2. I plan to follow up this series with some improvements to the PTP documentation better explaining each flag and the expectation of the driver APIs. ==================== Link: https://patch.msgid.link/20250918-jk-fix-bcm-phy-supported-flags-v1-0-747b60407c9c@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22ptp: document behavior of PTP_STRICT_FLAGSJacob Keller
Commit 6138e687c7b6 ("ptp: Introduce strict checking of external time stamp options.") added the PTP_STRICT_FLAGS to the set of flags supported for the external timestamp request ioctl. It is only supported by PTP_EXTTS_REQUEST2, as it was introduced the introduction of the new ioctls. Further, the kernel has always set this flag for PTP_EXTTS_REQUEST2 regardless of whether or not the user requested the behavior. This effectively means that the flag is not useful for userspace. If the user issues a PTP_EXTTS_REQUEST ioctl, the flag is ignored due to not being supported on the old ioctl. If the user issues a PTP_EXTTS_REQUEST2 ioctl, the flag will be set by the kernel regardless of whether the user set the flag in their structure. Add a comment documenting this behavior in the uAPI header file. Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Acked-by: Richard Cochran <richardcochran@gmail.com> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Tested-by: James Clark <jjc@jclark.com> Link: https://patch.msgid.link/20250918-jk-fix-bcm-phy-supported-flags-v1-3-747b60407c9c@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22broadcom: fix support for PTP_EXTTS_REQUEST2 ioctlJacob Keller
Commit 7c571ac57d9d ("net: ptp: introduce .supported_extts_flags to ptp_clock_info") modified the PTP core kernel logic to validate the supported flags for the PTP_EXTTS_REQUEST ioctls, rather than relying on each individual driver correctly checking its flags. The bcm_ptp_enable() function implements support for PTP_CLK_REQ_EXTTS, but does not check the flags, and does not forward the request structure into bcm_ptp_extts_locked(). When originally converting the bcm-phy-ptp.c code, it was unclear what edges the hardware actually timestamped. Thus, no flags were initialized in the .supported_extts_flags field. This results in the kernel automatically rejecting all userspace requests for the PTP_EXTTS_REQUEST2 ioctl. This occurs because the PTP_STRICT_FLAGS is always assumed when operating under PTP_EXTTS_REQUEST2. This has been the case since the flags introduction by commit 6138e687c7b6 ("ptp: Introduce strict checking of external time stamp options."). The bcm-phy-ptp.c logic never properly supported strict flag validation, as it previously ignored all flags including both PTP_STRICT_FLAGS and the PTP_FALLING_EDGE and PTP_RISING_EDGE flags. Reports from users in the field prove that the hardware timestamps the rising edge. Encode this in the .supported_extts_flags field. This re-enables support for the PTP_EXTTS_REQUEST2 ioctl. Reported-by: James Clark <jjc@jclark.com> Fixes: 7c571ac57d9d ("net: ptp: introduce .supported_extts_flags to ptp_clock_info") Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Acked-by: Richard Cochran <richardcochran@gmail.com> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Tested-by: James Clark <jjc@jclark.com> Link: https://patch.msgid.link/20250918-jk-fix-bcm-phy-supported-flags-v1-2-747b60407c9c@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22broadcom: fix support for PTP_PEROUT_DUTY_CYCLEJacob Keller
The bcm_ptp_perout_locked() function has support for handling PTP_PEROUT_DUTY_CYCLE, but its not listed in the supported_perout_flags. Attempts to use the duty cycle support will be rejected since commit d9f3e9ecc456 ("net: ptp: introduce .supported_perout_flags to ptp_clock_info"), as this flag accidentally missed while doing the conversion. Drop the unnecessary supported flags check from the bcm_ptp_perout_locked() function and correctly set the supported_perout_flags. This fixes use of the PTP_PEROUT_DUTY_CYCLE support for the broadcom driver. Reported-by: James Clark <jjc@jclark.com> Fixes: d9f3e9ecc456 ("net: ptp: introduce .supported_perout_flags to ptp_clock_info") Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Reviewed-by: Vadim Fedorenko <vadim.fedorenko@linux.dev> Acked-by: Richard Cochran <richardcochran@gmail.com> Reviewed-by: Kory Maincent <kory.maincent@bootlin.com> Tested-by: James Clark <jjc@jclark.com> Link: https://patch.msgid.link/20250918-jk-fix-bcm-phy-supported-flags-v1-1-747b60407c9c@intel.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
2025-09-22Merge tag 'sched_ext-for-6.17-rc7-fixes' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext Pull sched_ext fix from jun Heo: "This contains a fix for sched_ext idle CPU selection that likely fixes a substantial performance regression. The scx_bpf_select_cpu_dfl/and() kfuncs were incorrectly detecting all tasks as migration-disabled when called outside ops.select_cpu(), causing them to always return -EBUSY instead of finding idle CPUs. The fix properly distinguishes between genuinely migration-disabled tasks vs. the current task whose migration is temporarily disabled by BPF execution" * tag 'sched_ext-for-6.17-rc7-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/sched_ext: sched_ext: idle: Handle migration-disabled tasks in BPF code
2025-09-22Merge tag 'for-linus-iommufd' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd Pull iommufd fixes from Jason Gunthorpe: "Fix two user triggerable use-after-free issues: - Possible race UAF setting up mmaps - Syzkaller found UAF when erroring an file descriptor creation ioctl due to the fput() work queue" * tag 'for-linus-iommufd' of git://git.kernel.org/pub/scm/linux/kernel/git/jgg/iommufd: iommufd/selftest: Update the fail_nth limit iommufd: WARN if an object is aborted with an elevated refcount iommufd: Fix race during abort for file descriptors iommufd: Fix refcounting race during mmap
2025-09-22Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdmaLinus Torvalds
Pull rdma fix from Jason Gunthorpe: "Just a one line change, was expecting more rc stuff, but it has been quiet. - Fix mlx5 devx event delivery to userspace for certain kinds of SRQs" * tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma: IB/mlx5: Fix obj_type mismatch for SRQ event subscriptions
2025-09-22Merge tag 'hid-for-linus-2025092201' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid Pull HID fixes from Jiri Kosina: - work data memory corruption fix in amd_sfh (Basavaraj Natikar) - fix for regression in cp2112 where setting a GPIO value would always fail (Sébastien Szymanski) - fix for regression in hid-lenovo causing driver to fail on non-ACPI systems (Janne Grunau) - a couple device ID additions and tiny device-specific quirks * tag 'hid-for-linus-2025092201' of git://git.kernel.org/pub/scm/linux/kernel/git/hid/hid: HID: amd_sfh: Add sync across amd sfh work functions HID: asus: add support for missing PX series fn keys HID: cp2112: fix setter callbacks return value HID: lenovo: Use KEY_PERFORMANCE instead of ACPI's platform_profile HID: intel-thc-hid: intel-quickspi: Add WCL Device IDs HID: intel-thc-hid: intel-quicki2c: Add WCL Device IDs
2025-09-22Merge tag 'pinctrl-v6.17-3' of ↵Linus Torvalds
git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl Pull pin control fixes from Linus Walleij: "Two small driver fixes for the Airhoa driver: - Correct a PHY LED mux value so the PHY LED will blink as it should - Fix the MDIO function bitmasks, working around a HW bug to force-enable the MDIO pins" * tag 'pinctrl-v6.17-3' of git://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl: pinctrl: airoha: fix wrong MDIO function bitmaks pinctrl: airoha: fix wrong PHY LED mux value for LED1 GPIO46
2025-09-22x86/acpi/cstate: Remove open coded check for cpu_feature_enabled()Mario Limonciello (AMD)
acpi_processor_power_init_bm_check() has an open coded implementation of cpu_feature_enabled() to detect X86_FEATURE_ZEN. Switch to using cpu_feature_enabled(). Signed-off-by: Mario Limonciello (AMD) <superm1@kernel.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-22ACPI: SPCR: Support Precise Baud Rate fieldChen Pei
The Microsoft Serial Port Console Redirection (SPCR) specification revision 1.09 comprises additional field: Precise Baud Rate [1]. It is used to describe non-traditional baud rates (such as those used by high-speed UARTs). It contains a specific non-zero baud rate which overrides the value of the Configured Baud Rate field. If this field is zero or not present, Configured Baud Rate is used. Link: https://learn.microsoft.com/en-us/windows-hardware/drivers/serports/serial-port-console-redirection-table [1] Signed-off-by: Chen Pei <cp0613@linux.alibaba.com> Link: https://patch.msgid.link/20250913070815.16758-1-cp0613@linux.alibaba.com [ rjw: Corrected typo in the subject ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2025-09-22drm/i915/pm: Drop redundant pci stuff from suspend/resume pathsVille Syrjälä
I don't think there should be any need for us to call any of pci_enable_device(), pci_disable_device() or pci_set_master() from the suspend/resume paths. The config space save/restore should take care of all of this. Cc: Karthik Poosa <karthik.poosa@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250919185015.14561-7-ville.syrjala@linux.intel.com
2025-09-22drm/i915/pm: Allow drivers/pci to manage our pci state normallyVille Syrjälä
Stop doing the pci_save_state(), except when we need to prevent D3 due to BIOS bugs, so that the code in drivers/pci is allowed to manage the state of the PCI device. Less chance something getting left by the wayside by i915 if/when the things change in drivers/pci. Cc: Badal Nilawar <badal.nilawar@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250919185015.14561-6-ville.syrjala@linux.intel.com
2025-09-22drm/i915/pm: Do pci_restore_state() in switcheroo resume hookVille Syrjälä
Since this switcheroo garbage bypasses all the core pm we have to manually manage the pci state. To that end add the missing pci_restore_state() to the switcheroo resume hook. We already have the pci_save_state() counterpart on the suspend side. Arguably none of this code should exist in the driver in the first place, and instead the entire switcheroo mechanism should be rewritten and properly integrated into core pm code... Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250919185015.14561-5-ville.syrjala@linux.intel.com
2025-09-22drm/i915/pm: Move the hibernate+D3 quirk stuff into noirq() pm hooksVille Syrjälä
If the driver doesn't call pci_save_state() drivers/pci will normally save+power manage the device from the _noirq() pm hooks. We can't let that happen as some old BIOSes fail to hibernate when the device is in D3. However, we can get very close to the standard behaviour by doing our explicit pci_save_state() and pci_set_power_state() stuff from driver provided _noirq() hooks. This results in a change of behaviour where we no longer go into D3 at the end of freeze_late, so when it comes time to thaw() we'll already be in D0, and thus we can drop the explicit pci_set_power_state(D0) call. Presumably switcheroo suspend will want to go into D3 so call the _noirq() stuff from the switcheroo suspend hook, and since we dropped the pci_set_power_state(D0) from resume_early() we'll need to add one back into the switcheroo resume hook. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250919185015.14561-4-ville.syrjala@linux.intel.com
2025-09-22drm/i915/pm: Hoist pci_save_state()+pci_set_power_state() to the end of pm ↵Ville Syrjälä
_late() hook drivers/pci does the pci_save_state()+pci_set_power_state() from the _noirq() pm hooks. Move our manual calls (needed for the hibernate vs. D3 workaround with buggy BIOSes) towards that same point. We currently have no _noirq() hooks, so end of _late() hooks is the best we can do right now. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250919185015.14561-3-ville.syrjala@linux.intel.com
2025-09-22drm/i915/pm: Simplify pm hook documentationVille Syrjälä
Stop spelling out each variant of the hook ("" vs. "_late" vs. "_early") and just say eg. "@thaw*" to indicate all of them. Avoids having to update the docs whenever we start/stop using one of the variants. Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Jouni Högander <jouni.hogander@intel.com> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20250919185015.14561-2-ville.syrjala@linux.intel.com
2025-09-22sched_ext: idle: Handle migration-disabled tasks in BPF codeAndrea Righi
When scx_bpf_select_cpu_dfl()/and() kfuncs are invoked outside of ops.select_cpu() we can't rely on @p->migration_disabled to determine if migration is disabled for the task @p. In fact, migration is always disabled for the current task while running BPF code: __bpf_prog_enter() disables migration and __bpf_prog_exit() re-enables it. To handle this, when @p->migration_disabled == 1, check whether @p is the current task. If so, migration was not disabled before entering the callback, otherwise migration was disabled. This ensures correct idle CPU selection in all cases. The behavior of ops.select_cpu() remains unchanged, because this callback is never invoked for the current task and migration-disabled tasks are always excluded. Example: without this change scx_bpf_select_cpu_and() called from ops.enqueue() always returns -EBUSY; with this change applied, it correctly returns idle CPUs. Fixes: 06efc9fe0b8de ("sched_ext: idle: Handle migration-disabled tasks in idle selection") Cc: stable@vger.kernel.org # v6.16+ Signed-off-by: Andrea Righi <arighi@nvidia.com> Acked-by: Changwoo Min <changwoo@igalia.com> Signed-off-by: Tejun Heo <tj@kernel.org>
2025-09-22ARM: dts: microchip: sam9x7: Add qspi controllerDharma Balasubiramani
Add support for QSPI controller. Signed-off-by: Dharma Balasubiramani <dharma.b@microchip.com> Link: https://lore.kernel.org/r/20250915-sam9x7-qspi-dtsi-v1-1-1cc9adba7573@microchip.com Signed-off-by: Nicolas Ferre <nicolas.ferre@microchip.com>
2025-09-22drm/xe: Don't copy pinned kernel bos twice on suspendThomas Hellström
We were copying the bo content the bos on the list "xe->pinned.late.kernel_bo_present" twice on suspend. Presumingly the intent is to copy the pinned external bos on the first pass. This is harmless since we (currently) should have no pinned external bos needing copy since a) exernal system bos don't have compressed content, b) We do not (yet) allow pinning of VRAM bos. Still, fix this up so that we copy pinned external bos on the first pass. We're about to allow bos pinned in VRAM. Fixes: c6a4d46ec1d7 ("drm/xe: evict user memory in PM notifier") Cc: Matthew Auld <matthew.auld@intel.com> Cc: <stable@vger.kernel.org> # v6.16+ Signed-off-by: Thomas Hellström <thomas.hellstrom@linux.intel.com> Reviewed-by: Matthew Auld <matthew.auld@intel.com> Link: https://lore.kernel.org/r/20250918092207.54472-2-thomas.hellstrom@linux.intel.com (cherry picked from commit 9e69bafece43dcefec864f00b3ec7e088aa7fcbc) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-22drm/xe: Fix build with CONFIG_MODULES=nLucas De Marchi
When building with CONFIG_MODULES=n, the __exit functions are dropped. However our init functions may call them for error handling, so they are not good candidates for the exit sections. Fix this error reported by 0day: ld.lld: error: relocation refers to a symbol in a discarded section: xe_configfs_exit >>> defined in vmlinux.a(drivers/gpu/drm/xe/xe_configfs.o) >>> referenced by xe_module.c >>> drivers/gpu/drm/xe/xe_module.o:(init_funcs) in archive vmlinux.a This is the only exit function using __exit. Drop it to fix the build. Cc: Riana Tauro <riana.tauro@intel.com> Reported-by: kernel test robot <lkp@intel.com> Closes: https://lore.kernel.org/oe-kbuild-all/202506092221.1FmUQmI8-lkp@intel.com/ Fixes: 16280ded45fb ("drm/xe: Add configfs to enable survivability mode") Reviewed-by: Balasubramani Vivekanandan <balasubramani.vivekanandan@intel.com> Link: https://lore.kernel.org/r/20250912-fix-nomodule-build-v1-1-d11b70a92516@intel.com Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com> (cherry picked from commit d9b2623319fa20c2206754284291817488329648) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-22drm/xe/vf: Don't expose sysfs attributes not applicable for VFsMichal Wajdeczko
VFs can't read BMG_PCIE_CAP(0x138340) register nor access PCODE (already guarded by the info.skip_pcode flag) so we shouldn't expose attributes that require any of them to avoid errors like: [] xe 0000:03:00.1: [drm] Tile0: GT0: VF is trying to read an \ inaccessible register 0x138340+0x0 [] RIP: 0010:xe_gt_sriov_vf_read32+0x6c2/0x9a0 [xe] [] Call Trace: [] xe_mmio_read32+0x110/0x280 [xe] [] auto_link_downgrade_capable_show+0x2e/0x70 [xe] [] dev_attr_show+0x1a/0x70 [] sysfs_kf_seq_show+0xaa/0x120 [] kernfs_seq_show+0x41/0x60 Fixes: 0e414bf7ad01 ("drm/xe: Expose PCIe link downgrade attributes") Fixes: cdc36b66cd41 ("drm/xe: Expose fan control and voltage regulator version") Signed-off-by: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Lukasz Laguna <lukasz.laguna@intel.com> Reviewed-by: Raag Jadav <raag.jadav@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> Link: https://lore.kernel.org/r/20250916170029.3313-2-michal.wajdeczko@intel.com (cherry picked from commit a2d6223d224f333f705ed8495bf8bebfbc585c35) Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2025-09-22workqueue: fix texinfodocs warning for WQ_* flags referenceKriish Sharma
Sphinx emitted a warning during make texinfodocs: WARNING: Inline literal start-string without end-string. This was caused by the trailing '*' in "%WQ_*" being parsed as reStructuredText markup in the kernel-doc comment. Escape the '*' in the comment so that Sphinx treats it as a literal character, resolving the warning. Signed-off-by: Kriish Sharma <kriish.sharma2006@gmail.com> Signed-off-by: Tejun Heo <tj@kernel.org>
generated by cgit v1.3 (git 2.53.0) at 2026-11-12 21:49:15 +0000