[PATCH] rust: cpufreq: fix `undocumented_unsafe_blocks` in `PolicyCpu::from_cpu()`

[PATCH] rust: cpufreq: fix `undocumented_unsafe_blocks` in `PolicyCpu::from_cpu()`

[Miguel Ojeda]

For Rust <= 1.86, Clippy triggers after commit 02c5d7bfa872 ("rust:
cpufreq: reject NULL from cpufreq_cpu_get()"):

    warning: unsafe block missing a safety comment
       --> rust/kernel/cpufreq.rs:700:26
        |
    700 |             NonNull::new(unsafe { bindings::cpufreq_cpu_get(u32::from(cpu)) }).ok_or(ENODEV)?;
        |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        |
        = help: consider adding a safety comment on the preceding line
        = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#undocumented_unsafe_blocks
        = note: requested on the command line with `-W clippy::undocumented-unsafe-blocks`

Thus clean it up.

Fixes: 02c5d7bfa872 ("rust: cpufreq: reject NULL from cpufreq_cpu_get()")
Assisted-by: LLM
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
---
 rust/kernel/cpufreq.rs | 8 +++++---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/rust/kernel/cpufreq.rs b/rust/kernel/cpufreq.rs
index b75d692846a2..5f5beedec88b 100644
--- a/rust/kernel/cpufreq.rs
+++ b/rust/kernel/cpufreq.rs
@@ -695,9 +695,11 @@ fn clear_data<T: ForeignOwnable>(&mut self) -> Option<T> {
 
 impl<'a> PolicyCpu<'a> {
     fn from_cpu(cpu: CpuId) -> Result<Self> {
-        // SAFETY: It is safe to call `cpufreq_cpu_get` for any valid CPU.
-        let ptr =
-            NonNull::new(unsafe { bindings::cpufreq_cpu_get(u32::from(cpu)) }).ok_or(ENODEV)?;
+        let ptr = NonNull::new(
+            // SAFETY: It is safe to call `cpufreq_cpu_get` for any valid CPU.
+            unsafe { bindings::cpufreq_cpu_get(u32::from(cpu)) },
+        )
+        .ok_or(ENODEV)?;
 
         Ok(Self(
             // SAFETY: `ptr` is non-NULL and `cpufreq_cpu_get()` took a reference on it, so it is

base-commit: 2efb7a11f1aa4d2dc285fe2680cca22cb9f72f64
-- 
2.56.0

Re: [PATCH] rust: cpufreq: fix `undocumented_unsafe_blocks` in `PolicyCpu::from_cpu()`

[Miguel Ojeda]

On Sun, Oct 18, 2026 at 6:37 PM Miguel Ojeda <ojeda@kernel.org> wrote:
>
> +        let ptr = NonNull::new(
> +            // SAFETY: It is safe to call `cpufreq_cpu_get` for any valid CPU.
> +            unsafe { bindings::cpufreq_cpu_get(u32::from(cpu)) },
> +        )
> +        .ok_or(ENODEV)?;

The other option is to split the statements in two, which probably
looks better, but this shows how to do it without changing the shape
of the code.

Cheers,
Miguel

Re: [PATCH] rust: cpufreq: fix `undocumented_unsafe_blocks` in `PolicyCpu::from_cpu()`

[Zhongqiu Han]

On 10/19/2026 12:37 AM, Miguel Ojeda wrote:
> For Rust <= 1.86, Clippy triggers after commit 02c5d7bfa872 ("rust:
> cpufreq: reject NULL from cpufreq_cpu_get()"):
> 
>      warning: unsafe block missing a safety comment
>         --> rust/kernel/cpufreq.rs:700:26
>          |
>      700 |             NonNull::new(unsafe { bindings::cpufreq_cpu_get(u32::from(cpu)) }).ok_or(ENODEV)?;
>          |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>          |
>          = help: consider adding a safety comment on the preceding line
>          = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#undocumented_unsafe_blocks
>          = note: requested on the command line with `-W clippy::undocumented-unsafe-blocks`
> 
> Thus clean it up.
> 
> Fixes: 02c5d7bfa872 ("rust: cpufreq: reject NULL from cpufreq_cpu_get()")
> Assisted-by: LLM
> Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>

FWIW, splitting it into two statements as you mentioned would read 
better to me.


> ---
>   rust/kernel/cpufreq.rs | 8 +++++---
>   1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/rust/kernel/cpufreq.rs b/rust/kernel/cpufreq.rs
> index b75d692846a2..5f5beedec88b 100644
> --- a/rust/kernel/cpufreq.rs
> +++ b/rust/kernel/cpufreq.rs
> @@ -695,9 +695,11 @@ fn clear_data<T: ForeignOwnable>(&mut self) -> Option<T> {
>   
>   impl<'a> PolicyCpu<'a> {
>       fn from_cpu(cpu: CpuId) -> Result<Self> {
> -        // SAFETY: It is safe to call `cpufreq_cpu_get` for any valid CPU.
> -        let ptr =
> -            NonNull::new(unsafe { bindings::cpufreq_cpu_get(u32::from(cpu)) }).ok_or(ENODEV)?;
> +        let ptr = NonNull::new(
> +            // SAFETY: It is safe to call `cpufreq_cpu_get` for any valid CPU.
> +            unsafe { bindings::cpufreq_cpu_get(u32::from(cpu)) },
> +        )
> +        .ok_or(ENODEV)?;
>   
>           Ok(Self(
>               // SAFETY: `ptr` is non-NULL and `cpufreq_cpu_get()` took a reference on it, so it is
> 
> base-commit: 2efb7a11f1aa4d2dc285fe2680cca22cb9f72f64


-- 
Thx and BRs,
Zhongqiu Han

Re: [PATCH] rust: cpufreq: fix `undocumented_unsafe_blocks` in `PolicyCpu::from_cpu()`

[Viresh Kumar]

On 19-10-26, 12:13, Zhongqiu Han wrote:
> On 10/19/2026 12:37 AM, Miguel Ojeda wrote:
> > For Rust <= 1.86, Clippy triggers after commit 02c5d7bfa872 ("rust:
> > cpufreq: reject NULL from cpufreq_cpu_get()"):
> > 
> >      warning: unsafe block missing a safety comment
> >         --> rust/kernel/cpufreq.rs:700:26
> >          |
> >      700 |             NonNull::new(unsafe { bindings::cpufreq_cpu_get(u32::from(cpu)) }).ok_or(ENODEV)?;
> >          |                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >          |
> >          = help: consider adding a safety comment on the preceding line
> >          = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#undocumented_unsafe_blocks
> >          = note: requested on the command line with `-W clippy::undocumented-unsafe-blocks`
> > 
> > Thus clean it up.
> > 
> > Fixes: 02c5d7bfa872 ("rust: cpufreq: reject NULL from cpufreq_cpu_get()")
> > Assisted-by: LLM
> > Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
> 
> Reviewed-by: Zhongqiu Han <zhongqiu.han@oss.qualcomm.com>
> 
> FWIW, splitting it into two statements as you mentioned would read better to
> me.

I agree.

-- 
viresh