summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2026-04-07irqchip/renesas-rzv2h: Kill icu_err stringGeert Uytterhoeven1-6/+3
Replace the string variable icu_err by its expanded value where needed, to improve readability. This reduces generated code size by 16 bytes. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Link: https://patch.msgid.link/c7472bec20dea2c4d63e390e8e293b7d7003ef39.1775205874.git.geert+renesas@glider.be
2026-04-07irqchip/renesas-rzv2h: Kill swint_names[]Geert Uytterhoeven1-10/+4
The array swint_names[] just contains expansions of "int-ca55-%u". Replace it by formatting the strings where needed, to improve readability. Despite the two error messages can no longer be shared with the ICU error cases, this reduces generated code size by 56 bytes. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/aceab3fbc307ef428dfd62d8d846b68704dea012.1775205874.git.geert+renesas@glider.be
2026-04-07irqchip/renesas-rzv2h: Kill swint_idx[]Geert Uytterhoeven1-3/+2
The array swint_idx[] just contains an identity mapping. Replace it by using the index directly, to simplify the code. Signed-off-by: Geert Uytterhoeven <geert+renesas@glider.be> Signed-off-by: Thomas Gleixner <tglx@kernel.org> Reviewed-by: Biju Das <biju.das.jz@bp.renesas.com> Link: https://patch.msgid.link/0f32ba2a4701311710d02ff4fa2fd472b56745c4.1775205874.git.geert+renesas@glider.be
2026-04-07slub: use N_NORMAL_MEMORY in can_free_to_pcs to handle remote freesHao Li1-2/+3
Memory hotplug now keeps N_NORMAL_MEMORY up to date correctly, so make can_free_to_pcs() use it. As a result, when freeing objects on memoryless nodes, or on nodes that have memory but only in ZONE_MOVABLE, the objects can be freed to the sheaf instead of going through the slow path. Signed-off-by: Hao Li <hao.li@linux.dev> Acked-by: Harry Yoo (Oracle) <harry@kernel.org> Acked-by: David Rientjes <rientjes@google.com> Link: https://patch.msgid.link/20260403073958.8722-1-hao.li@linux.dev Signed-off-by: Vlastimil Babka (SUSE) <vbabka@kernel.org>
2026-04-07net: af_key: zero aligned sockaddr tail in PF_KEY exportsZhengchuan Liang1-18/+34
PF_KEY export paths use `pfkey_sockaddr_size()` when reserving sockaddr payload space, so IPv6 addresses occupy 32 bytes on the wire. However, `pfkey_sockaddr_fill()` initializes only the first 28 bytes of `struct sockaddr_in6`, leaving the final 4 aligned bytes uninitialized. Not every PF_KEY message is affected. The state and policy dump builders already zero the whole message buffer before filling the sockaddr payloads. Keep the fix to the export paths that still append aligned sockaddr payloads with plain `skb_put()`: - `SADB_ACQUIRE` - `SADB_X_NAT_T_NEW_MAPPING` - `SADB_X_MIGRATE` Fix those paths by clearing only the aligned sockaddr tail after `pfkey_sockaddr_fill()`. Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2") Fixes: 08de61beab8a ("[PFKEYV2]: Extension for dynamic update of endpoint address(es)") Reported-by: Yifan Wu <yifanwucs@gmail.com> Reported-by: Juefei Pu <tomapufckgml@gmail.com> Co-developed-by: Yuan Tan <yuantan098@gmail.com> Signed-off-by: Yuan Tan <yuantan098@gmail.com> Suggested-by: Xin Liu <bird@lzu.edu.cn> Tested-by: Xiao Liu <lx24@stu.ynu.edu.cn> Signed-off-by: Zhengchuan Liang <zcliangcn@gmail.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2026-04-07xfrm: Drop support for HMAC-RIPEMD-160Eric Biggers2-26/+2
Drop support for HMAC-RIPEMD-160 from IPsec to reduce the UAPI surface and simplify future maintenance. It's almost certainly unused. RIPEMD-160 received some attention in the early 2000s when SHA-* weren't quite as well established. But it never received much adoption outside of certain niches such as Bitcoin. It's actually unclear that Linux + IPsec + HMAC-RIPEMD-160 has *ever* been used, even historically. When support for it was added in 2003, it was done so in a "cleanup" commit without any justification [1]. It didn't actually work until someone happened to fix it 5 years later [2]. That person didn't use or test it either [3]. Finally, also note that "hmac(rmd160)" is by far the slowest of the algorithms in aalg_list[]. Of course, today IPsec is usually used with an AEAD, such as AES-GCM. But even for IPsec users still using a dedicated auth algorithm, they almost certainly aren't using, and shouldn't use, HMAC-RIPEMD-160. Thus, let's just drop support for it. Note: no kconfig update is needed, since CRYPTO_RMD160 wasn't actually being selected anyway. References: [1] linux-history commit d462985fc1941a47 ("[IPSEC]: Clean up key manager algorithm handling.") [2] linux commit a13366c632132bb9 ("xfrm: xfrm_algo: correct usage of RIPEMD-160") [3] https://lore.kernel.org/all/1212340578-15574-1-git-send-email-rueegsegger@swiss-it.ch Signed-off-by: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2026-04-07Merge patch series "rust: bump minimum Rust and `bindgen` versions"Miguel Ojeda39-451/+88
As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's Rust versions as our minimum supported version. Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it still uses to this day [3] (i.e. no update to Rust 1.85.1). Debian Trixie was released with `bindgen` 0.71.1, which it also still uses to this day [4]. Debian Trixie's release happened on 2025-08-09 [5], which means that a fair amount of time has passed since its release for kernel developers to upgrade. Thus bump the minimum to the new versions, i.e. - Rust: 1.78.0 -> 1.85.0 - bindgen: 0.65.1 -> 0.71.1 There are a few main parts to the series, in this order: - A few cleanups that can be performed before the bumps. - The Rust bump (and its cleanups). - The `bindgen` bump (and its cleanups). - Documentation updates. - The `cfi_encoding` patch, added here, which needs the bump. - The per-version flags support and a Clippy cleanup on top. Link: https://lwn.net/Articles/1050174/ [1] Link: https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#desktops-and-well-known-packages [2] Link: https://packages.debian.org/trixie/rustc [3] Link: https://packages.debian.org/trixie/bindgen [4] Link: https://www.debian.org/releases/trixie/ [5] Link: https://patch.msgid.link/20260405235309.418950-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07xfrm_user: fix info leak in build_report()Greg Kroah-Hartman1-0/+1
struct xfrm_user_report is a __u8 proto field followed by a struct xfrm_selector which means there is three "empty" bytes of padding, but the padding is never zeroed before copying to userspace. Fix that up by zeroing the structure before setting individual member variables. Cc: stable <stable@kernel.org> Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Simon Horman <horms@kernel.org> Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2026-04-07xfrm_user: fix info leak in build_mapping()Greg Kroah-Hartman1-0/+1
struct xfrm_usersa_id has a one-byte padding hole after the proto field, which ends up never getting set to zero before copying out to userspace. Fix that up by zeroing out the whole structure before setting individual variables. Fixes: 3a2dfbe8acb1 ("xfrm: Notify changes in UDP encapsulation via netlink") Cc: Steffen Klassert <steffen.klassert@secunet.com> Cc: Herbert Xu <herbert@gondor.apana.org.au> Cc: "David S. Miller" <davem@davemloft.net> Cc: Eric Dumazet <edumazet@google.com> Cc: Jakub Kicinski <kuba@kernel.org> Cc: Paolo Abeni <pabeni@redhat.com> Cc: Simon Horman <horms@kernel.org> Assisted-by: gregkh_clanker_t1000 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2026-04-07xfrm: fix refcount leak in xfrm_migrate_policy_findKotlyarov Mihail1-3/+0
syzkaller reported a memory leak in xfrm_policy_alloc: BUG: memory leak unreferenced object 0xffff888114d79000 (size 1024): comm "syz.1.17", pid 931 ... xfrm_policy_alloc+0xb3/0x4b0 net/xfrm/xfrm_policy.c:432 The root cause is a double call to xfrm_pol_hold_rcu() in xfrm_migrate_policy_find(). The lookup function already returns a policy with held reference, making the second call redundant. Remove the redundant xfrm_pol_hold_rcu() call to fix the refcount imbalance and prevent the memory leak. Found by Linux Verification Center (linuxtesting.org) with Syzkaller. Fixes: 563d5ca93e88 ("xfrm: switch migrate to xfrm_policy_lookup_bytype") Signed-off-by: Kotlyarov Mihail <mihailkotlyarow@gmail.com> Reviewed-by: Florian Westphal <fw@strlen.de> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2026-04-07xfrm: hold dev ref until after transport_finish NF_HOOKQi Tang3-6/+22
After async crypto completes, xfrm_input_resume() calls dev_put() immediately on re-entry before the skb reaches transport_finish. The skb->dev pointer is then used inside NF_HOOK and its okfn, which can race with device teardown. Remove the dev_put from the async resumption entry and instead drop the reference after the NF_HOOK call in transport_finish, using a saved device pointer since NF_HOOK may consume the skb. This covers NF_DROP, NF_QUEUE and NF_STOLEN paths that skip the okfn. For non-transport exits (decaps, gro, drop) and secondary async return points, release the reference inline when async is set. Suggested-by: Florian Westphal <fw@strlen.de> Fixes: acf568ee859f ("xfrm: Reinject transport-mode packets through tasklet") Cc: stable@vger.kernel.org Signed-off-by: Qi Tang <tpluszz77@gmail.com> Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
2026-04-07xfrm: Wait for RCU readers during policy netns exitSteffen Klassert1-0/+2
xfrm_policy_fini() frees the policy_bydst hash tables after flushing the policy work items and deleting all policies, but it does not wait for concurrent RCU readers to leave their read-side critical sections first. The policy_bydst tables are published via rcu_assign_pointer() and are looked up through rcu_dereference_check(), so netns teardown must also wait for an RCU grace period before freeing the table memory. Fix this by adding synchronize_rcu() before freeing the policy hash tables. Fixes: e1e551bc5630 ("xfrm: policy: prepare policy_bydst hash for rcu lookups") Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com> Reviewed-by: Florian Westphal <fw@strlen.de>
2026-04-07Merge tag 'icc-7.1-rc1' of ↵Greg Kroah-Hartman19-461/+4014
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/djakov/icc into char-misc-next Georgi writes: This pull request contains the interconnect changes for the 7.1-rc1 merge window. They are listed below: - New driver for Mahua SoC - New driver for Eliza SoC - Enable QoS support for QCS8300 and QCS615 SoCs - Add L3 cache scaling compatibles for SM8550 and Eliza SoCs - Fix multiple issues in the msm8974 driver - Fix kfree mismatch - Misc cleanups - Add maintainer entry for the interconnect KUnit tests Signed-off-by: Georgi Djakov <djakov@kernel.org> * tag 'icc-7.1-rc1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/djakov/icc: (22 commits) MAINTAINERS: Add interconnect kunit test entry interconnect: debugfs: fix devm_kstrdup and kfree mismatch interconnect: qcom: msm8974: expand DEFINE_QNODE macros interconnect: qcom: msm8974: switch to the main icc-rpm driver interconnect: qcom: let platforms declare their bugginess interconnect: qcom: define OCMEM bus resource interconnect: qcom: icc-rpm: allow overwriting get_bw callback interconnect: qcom: drop unused is_on flag dt-bindings: interconnect: qcom,msm8974: use qcom,rpm-common dt-bindings: interconnect: qcom,msm8974: drop bus clocks interconnect: qcom: qcs615: enable QoS configuration dt-bindings: interconnect: qcom,qcs615-rpmh: add clocks property to enable QoS interconnect: qcom: Add Eliza interconnect provider driver dt-bindings: interconnect: document the RPMh Network-On-Chip interconnect in Eliza SoC dt-bindings: interconnect: OSM L3: Add Eliza EPSS L3 compatible interconnect: qcom: De-acronymize SoC names dt-bindings: interconnect: qcom,glymur-rpmh: De-acronymize SoC name dt-bindings: interconnect: OSM L3: Document sm8550 OSM L3 compatible interconnect: qcom: qcs8300: enable QoS configuration dt-bindings: interconnect: qcom,qcs8300-rpmh: add clocks property to enable QoS ...
2026-04-07Merge tag 'extcon-next-for-7.1' of ↵Greg Kroah-Hartman6-17/+75
ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-next Chanwoo writes: Update extcon next for v7.1 Detailed description for this pull request: - Fix sysfs duplicate filename issue on extcon core : Adjust ida_free timing after device_unregister to prevent duplicate filename error when re-allocating id - Update NXP PTN5150 extcon driver and dt-binding document : Handle pending IRQ events during system resume : Allow "connector" node to present in devicetree : Add Type-C orientation switch support to correctly set orientation of multiplexer according to CC status : Support USB role switch via connector fwnode - Replace use of system_wq with system_percpu_wq on int3496 driver - Make typec-power-opmode optional on usbc-tusb320 driver : Prevent probe error when usb-c connector is configured in the DT without "typec-power-opmode" property * tag 'extcon-next-for-7.1' of ssh://gitolite.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon: extcon: usbc-tusb320: Make typec-power-opmode optional extcon: ptn5150: Support USB role switch via connector fwnode extcon: ptn5150: Add Type-C orientation switch support dt-bindings: extcon: ptn5150: Allow "connector" node to present extcon: Fixed sysfs duplicate filename issue extcon: int3496: replace use of system_wq with system_percpu_wq extcon: ptn5150: handle pending IRQ events during system resume
2026-04-07rust: kbuild: allow `clippy::precedence` for Rust < 1.86.0Miguel Ojeda1-1/+7
The Clippy `precedence` lint was extended in Rust 1.85.0 to include bitmasking and shift operations [1]. However, because it generated many hits, in Rust 1.86.0 it was split into a new `precedence_bits` lint which is not enabled by default [2]. In other words, only Rust 1.85 has a different behavior. For instance, it reports: warning: operator precedence can trip the unwary --> drivers/gpu/nova-core/fb/hal/ga100.rs:16:5 | 16 | / u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08()) << FLUSH_SYSMEM_ADDR_SHIFT 17 | | | u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40()) 18 | | << FLUSH_SYSMEM_ADDR_SHIFT_HI | |_________________________________________^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#precedence = note: `-W clippy::precedence` implied by `-W clippy::all` = help: to override `-W clippy::all` add `#[allow(clippy::precedence)]` help: consider parenthesizing your expression | 16 ~ (u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR::read(bar).adr_39_08()) << FLUSH_SYSMEM_ADDR_SHIFT) | (u64::from(regs::NV_PFB_NISO_FLUSH_SYSMEM_ADDR_HI::read(bar).adr_63_40()) 17 + << FLUSH_SYSMEM_ADDR_SHIFT_HI) | While so far we try our best to keep all versions Clippy-clean, the minimum (which is now Rust 1.85.0 after the bump) and the latest stable are the most important ones; and this may be considered a "false positive" with respect to the behavior in other versions. Thus allow this lint for this version using the per-version flags mechanism introduced in the previous commit. Link: https://github.com/rust-lang/rust-clippy/issues/14097 [1] Link: https://github.com/rust-lang/rust-clippy/pull/14115 [2] Link: https://lore.kernel.org/rust-for-linux/DFVDKMMA7KPC.2DN0951H3H55Y@kernel.org/ Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-34-ojeda@kernel.org [ Added paragraph from commit message to comment. - Miguel ] Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: kbuild: support global per-version flagsMiguel Ojeda1-1/+9
Sometimes it is useful to gate global Rust flags per compiler version. For instance, we may want to disable a lint that has false positives in a single version [1]. We already had helpers like `rustc-min-version` for that, which we use elsewhere, but we cannot currently use them for `rust_common_flags`, which contains the global flags for all Rust code (kernel and host), because `rustc-min-version` depends on `CONFIG_RUSTC_VERSION`, which does not exist when `rust_common_flags` is defined. Thus, to support that, introduce `rust_common_flags_per_version`, defined after the `include/config/auto.conf` inclusion (where `CONFIG_RUSTC_VERSION` becomes available), and append it to `rust_common_flags`, `KBUILD_HOSTRUSTFLAGS` and `KBUILD_RUSTFLAGS`. In addition, move the expansion of `HOSTRUSTFLAGS` to the same place, so that users can also override per-version flags [2]. Link: https://lore.kernel.org/rust-for-linux/CANiq72mWdFU11GcCZRchzhy0Gi1QZShvZtyRkHV2O+WA2uTdVQ@mail.gmail.com/ [1] Link: https://lore.kernel.org/rust-for-linux/CANiq72mTaA2tjhkLKf0-2hrrrt9rxWPgy6SfNSbponbGOegQvA@mail.gmail.com/ [2] Link: https://patch.msgid.link/20260307170929.153892-1-ojeda@kernel.org Link: https://patch.msgid.link/20260405235309.418950-33-ojeda@kernel.org Reviewed-by: Tamir Duberstein <tamird@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: declare cfi_encoding for lru_statusAlice Ryhl8-45/+10
By default bindgen will convert 'enum lru_status' into a typedef for an integer. For the most part, an integer of the same size as the enum results in the correct ABI, but in the specific case of CFI, that is not the case. The CFI encoding is supposed to be the same as a struct called 'lru_status' rather than the name of the underlying native integer type. To fix this, tell bindgen to generate a newtype and set the CFI type explicitly. Note that we need to set the CFI attribute explicitly as bindgen is using repr(transparent), which is otherwise identical to the inner type for ABI purposes. This allows us to remove the page range helper C function in Binder without risking a CFI failure when list_lru_walk calls the provided function pointer. The --with-attribute-custom-enum argument requires bindgen v0.71 or greater. [ In particular, the feature was added in 0.71.0 [1][2]. In addition, `feature(cfi_encoding)` has been available since Rust 1.71.0 [3]. Link: https://github.com/rust-lang/rust-bindgen/issues/2520 [1] Link: https://github.com/rust-lang/rust-bindgen/pull/2866 [2] Link: https://github.com/rust-lang/rust/pull/105452 [3] - Miguel ] My testing procedure was to add this to the android17-6.18 branch and verify that rust_shrink_free_page is successfully called without crash, and verify that it does in fact crash when the cfi_encoding is set to other values. Note that I couldn't test this on android16-6.12 as that branch uses a bindgen version that is too old. Signed-off-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260223-cfi-lru-status-v2-1-89c6448a63a4@google.com [ Rebased on top of the minimum Rust version bump series which provide the required `bindgen` version. - Miguel ] Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-32-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: general-information: use real exampleMiguel Ojeda1-2/+2
Currently the example in the documentation shows a version-based name for the Kconfig example: RUSTC_VERSION_MIN_107900 The reason behind it was to possibly avoid repetition in case several features used the same minimum. However, we ended up preferring to give them a descriptive name for each feature added even if that could lead to some repetition. In practice, the repetition has not happened so far, and even if it does at some point, it is not a big deal. Thus replace the example in the documentation with one of our current examples (after removing previous ones from the bump), to show how they actually look like, and in case someone `grep`s for it. In addition, it has the advantage that it shows the `RUSTC_HAS_*` pattern we follow in `init/Kconfig`, similar to the C side. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-31-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: general-information: simplify Kconfig exampleMiguel Ojeda1-1/+1
There is no need to use `def_bool y if <expr>` -- one can simply write `def_bool <expr>`. In fact, the simpler form is how we actually use them in practice in `init/Kconfig`. Thus simplify the example. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-30-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: remove GDB/Binutils mentionMiguel Ojeda1-9/+0
The versions provided nowadays by even a distribution like Debian Stable (and Debian Old Stable) are newer than those mentioned [1]. Thus remove the workaround. Note that the minimum binutils version in the kernel is still 2.30, so one could argue part of the note is still relevant, but it is unlikely a kernel developer using such an old binutils is enabling Rust on a modern kernel, especially when using distribution toolchains, e.g. the Rust minimum version is not satisfied by Debian Old Stable. So we are at the point where keeping the docs short and relevant for essentially everyone is probably the better trade-off. Link: https://packages.debian.org/search?suite=all&searchon=names&keywords=binutils [1] Link: https://lore.kernel.org/all/CANiq72mCpc9=2TN_zC4NeDMpFQtPXAFvyiP+gRApg2vzspPWmw@mail.gmail.com/ Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-29-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: remove Nix "unstable channel" noteMiguel Ojeda1-2/+2
Nix does not need the "unstable channel" note, since its packages are recent enough even in the stable channel [1][2]. Thus remove it to simplify the documentation. Link: https://search.nixos.org/packages?channel=25.11&query=rust [1] Link: https://search.nixos.org/packages?channel=25.11&query=bindgen [2] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-28-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: remove Gentoo "testing" noteMiguel Ojeda1-2/+2
Gentoo does not need the "testing" note, since its packages are recent enough even in the stable branch [1][2]. Thus remove it to simplify the documentation. Link: https://packages.gentoo.org/packages/dev-lang/rust [1] Link: https://packages.gentoo.org/packages/dev-util/bindgen [2] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-27-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: add Ubuntu 26.04 LTS and remove subsection titleMiguel Ojeda1-4/+1
Ubuntu 26.04 LTS (Resolute Raccoon) is scheduled to be released in a few weeks [1], and it has a recent enough Rust toolchain, just like Ubuntu 25.10 has [2][3]. We could update the title and the paragraph, but to simplify and to make it more consistent with the other distributions' sections, let's instead just remove that title. It will also reduce the differences later on to keep it updated. Eventually, when we remove the remaining subsection for older LTSs, Ubuntu should be a small section like the other distributions. Thus remove the title and add the mention of Ubuntu 26.04 LTS. Link: https://documentation.ubuntu.com/release-notes/26.04/schedule/#resolute-raccoon-schedule [1] Link: https://packages.ubuntu.com/search?keywords=rustc&searchon=names&exact=1&suite=all&section=all [2] Link: https://packages.ubuntu.com/search?keywords=bindgen&searchon=names&exact=1&suite=all&section=all [3] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-26-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: update minimum Ubuntu versionMiguel Ojeda1-1/+1
Ubuntu 25.04 is out of support [1], and Ubuntu 25.10 is the latest supported one. Moreover, Ubuntu 25.10 is the first that provides a recent enough Rust given the minimum bump -- they provide 1.85.1 [2]. Thus update it. Link: https://ubuntu.com/about/release-cycle [1] Link: https://packages.ubuntu.com/search?keywords=rustc&searchon=names&exact=1&suite=all&section=all [2] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-25-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: update Ubuntu versioned packagesMiguel Ojeda1-14/+14
Now that the minimum supported Rust version is bumped, bump the versioned Rust packages [1][2][3][4] to that version for Ubuntu in the Quick Start guide. In addition, add "may" to the `RUST_LIB_SRC` line since it does not look like it is needed from a quick test in a Ubuntu 24.04 LTS container. Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=rustc [1] Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=bindgen [2] Link: https://launchpad.net/ubuntu/+source/rustc-1.85 [3] Link: https://launchpad.net/ubuntu/+source/rust-bindgen-0.71 [4] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-24-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07docs: rust: quick-start: openSUSE provides `rust-src` package nowadaysMiguel Ojeda1-1/+1
Both openSUSE Tumbleweed and Slowroll provide the `rust-src` package nowadays [1]. Thus remove the version-specific one from the Quick Start guide. Link: https://software.opensuse.org/package/rust-src?search_term=rust-src [1] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-23-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: kbuild: remove "dummy parameter" workaround for `bindgen` < 0.71.1Miguel Ojeda2-13/+2
Until the version bump of `bindgen`, we needed to pass a dummy parameter to avoid failing the `--version` call. Thus remove it. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-22-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: kbuild: update `bindgen --rust-target` version and replace commentMiguel Ojeda1-14/+2
As the comment in the `Makefile` explains, previously, we needed to limit ourselves to the list of Rust versions known by `bindgen` for its `--rust-target` option [1]. In other words, we needed to consult the versions known by the minimum version of `bindgen` that we supported. Now that we bumped the minimum version of `bindgen`, that limitation does not apply anymore since `bindgen` 0.71.0 [2]. Thus replace the comment and simply write our minimum supported Rust version there, which is much simpler. See commit 7a5f93ea5862 ("rust: kbuild: set `bindgen`'s Rust target version") for more details. Link: https://rust-lang.zulipchat.com/#narrow/channel/425075-rust-for-linux/topic/rust.20version.20on.20generated.20bindings/near/484087179 [1] Link: https://github.com/rust-lang/rust-bindgen/pull/2993 [2] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-21-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: rust_is_available: remove warning for `bindgen` < 0.69.5 && libclang ↵Miguel Ojeda3-51/+1
>= 19.1 It is not possible anymore to fall into the issue that this warning was alerting about given the `bindgen` version bump. Thus simplify by removing the machinery behind it, including tests. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-20-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: rust_is_available: remove warning for `bindgen` 0.66.[01]Miguel Ojeda3-38/+3
It is not possible anymore to fall into the issue that this warning was alerting about given the `bindgen` version bump. Thus simplify by removing the machinery behind it, including tests. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-19-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: bump `bindgen` minimum supported version to 0.71.1 (Debian Trixie)Miguel Ojeda2-2/+2
As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's `bindgen` versions as our minimum supported version. Debian Trixie was released with `bindgen` 0.71.1, which it still uses to this day [2]. Debian Trixie's release happened on 2025-08-09 [3], which means that a fair amount of time has passed since its release for kernel developers to upgrade. Thus bump the minimum to the new version. Then, in later commits, clean up most of the workarounds and other bits that this upgrade of the minimum allows us. Ubuntu 25.10 also has a recent enough `bindgen` [4] (even the already unsupported Ubuntu 25.04 had it), and they also provide versioned packages with `bindgen` 0.71.1 back to Ubuntu 24.04 LTS [5]. Link: https://lwn.net/Articles/1050174/ [1] Link: https://packages.debian.org/trixie/bindgen [2] Link: https://www.debian.org/releases/trixie/ [3] Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=bindgen [4] Link: https://launchpad.net/ubuntu/+source/rust-bindgen-0.71 [5] Acked-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-18-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: block: update `const_refs_to_static` MSRV TODO commentMiguel Ojeda1-3/+1
`feature(const_refs_to_static)` was stabilized in Rust 1.83.0 [1]. Thus update the comment to reflect that. Link: https://github.com/rust-lang/rust/pull/129759 [1] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-17-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: macros: simplify code using `feature(extract_if)`Miguel Ojeda2-4/+8
`feature(extract_if)` [1] was stabilized in Rust 1.87.0 [2], and the last significant change happened in Rust 1.85.0 [3] when the range parameter was added. That is, with our new minimum version, we can start using the feature. Thus simplify the code using the feature and remove the TODO comment. Suggested-by: Gary Guo <gary@garyguo.net> Link: https://lore.kernel.org/rust-for-linux/DHHVSX66206Y.3E7I9QUNTCJ8I@garyguo.net/ Link: https://github.com/rust-lang/rust/issues/43244 [1] Link: https://github.com/rust-lang/rust/pull/137109 [2] Link: https://github.com/rust-lang/rust/pull/133265 [3] Link: https://patch.msgid.link/20260405235309.418950-16-ojeda@kernel.org Reviewed-by: Tamir Duberstein <tamird@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: alloc: simplify with `NonNull::add()` now that it is stableMiguel Ojeda1-7/+1
Currently, we need to go through raw pointers and then re-create the `NonNull` from the result of offsetting the raw pointer. `feature(non_null_convenience)` [1] has been stabilized in Rust 1.80.0 [2], which is older than our new minimum Rust version (Rust 1.85.0). Thus, now that we bump the Rust minimum version, simplify using `NonNull::add()` and clean the TODO note. Link: https://github.com/rust-lang/rust/issues/117691 [1] Link: https://github.com/rust-lang/rust/pull/124498 [2] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-15-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: transmute: simplify code with Rust 1.80.0 `split_at_*checked()`Miguel Ojeda1-27/+6
`feature(split_at_checked)` [1] has been stabilized in Rust 1.80.0 [2], which is older than our new minimum Rust version (Rust 1.85.0). Thus simplify the code using `split_at_*checked()`. Link: https://github.com/rust-lang/rust/issues/119128 [1] Link: https://github.com/rust-lang/rust/pull/124678 [2] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-14-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: kbuild: remove `feature(...)`s that are now stableMiguel Ojeda3-28/+1
Now that the Rust minimum version is 1.85.0, there is no need to enable certain features that are stable. Thus clean them up. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-13-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: kbuild: remove skipping of `-Wrustdoc::unescaped_backticks`Miguel Ojeda1-4/+1
Back in Rust 1.82.0, I cleaned the `rustdoc::unescaped_backticks` lint in upstream Rust and added tests so that hopefully it would not regress [1]. Thus we can remove it from our side given the Rust minimum version bump. Link: https://github.com/rust-lang/rust/pull/128307 [1] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-12-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: remove `RUSTC_HAS_COERCE_POINTEE` and simplify codeMiguel Ojeda5-77/+6
With the Rust version bump in place, the `RUSTC_HAS_COERCE_POINTEE` Kconfig (automatic) option is always true. Thus remove the option and simplify the code. In particular, this includes removing our use of the predecessor unstable features we used with Rust < 1.84.0 (`coerce_unsized`, `dispatch_from_dyn` and `unsize`). Reviewed-by: Tamir Duberstein <tamird@kernel.org> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-11-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: remove `RUSTC_HAS_SLICE_AS_FLATTENED` and simplify codeMiguel Ojeda4-56/+0
With the Rust version bump in place, the `RUSTC_HAS_SLICE_AS_FLATTENED` Kconfig (automatic) option is always true. Thus remove the option and simplify the code. In particular, this includes removing the `slice` module which contained the temporary slice helpers, i.e. the `AsFlattened` extension trait and its `impl`s. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-10-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: simplify `RUSTC_VERSION` Kconfig conditionsMiguel Ojeda4-15/+1
With the Rust version bump in place, several Kconfig conditions based on `RUSTC_VERSION` are always true. Thus simplify them. The minimum supported major LLVM version by our new Rust minimum version is now LLVM 18, instead of LLVM 16. However, there are no possible cleanups for `RUSTC_LLVM_VERSION`. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-9-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: allow globally `clippy::incompatible_msrv`Miguel Ojeda2-1/+1
`clippy::incompatible_msrv` is not buying us much, and we discussed allowing it several times in the past. For instance, there was recently another patch sent to `allow` it where needed [1]. While that particular case would not be needed after the minimum version bump to 1.85.0, it is simpler to just allow it to prevent future instances. [ In addition, the lint fired without taking into account the features that have been enabled in a crate [2]. While this was improved in Rust 1.90.0 [3], it would still fire in a case like this patch. ] Thus do so, and remove the last instance of locally allowing it we have in the tree (except the one in the vendored `proc_macro2` crate). Note that we still keep the `msrv` config option in `clippy.toml` since that affects other lints as well. Link: https://lore.kernel.org/rust-for-linux/20260404212831.78971-4-jhubbard@nvidia.com/ [1] Link: https://github.com/rust-lang/rust-clippy/issues/14425 [2] Link: https://github.com/rust-lang/rust-clippy/pull/14433 [3] Link: https://patch.msgid.link/20260405235309.418950-8-ojeda@kernel.org Reviewed-by: Gary Guo <gary@garyguo.net> Reviewed-by: Tamir Duberstein <tamird@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: bump Clippy's MSRV and clean `incompatible_msrv` allowsMiguel Ojeda4-9/+2
Following the Rust compiler bump, we can now update Clippy's MSRV we set in the configuration, which will improve the diagnostics it generates. Thus do so and clean a few of the `allow`s that are not needed anymore. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Acked-by: Danilo Krummrich <dakr@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-7-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: bump Rust minimum supported version to 1.85.0 (Debian Trixie)Miguel Ojeda2-2/+2
As proposed in the past in e.g. LPC 2025 and the Maintainers Summit [1], we are going to follow Debian Stable's Rust versions as our minimum supported version. Debian Trixie was released with a Rust 1.85.0 toolchain [2], which it still uses to this day [3] (i.e. no update to Rust 1.85.1). Debian Trixie's release happened on 2025-08-09 [4], which means that a fair amount of time has passed since its release for kernel developers to upgrade. Thus bump the minimum to the new version. Then, in later commits, clean up most of the workarounds and other bits that this upgrade of the minimum allows us. pin-init was left as-is since the patches come from upstream. And the vendored crates are unmodified, since we do not want to change those. Note that the minimum LLVM major version for Rust 1.85.0 is LLVM 18 (the Rust upstream binaries use LLVM 19.1.7), thus e.g. `RUSTC_LLVM_VERSION` tests can also be updated, but there are no suitable ones to simplify. Ubuntu 25.10 also has a recent enough Rust toolchain [5], and they also provide versioned packages with a Rust 1.85.1 toolchain even back to Ubuntu 22.04 LTS [6]. Link: https://lwn.net/Articles/1050174/ [1] Link: https://www.debian.org/releases/trixie/release-notes/whats-new.en.html#desktops-and-well-known-packages [2] Link: https://packages.debian.org/trixie/rustc [3] Link: https://www.debian.org/releases/trixie/ [4] Link: https://packages.ubuntu.com/search?suite=all&searchon=names&keywords=rustc [5] Link: https://launchpad.net/ubuntu/+source/rustc-1.85 [6] Acked-by: Tamir Duberstein <tamird@kernel.org> Acked-by: Benno Lossin <lossin@kernel.org> Acked-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Acked-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20260405235309.418950-6-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07gpu: nova-core: bindings: remove unneeded `cfg_attr`Miguel Ojeda1-3/+0
These were likely copied from the `bindings` and `uapi` crates, but are unneeded since there are no `cfg(test)`s in the bindings. In addition, the issue that triggered the addition in those crates originally is also fixed in `bindgen` (please see the previous commit). Thus remove them. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20260405235309.418950-5-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: kbuild: remove unneeded old `allow`s for generated layout testsMiguel Ojeda2-8/+0
The issue that required `allow`s for `cfg(test)` code generated by `bindgen` for layout testing was fixed back in `bindgen` 0.60.0 [1], so it could have been removed even before the version bump, but it does not hurt. Thus remove it now. Link: https://github.com/rust-lang/rust-bindgen/pull/2203 [1] Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-4-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: kbuild: remove "`try` keyword" workaround for `bindgen` < 0.59.2Miguel Ojeda1-4/+0
There is a workaround that has not been needed, even already after commit 08ab786556ff ("rust: bindgen: upgrade to 0.65.1"), but it does not hurt. Thus remove it. Reviewed-by: Tamir Duberstein <tamird@kernel.org> Reviewed-by: Gary Guo <gary@garyguo.net> Link: https://patch.msgid.link/20260405235309.418950-3-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07rust: kbuild: remove `--remap-path-prefix` workaroundsMiguel Ojeda1-6/+2
Commit 8cf5b3f83614 ("Revert "kbuild, rust: use -fremap-path-prefix to make paths relative"") removed `--remap-path-prefix` from the build system, so the workarounds are not needed anymore. Thus remove them. Note that the flag has landed again in parallel in this cycle in commit dda135077ecc ("rust: build: remap path to avoid absolute path"), together with `--remap-path-scope=macro` [1]. However, they are gated on `rustc-option-yn, --remap-path-scope=macro`, which means they are both only passed starting with Rust 1.95.0 [2]: `--remap-path-scope` is only stable in Rust 1.95, so use `rustc-option` to detect its presence. This feature has been available as `-Zremap-path-scope` for all versions that we support; however due to bugs in the Rust compiler, it does not work reliably until 1.94. I opted to not enable it for 1.94 as it's just a single version that we missed. In turn, that means the workarounds removed here should not be needed again (even with the flag added again above), since: - `rustdoc` now recognizes the `--remap-path-prefix` flag since Rust 1.81.0 [3] (even if it is still an unstable feature [4]). - The Internal Compiler Error [5] that the comment mentions was fixed in Rust 1.87.0 [6]. We tested that was the case in a previous version of this series by making the workaround conditional [7][8]. ...which are both older versions than Rust 1.95.0. We will still need to skip `--remap-path-scope` for `rustdoc` though, since `rustdoc` does not support that one yet [4]. Link: https://github.com/rust-lang/rust/issues/111540 [1] Link: https://github.com/rust-lang/rust/pull/147611 [2] Link: https://github.com/rust-lang/rust/pull/107099 [3] Link: https://doc.rust-lang.org/nightly/rustdoc/unstable-features.html#--remap-path-prefix-remap-source-code-paths-in-output [4] Link: https://github.com/rust-lang/rust/issues/138520 [5] Link: https://github.com/rust-lang/rust/pull/138556 [6] Link: https://lore.kernel.org/rust-for-linux/20260401114540.30108-9-ojeda@kernel.org/ [7] Link: https://lore.kernel.org/rust-for-linux/20260401114540.30108-10-ojeda@kernel.org/ [8] Link: https://patch.msgid.link/20260405235309.418950-2-ojeda@kernel.org Acked-by: Gary Guo <gary@garyguo.net> Reviewed-by: Tamir Duberstein <tamird@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2026-04-07drm/i915/psr: Do not use pipe_src as borders for SU areaJouni Högander1-11/+19
This far using crtc_state->pipe_src as borders for Selective Update area haven't caused visible problems as drm_rect_width(crtc_state->pipe_src) == crtc_state->hw.adjusted_mode.crtc_hdisplay and drm_rect_height(crtc_state->pipe_src) == crtc_state->hw.adjusted_mode.crtc_vdisplay when pipe scaling is not used. On the other hand using pipe scaling is forcing full frame updates and all the Selective Update area calculations are skipped. Now this improper usage of crtc_state->pipe_src is causing following warnings: <4> [7771.978166] xe 0000:00:02.0: [drm] drm_WARN_ON_ONCE(su_lines % vdsc_cfg->slice_height) after WARN_ON_ONCE was added by commit: "drm/i915/dsc: Add helper for writing DSC Selective Update ET parameters" These warnings are seen when DSC and pipe scaling are enabled simultaneously. This is because on full frame update SU area is improperly set as pipe_src which is not aligned with DSC slice height. Fix these by creating local rectangle using crtc_state->hw.adjusted_mode.crtc_hdisplay and crtc_state->hw.adjusted_mode.crtc_vdisplay. Use this local rectangle as borders for SU area. Fixes: d6774b8c3c58 ("drm/i915: Ensure damage clip area is within pipe area") Cc: <stable@vger.kernel.org> # v6.0+ Signed-off-by: Jouni Högander <jouni.hogander@intel.com> Reviewed-by: Mika Kahola <mika.kahola@intel.com> Link: https://patch.msgid.link/20260327114553.195285-1-jouni.hogander@intel.com (cherry picked from commit da0cdc1c329dd2ff09c41fbbe9fbd9c92c5d2c6e) Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2026-04-07ata: ahci: force 32-bit DMA for JMicron JMB582/JMB585Arthur Husband1-0/+14
The JMicron JMB585 (and JMB582) SATA controllers advertise 64-bit DMA support via the S64A bit in the AHCI CAP register, but their 64-bit DMA implementation is defective. Under sustained I/O, DMA transfers targeting addresses above 4GB silently corrupt data -- writes land at incorrect memory addresses with no errors logged. The failure pattern is similar to the ASMedia ASM1061 (commit 20730e9b2778 ("ahci: add 43-bit DMA address quirk for ASMedia ASM1061 controllers")), which also falsely advertised full 64-bit DMA support. However, the JMB585 requires a stricter 32-bit DMA mask rather than 43-bit, as corruption occurs with any address above 4GB. On the Minisforum N5 Pro specifically, the combination of the JMB585's broken 64-bit DMA with the AMD Family 1Ah (Strix Point) IOMMU causes silent data corruption that is only detectable via checksumming filesystems (BTRFS/ZFS scrub). The corruption occurs when 32-bit IOVA space is exhausted and the kernel transparently switches to 64-bit DMA addresses. Add device-specific PCI ID entries for the JMB582 (0x0582) and JMB585 (0x0585) before the generic JMicron class match, using a new board type that combines AHCI_HFLAG_IGN_IRQ_IF_ERR (preserving existing behavior) with AHCI_HFLAG_32BIT_ONLY to force 32-bit DMA masks. Signed-off-by: Arthur Husband <artmoty@gmail.com> Reviewed-by: Damien Le Moal <dlemoal@kernel.org> Signed-off-by: Niklas Cassel <cassel@kernel.org>
2026-04-07selftests/nolibc: don't skip tests for unimplemented syscalls anymoreThomas Weißschuh1-11/+3
The automatic skipping of tests on ENOSYS returns was introduced in commit 349afc8a52f8 ("selftests/nolibc: skip tests for unimplemented syscalls"). It handled the fact that nolibc would return ENOSYS for many syscall wrappers on riscv32. Nowadays nolibc handles all these correctly, so this logic is not used anymore. To make missing nolibc functionality more obvious fail the tests again if something is not implemented. Revert the mentioned commit again. Signed-off-by: Thomas Weißschuh <linux@weissschuh.net> Acked-by: Willy Tarreau <w@1wt.eu> Link: https://patch.msgid.link/20260406-nolibc-no-skip-enosys-v1-2-c046b1ac7d73@weissschuh.net/
generated by cgit v1.2.3 (git 2.39.0) at 2026-06-06 07:21:16 +0300