Refactor RX TID deletion handling by moving the REO command
setup and send sequence into a new helper function:
ath12k_dp_rx_tid_delete_handler().
This improves code readability and modularity, and prepares
the codebase for potential reuse of the REO command logic in
other contexts where RX TID deletion is required.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.3.1-00173-QCAHKSWPL_SILICONZ-1
Tested-on: WCN7850 hw2.0 PCI WLAN.HMT.1.0.c5-00481-QCAHMTSWPL_V1.0_V2.0_SILICONZ-3
Signed-off-by: Nithyanantham Paramasivam <nithyanantham.paramasivam@oss.qualcomm.com>
Reviewed-by: Baochen Qiang <baochen.qiang@oss.qualcomm.com>
Reviewed-by: Vasanthakumar Thiagarajan <vasanthakumar.thiagarajan@oss.qualcomm.com>
Link: https://patch.msgid.link/20250806111750.3214584-3-nithyanantham.paramasivam@oss.qualcomm.com
Signed-off-by: Jeff Johnson <jeff.johnson@oss.qualcomm.com>
- Add methods on `HrTimer` that can only be called with exclusive access to an
unarmed timer, or form timer callback context.
- Add arithmetic operations to `Instant` and `Delta`.
- Add a few convenience and access methods to `HrTimer` and `Instant`.
-----BEGIN PGP SIGNATURE-----
iQJKBAABCAA0FiEEEsH5R1a/fCoV1sAS4bgaPnkoY3cFAmjNKPwWHGEuaGluZGJv
cmdAa2VybmVsLm9yZwAKCRDhuBo+eShjd6ikD/9P4guI56wAqW18y8+EmGBdONyq
sJ0MUK584YjVceby/GTO4EoSR6h9ms0gXFq4u85vE3PLAMIOmrRwYHx/S6kdnxyz
SvrQoLwHv3Uy8ExjDRRUdDbWtJlENOaDrCWIiw3+h/aPcAdZVWpsv49XBvLFF1KQ
kKglf/f0kawwdCqQMEloBN90PmP4Nut0Ele5F6WeMth30SbRtaK4OaQLi52errLn
OGJeqv6wmLIHjN6VdXqjHb241tJptjbyS8kG+GSv+EZ2OStH3jt6azfZrtG9a+Iq
iDSCrcZ0/fYMEJ0ybOyXbgaeut7RJjW4Wnlo0AJwnCyptHeChlwJ0dGwQ62AvSKt
cpCX38xKK9A91vpKdFNdDi7BDiMzM4dWAByc/Tx1USGVJA/sTIVNCa8w6VLo1tJ6
3ve/ORXD2LeyUjWvkMWms728zzrQswdXYc8OeXm/YaxT1Dewtpu2slrfGIC48tos
gFfhhFd1PwYtfXBVhYCUhTQqBIwlh9t/Mb37Q5D7PTCKEALIpLhsYJI3daM5BF10
LuqdosfL2n4weTsO+FXpCE3vnnPmplWqZYn3Th3vEJy6IrrxpiC6EwndjuCPSMcB
iHghzu/vSEw8cYpca3HHp1F8HGarfYyf19tncta2J+hZlXxbq81NIZoHfUAo4k6E
dJRjwZ51erfV53kGjg==
=MWG5
-----END PGP SIGNATURE-----
Merge tag 'rust-timekeeping-v6.18' of https://github.com/Rust-for-Linux/linux into rust-next
Pull timekeeping updates from Andreas Hindborg:
- Add methods on 'HrTimer' that can only be called with exclusive
access to an unarmed timer, or form timer callback context.
- Add arithmetic operations to 'Instant' and 'Delta'.
- Add a few convenience and access methods to 'HrTimer' and 'Instant'.
* tag 'rust-timekeeping-v6.18' of https://github.com/Rust-for-Linux/linux:
rust: time: Implement basic arithmetic operations for Delta
rust: time: Implement Add<Delta>/Sub<Delta> for Instant
rust: hrtimer: Add HrTimer::expires()
rust: time: Add Instant::from_ktime()
rust: hrtimer: Add forward_now() to HrTimer and HrTimerCallbackContext
rust: hrtimer: Add HrTimerCallbackContext and ::forward()
rust: hrtimer: Add HrTimer::raw_forward() and forward()
rust: hrtimer: Add HrTimerInstant
rust: hrtimer: Document the return value for HrTimerHandle::cancel()
This is a port of the Binder data structure introduced in commit
15d9da3f81 ("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>
Provides an abstraction for C bitmap API and bitops operations.
This commit enables a Rust implementation of an Android Binder
data structure from commit 15d9da3f81 ("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>
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>
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>
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>
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 5c667d5a5a ("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>
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>
Christian reported that commit a430c11f40 ("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: a430c11f40 ("intel_idle: Rescan "dead" SMT siblings during initialization")
Fixes: f694481b1d ("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
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 dbd5058ba6
("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>
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>
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 7ed90803a2
("mptcp: send explicit ack on delayed ack_seq incr") and commit
ea4ca586b1 ("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>
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>
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>
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>
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>
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>
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: bfec6d7f20 ("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>
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>
The commit 61f132ca8c ("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>
The rcu_read_lock() has been introduced in __ethtool_get_ts_info() since
the commit 4c61d809cf ("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: f5b9a1cde0 ("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>
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 e48c414ee6~
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>
inet_unhash() checks sk_unhashed() twice at the entry and after locking
ehash/lhash bucket.
The former was somehow added redundantly by commit 4f9bf2a2f5 ("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>
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>
__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>
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>
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>
Commit 6138e687c7 ("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>
Commit 7c571ac57d ("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 6138e687c7 ("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: 7c571ac57d ("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>
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
d9f3e9ecc4 ("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: d9f3e9ecc4 ("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>
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.
-----BEGIN PGP SIGNATURE-----
iIQEABYKACwWIQTfIjM1kS57o3GsC/uxYfJx3gVYGQUCaNF8hQ4cdGpAa2VybmVs
Lm9yZwAKCRCxYfJx3gVYGYhsAPwNeMGqniyewfciL6q+9Yjnxudn+bCzntvTidY/
EbV3vgD9GPily3kjKhuPBGIq5hnyiV1DsmmCTIu8vaj7RB4uYw8=
=k2RU
-----END PGP SIGNATURE-----
Merge tag 'sched_ext-for-6.17-rc7-fixes' of 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
Two user triggerable UAFs:
- Possible race UAF setting up mmaps
- Syzkaller found UAF when erroring an file descriptor creation ioctl due
to the fput() work queue.
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRRRCHOFoQz/8F5bUaFwuHvBreFYQUCaNFXCgAKCRCFwuHvBreF
YXoFAP9xzBDOVp64CJBY8cD/URaQc8t55b8uJCYgxbDesQa4iAEAxTX9gdZ7Lr6Z
THwdY00LI040gBHUxIZOaXNeOhuPIg8=
=DQIy
-----END PGP SIGNATURE-----
Merge tag 'for-linus-iommufd' of 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
- Fix mlx5 devx event delivery to userspace for certain kinds of SRQs
-----BEGIN PGP SIGNATURE-----
iHUEABYKAB0WIQRRRCHOFoQz/8F5bUaFwuHvBreFYQUCaNFT/AAKCRCFwuHvBreF
YcafAP9bA38Qg5N2FZVUdKHRFx1diKVmh2Icp2zDqFmR/mhpSAD/enXPK3FLnQrx
hwB/2b/xn5yWjOllWAokjwaFoZ49zgA=
=dG5k
-----END PGP SIGNATURE-----
Merge tag 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma
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
-----BEGIN PGP SIGNATURE-----
iQIzBAABCAAdFiEEL65usyKPHcrRDEicpmLzj2vtYEkFAmjREAsACgkQpmLzj2vt
YEk3cQ/9EJXVKCOlENyjAVd/Lu1tG8iRL181l4nlnkXkUKWG1//Qq+5g9qU1ycpy
V21mYHzgriJ6fA1lH/UKgw2Ayq2QA2Rqe3TDCdzdwi8bRvPEvGxH+zmaickuZHpl
Zi+LT17xW3SZtNRXKMDp5/Feb85quOQSuo+HXrql14jl3sF5nAF9BfOwvTb/UHel
YzL3mAtwyDF90Ijhl/uLQaSeblHG3LOnCy3OPE7XyyOOXW3VQvXuEp5mA9Cac18J
A0zcIYlR+wUj3yobjLe7xU27HKUe01a3WMGt3FfrStQK4HQFl1Rg6I66piBbqd4/
oroP78A8tfVJf1ruGadcvj7IuRg9tSTHZVowRDx+5TeRywWFBBGIrmBfy3WiMmGA
M/78ADQvcExOOY0kZBCXD3aJShpoS7gL0f35fKoC8yKhgyHC+GKOQwQz1kX2ub2Z
oRdnb1GItQ4wDvLH8yyJahMYWhuVv/R7ITABAs8Nb68yMO0yS5aMVFeW2kzZ0eM2
5yM0XtTzKWNSMi525+CEZDy53cNkrThhgC72UhSHmgnEtlcfgYZ0Gd9j6tSF2KEJ
FVIUu0o4DV303IJmx5euLOrwY/vHgr3Qw4bH2qIxw32CocgPabYcn6IAd5aynCrB
MmRqpMu/SOAPStBFYNSUk/CJvLlGImUAGe5m99daGTZxWjHRZ30=
=Jiyj
-----END PGP SIGNATURE-----
Merge tag 'hid-for-linus-2025092201' of 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
These are 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.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEElDRnuGcz/wPCXQWMQRCzN7AZXXMFAmjRBrkACgkQQRCzN7AZ
XXOK9Q//WYo/Jm6KETEwWAlEEKOTr3h+FnUox6giOOItXbJhJ1iqLzTLIhMsJHK5
2uEEFxtHAuNu01cNPYUkIfgqCpYEyA1xK7/gtRV+IWeFt4IiVDCMtyCCiUMzKV4k
OgeMO7Scqvm61qrvOu/+WF1kc+lsGZ3dJPoBLq1C6Dn67Y0SNegICCJh6YPPis4J
lEpx4PqZiqDYOMuy/r9tuAKFqOlP4Q9BhsXzLH+hC1V2kd7/7/hqWx3i+WFADDNP
1Q+GQYqqqR1yLhZq+tsJ2TcdAP04cx9mWuxeclIQrqQPxyeoFz4ua2K8s1TFUDu6
f3Gw7UAtCLJjx3O1G/Ji0MccrpUBr8IWdJloKHsiREuogzk4zdRT/6czBEZywM/G
HJ0EHrWNZa7RExxmfGG05/21YBHAAavfxF4klboxpfTcECXbCuJqJPq8IUe7EKwx
rXdkWTFxJhEMX3VL2BlTccIXZ4BjX9IokuLT3FYIaww4AXAOMhz8Jx2G8PnlfOeg
xVGDyVbmUzaO4SKcFfR7VvCXIxlk9F4keouG9cmxrNFbjgSSt24sab5QLdNujzdT
gTaFswHZ6P2rtqctcCbQN2XeK9qvPBOWvZv6ea9rxvMvsO5+7wC5Us/z4VFCmPvB
NFqNL+lNZ6HJgrlAtqkQPiqYRNdePUud7OsomPxIO5QnM2TEIkc=
=nbM0
-----END PGP SIGNATURE-----
Merge tag 'pinctrl-v6.17-3' of 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
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>
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>
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
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
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
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
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
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
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: 06efc9fe0b ("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>
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: c6a4d46ec1 ("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 9e69bafece)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
