linux-stable.git/rust/kernel, branch linux-6.17.y Linux kernel stable tree rust: devres: fix private intra-doc link 2025-11-13T20:37:39+00:00 Miguel Ojeda ojeda@kernel.org 2025-10-29T07:14:06+00:00 e033d62c353b15be9538890264a30f2dd10c74e6 commit ff4d2ef3874773c9c6173b0f099372bf62252aaf upstream. The future move of pin-init to `syn` uncovers the following private intra-doc link: error: public documentation for `Devres` links to private item `Self::inner` --> rust/kernel/devres.rs:106:7 | 106 | /// [`Self::inner`] is guaranteed to be initialized and is always accessed read-only. | ^^^^^^^^^^^ this item is private | = note: this link will resolve properly if you pass `--document-private-items` = note: `-D rustdoc::private-intra-doc-links` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(rustdoc::private_intra_doc_links)]` Currently, when rendered, the link points to "nowhere" (an inexistent anchor for a "method"). Thus fix it. Cc: stable@vger.kernel.org Fixes: f5d3ef25d238 ("rust: devres: get rid of Devres' inner Arc") Acked-by: Danilo Krummrich <dakr@kernel.org> Link: https://patch.msgid.link/20251029071406.324511-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit ff4d2ef3874773c9c6173b0f099372bf62252aaf upstream.

The future move of pin-init to `syn` uncovers the following private
intra-doc link:

    error: public documentation for `Devres` links to private item `Self::inner`
       --> rust/kernel/devres.rs:106:7
        |
    106 | /// [`Self::inner`] is guaranteed to be initialized and is always accessed read-only.
        |       ^^^^^^^^^^^ this item is private
        |
        = note: this link will resolve properly if you pass `--document-private-items`
        = note: `-D rustdoc::private-intra-doc-links` implied by `-D warnings`
        = help: to override `-D warnings` add `#[allow(rustdoc::private_intra_doc_links)]`

Currently, when rendered, the link points to "nowhere" (an inexistent
anchor for a "method").

Thus fix it.

Cc: stable@vger.kernel.org
Fixes: f5d3ef25d238 ("rust: devres: get rid of Devres' inner Arc")
Acked-by: Danilo Krummrich <dakr@kernel.org>
Link: https://patch.msgid.link/20251029071406.324511-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: condvar: fix broken intra-doc link 2025-11-13T20:37:39+00:00 Miguel Ojeda ojeda@kernel.org 2025-10-29T07:33:44+00:00 923ffdc63503723936cf9c53bb08d1c9f8fc3883 commit 09b1704f5b02c18dd02b21343530463fcfc92c54 upstream. The future move of pin-init to `syn` uncovers the following broken intra-doc link: error: unresolved link to `crate::pin_init` --> rust/kernel/sync/condvar.rs:39:40 | 39 | /// instances is with the [`pin_init`](crate::pin_init!) and [`new_condvar`] macros. | ^^^^^^^^^^^^^^^^ no item named `pin_init` in module `kernel` | = note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(rustdoc::broken_intra_doc_links)]` Currently, when rendered, the link points to a literal `crate::pin_init!` URL. Thus fix it. Cc: stable@vger.kernel.org Fixes: 129e97be8e28 ("rust: pin-init: fix documentation links") Reviewed-by: Alice Ryhl <aliceryhl@google.com> Link: https://patch.msgid.link/20251029073344.349341-1-ojeda@kernel.org Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 09b1704f5b02c18dd02b21343530463fcfc92c54 upstream.

The future move of pin-init to `syn` uncovers the following broken
intra-doc link:

    error: unresolved link to `crate::pin_init`
      --> rust/kernel/sync/condvar.rs:39:40
       |
    39 | /// instances is with the [`pin_init`](crate::pin_init!) and [`new_condvar`] macros.
       |                                        ^^^^^^^^^^^^^^^^ no item named `pin_init` in module `kernel`
       |
       = note: `-D rustdoc::broken-intra-doc-links` implied by `-D warnings`
       = help: to override `-D warnings` add `#[allow(rustdoc::broken_intra_doc_links)]`

Currently, when rendered, the link points to a literal `crate::pin_init!`
URL.

Thus fix it.

Cc: stable@vger.kernel.org
Fixes: 129e97be8e28 ("rust: pin-init: fix documentation links")
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Link: https://patch.msgid.link/20251029073344.349341-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: kunit: allow `cfg` on `test`s 2025-11-13T20:36:51+00:00 Kaibo Ma ent3rm4n@gmail.com 2025-09-16T02:12:56+00:00 9f1229c8f164f823c268317767af7e63cf5d81d0 [ Upstream commit c652dc44192d96820d73a7ecd89d275ca7e4355d ] The `kunit_test` proc macro only checks for the `test` attribute immediately preceding a `fn`. If the function is disabled via a `cfg`, the generated code would result in a compile error referencing a non-existent function [1]. This collects attributes and specifically cherry-picks `cfg` attributes to be duplicated inside KUnit wrapper functions such that a test function disabled via `cfg` compiles and is marked as skipped in KUnit correctly. Link: https://lore.kernel.org/r/20250916021259.115578-1-ent3rm4n@gmail.com Link: https://lore.kernel.org/rust-for-linux/CANiq72==48=69hYiDo1321pCzgn_n1_jg=ez5UYXX91c+g5JVQ@mail.gmail.com/ [1] Closes: https://github.com/Rust-for-Linux/linux/issues/1185 Suggested-by: Miguel Ojeda <ojeda@kernel.org> Suggested-by: David Gow <davidgow@google.com> Signed-off-by: Kaibo Ma <ent3rm4n@gmail.com> Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit c652dc44192d96820d73a7ecd89d275ca7e4355d ]

The `kunit_test` proc macro only checks for the `test` attribute
immediately preceding a `fn`. If the function is disabled via a `cfg`,
the generated code would result in a compile error referencing a
non-existent function [1].

This collects attributes and specifically cherry-picks `cfg` attributes
to be duplicated inside KUnit wrapper functions such that a test function
disabled via `cfg` compiles and is marked as skipped in KUnit correctly.

Link: https://lore.kernel.org/r/20250916021259.115578-1-ent3rm4n@gmail.com
Link: https://lore.kernel.org/rust-for-linux/CANiq72==48=69hYiDo1321pCzgn_n1_jg=ez5UYXX91c+g5JVQ@mail.gmail.com/ [1]
Closes: https://github.com/Rust-for-Linux/linux/issues/1185
Suggested-by: Miguel Ojeda <ojeda@kernel.org>
Suggested-by: David Gow <davidgow@google.com>
Signed-off-by: Kaibo Ma <ent3rm4n@gmail.com>
Reviewed-by: David Gow <davidgow@google.com>
Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
rust: device: fix device context of Device::parent() 2025-10-29T13:10:22+00:00 Danilo Krummrich dakr@kernel.org 2025-10-16T13:31:44+00:00 2b55b5be1d6cb0cd6f4e50e8a1b3590e366bc33d commit cfec502b3d091ff7c24df6ccf8079470584315a0 upstream. Regardless of the DeviceContext of a device, we can't give any guarantees about the DeviceContext of its parent device. This is very subtle, since it's only caused by a simple typo, i.e. Self::from_raw(parent) which preserves the DeviceContext in this case, vs. Device::from_raw(parent) which discards the DeviceContext. (I should have noticed it doing the correct thing in auxiliary::Device subsequently, but somehow missed it.) Hence, fix both Device::parent() and auxiliary::Device::parent(). Cc: stable@vger.kernel.org Fixes: a4c9f71e3440 ("rust: device: implement Device::parent()") Reviewed-by: Alice Ryhl <aliceryhl@google.com> Reviewed-by: Alexandre Courbot <acourbot@nvidia.com> Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit cfec502b3d091ff7c24df6ccf8079470584315a0 upstream.

Regardless of the DeviceContext of a device, we can't give any
guarantees about the DeviceContext of its parent device.

This is very subtle, since it's only caused by a simple typo, i.e.

	 Self::from_raw(parent)

which preserves the DeviceContext in this case, vs.

	 Device::from_raw(parent)

which discards the DeviceContext.

(I should have noticed it doing the correct thing in auxiliary::Device
subsequently, but somehow missed it.)

Hence, fix both Device::parent() and auxiliary::Device::parent().

Cc: stable@vger.kernel.org
Fixes: a4c9f71e3440 ("rust: device: implement Device::parent()")
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Alexandre Courbot <acourbot@nvidia.com>
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: cpufreq: fix formatting 2025-10-23T14:24:38+00:00 Miguel Ojeda ojeda@kernel.org 2025-10-10T17:43:51+00:00 6aaf1745859f91ee78b9a477d92b1387476b92a6 [ Upstream commit 32f072d9eaf9c31c2b0527a4a3370570a731e3cc ] We do our best to keep the repository `rustfmt`-clean, thus run the tool to fix the formatting issue. Link: https://docs.kernel.org/rust/coding-guidelines.html#style-formatting Link: https://rust-for-linux.com/contributing#submit-checklist-addendum Fixes: f97aef092e19 ("cpufreq: Make drivers using CPUFREQ_ETERNAL specify transition latency") Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Benno Lossin <lossin@kernel.org> Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 32f072d9eaf9c31c2b0527a4a3370570a731e3cc ]

We do our best to keep the repository `rustfmt`-clean, thus run the tool
to fix the formatting issue.

Link: https://docs.kernel.org/rust/coding-guidelines.html#style-formatting
Link: https://rust-for-linux.com/contributing#submit-checklist-addendum
Fixes: f97aef092e19 ("cpufreq: Make drivers using CPUFREQ_ETERNAL specify transition latency")
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Reviewed-by: Benno Lossin <lossin@kernel.org>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
cpufreq: Make drivers using CPUFREQ_ETERNAL specify transition latency 2025-10-19T14:37:00+00:00 Rafael J. Wysocki rafael.j.wysocki@intel.com 2025-09-26T10:12:37+00:00 509c344cdfd314b26914b2ccb117e78d7e01eb15 commit f97aef092e199c10a3da96ae79b571edd5362faa upstream. Commit a755d0e2d41b ("cpufreq: Honour transition_latency over transition_delay_us") caused platforms where cpuinfo.transition_latency is CPUFREQ_ETERNAL to get a very large transition latency whereas previously it had been capped at 10 ms (and later at 2 ms). This led to a user-observable regression between 6.6 and 6.12 as described by Shawn: "The dbs sampling_rate was 10000 us on 6.6 and suddently becomes 6442450 us (4294967295 / 1000 * 1.5) on 6.12 for these platforms because the default transition delay was dropped [...]. It slows down dbs governor's reacting to CPU loading change dramatically. Also, as transition_delay_us is used by schedutil governor as rate_limit_us, it shows a negative impact on device idle power consumption, because the device gets slightly less time in the lowest OPP." Evidently, the expectation of the drivers using CPUFREQ_ETERNAL as cpuinfo.transition_latency was that it would be capped by the core, but they may as well return a default transition latency value instead of CPUFREQ_ETERNAL and the core need not do anything with it. Accordingly, introduce CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS and make all of the drivers in question use it instead of CPUFREQ_ETERNAL. Also update the related Rust binding. Fixes: a755d0e2d41b ("cpufreq: Honour transition_latency over transition_delay_us") Closes: https://lore.kernel.org/linux-pm/20250922125929.453444-1-shawnguo2@yeah.net/ Reported-by: Shawn Guo <shawnguo@kernel.org> Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org> Reviewed-by: Jie Zhan <zhanjie9@hisilicon.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Cc: 6.6+ <stable@vger.kernel.org> # 6.6+ Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://patch.msgid.link/2264949.irdbgypaU6@rafael.j.wysocki [ rjw: Fix typo in new symbol name, drop redundant type cast from Rust binding ] Tested-by: Shawn Guo <shawnguo@kernel.org> # with cpufreq-dt driver Reviewed-by: Qais Yousef <qyousef@layalina.io> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit f97aef092e199c10a3da96ae79b571edd5362faa upstream.

Commit a755d0e2d41b ("cpufreq: Honour transition_latency over
transition_delay_us") caused platforms where cpuinfo.transition_latency
is CPUFREQ_ETERNAL to get a very large transition latency whereas
previously it had been capped at 10 ms (and later at 2 ms).

This led to a user-observable regression between 6.6 and 6.12 as
described by Shawn:

"The dbs sampling_rate was 10000 us on 6.6 and suddently becomes
 6442450 us (4294967295 / 1000 * 1.5) on 6.12 for these platforms
 because the default transition delay was dropped [...].

 It slows down dbs governor's reacting to CPU loading change
 dramatically.  Also, as transition_delay_us is used by schedutil
 governor as rate_limit_us, it shows a negative impact on device
 idle power consumption, because the device gets slightly less time
 in the lowest OPP."

Evidently, the expectation of the drivers using CPUFREQ_ETERNAL as
cpuinfo.transition_latency was that it would be capped by the core,
but they may as well return a default transition latency value instead
of CPUFREQ_ETERNAL and the core need not do anything with it.

Accordingly, introduce CPUFREQ_DEFAULT_TRANSITION_LATENCY_NS and make
all of the drivers in question use it instead of CPUFREQ_ETERNAL.  Also
update the related Rust binding.

Fixes: a755d0e2d41b ("cpufreq: Honour transition_latency over transition_delay_us")
Closes: https://lore.kernel.org/linux-pm/20250922125929.453444-1-shawnguo2@yeah.net/
Reported-by: Shawn Guo <shawnguo@kernel.org>
Reviewed-by: Mario Limonciello (AMD) <superm1@kernel.org>
Reviewed-by: Jie Zhan <zhanjie9@hisilicon.com>
Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
Cc: 6.6+ <stable@vger.kernel.org> # 6.6+
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Link: https://patch.msgid.link/2264949.irdbgypaU6@rafael.j.wysocki
[ rjw: Fix typo in new symbol name, drop redundant type cast from Rust binding ]
Tested-by: Shawn Guo <shawnguo@kernel.org> # with cpufreq-dt driver
Reviewed-by: Qais Yousef <qyousef@layalina.io>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: cpumask: Mark CpumaskVar as transparent 2025-10-15T10:03:19+00:00 Baptiste Lepers baptiste.lepers@gmail.com 2025-08-12T14:42:11+00:00 ffe015e8e3f681ca59694da4e56ab873ebd092e3 [ Upstream commit 23fca458f6ab18927e50c2134fb7b60297f18b4e ] Unsafe code in CpumaskVar's methods assumes that the type has the same layout as `bindings::cpumask_var_t`. This is not guaranteed by the default struct representation in Rust, but requires specifying the `transparent` representation. Fixes: 8961b8cb3099a ("rust: cpumask: Add initial abstractions") Signed-off-by: Baptiste Lepers <baptiste.lepers@gmail.com> Reviewed-by: Alice Ryhl <aliceryhl@google.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Sasha Levin <sashal@kernel.org> 
[ Upstream commit 23fca458f6ab18927e50c2134fb7b60297f18b4e ]

Unsafe code in CpumaskVar's methods assumes that the type has the same
layout as `bindings::cpumask_var_t`. This is not guaranteed by
the default struct representation in Rust, but requires specifying the
`transparent` representation.

Fixes: 8961b8cb3099a ("rust: cpumask: Add initial abstractions")
Signed-off-by: Baptiste Lepers <baptiste.lepers@gmail.com>
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: Sasha Levin <sashal@kernel.org>
rust: pci: fix incorrect platform reference in PCI driver unbind doc comment 2025-10-12T11:01:55+00:00 Rahul Rameshbabu sergeantsagara@protonmail.com 2025-09-14T03:19:19+00:00 32df3ad0dbfbcd0f201df445ed1a6b6567056685 commit a404d099554d17206d1f283c9a91f0616324f691 upstream. Substitute 'platform' with 'pci'. Fixes: 18ebb25dfa18 ("rust: pci: implement Driver::unbind()") Cc: stable@kernel.org Signed-off-by: Rahul Rameshbabu <sergeantsagara@protonmail.com> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit a404d099554d17206d1f283c9a91f0616324f691 upstream.

Substitute 'platform' with 'pci'.

Fixes: 18ebb25dfa18 ("rust: pci: implement Driver::unbind()")
Cc: stable@kernel.org
Signed-off-by: Rahul Rameshbabu <sergeantsagara@protonmail.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: pci: fix incorrect platform reference in PCI driver probe doc comment 2025-10-12T11:01:55+00:00 Rahul Rameshbabu sergeantsagara@protonmail.com 2025-09-14T03:18:34+00:00 c5828784c5b751bafec401f33eebee1ef44ef479 commit 855318e7c0c4a3e3014c0469dd5bc93a1c0df30c upstream. Substitute 'platform' with 'pci'. Fixes: 1bd8b6b2c5d3 ("rust: pci: add basic PCI device / driver abstractions") Cc: stable@kernel.org Signed-off-by: Rahul Rameshbabu <sergeantsagara@protonmail.com> Signed-off-by: Danilo Krummrich <dakr@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 855318e7c0c4a3e3014c0469dd5bc93a1c0df30c upstream.

Substitute 'platform' with 'pci'.

Fixes: 1bd8b6b2c5d3 ("rust: pci: add basic PCI device / driver abstractions")
Cc: stable@kernel.org
Signed-off-by: Rahul Rameshbabu <sergeantsagara@protonmail.com>
Signed-off-by: Danilo Krummrich <dakr@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rust: block: fix `srctree/` links 2025-10-12T11:01:55+00:00 Miguel Ojeda ojeda@kernel.org 2025-07-30T13:07:14+00:00 a7452ec64a263ae6c25bed8e7d46fdaa033bf803 commit 208d7f788e84e80992d7b1c82ff17b620eb1371e upstream. This `srctree/` link pointed to a file with an underscore, but the header used a dash instead. Thus fix it. This cleans a future warning that will check our `srctree/` links. Cc: stable@vger.kernel.org Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module") Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com> Signed-off-by: Miguel Ojeda <ojeda@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 
commit 208d7f788e84e80992d7b1c82ff17b620eb1371e upstream.

This `srctree/` link pointed to a file with an underscore, but the header
used a dash instead.

Thus fix it.

This cleans a future warning that will check our `srctree/` links.

Cc: stable@vger.kernel.org
Fixes: 3253aba3408a ("rust: block: introduce `kernel::block::mq` module")
Reviewed-by: Daniel Almeida <daniel.almeida@collabora.com>
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>