Re: [PATCH v2] rust: io: convert ResourceSize into a transparent newtype

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Incomplete API Implementation: PCI FFI boundary methods continue to return raw `bindings::resource_size_t` instead of the typed `ResourceSize` API.
- [Low] Incorrect import order for `core::num::TryFromIntError` violating kernel guidelines.
--

--- Patch [1]: [PATCH v2] rust: io: convert ResourceSize into a transparent newtype ---
commit b81b66fe76cbe9487443105d289e399a714dd21d
Author: Lorenzo Delgado <lnsdev@proton.me>

rust: io: convert ResourceSize into a transparent newtype

This patch wraps ResourceSize in a #[repr(transparent)] newtype to prevent
unintended integer operations and truncating casts. It provides explicit
boundary conversions and updates existing producers and consumers to use the
new typed API.

Link: https://github.com/Rust-for-Linux/linux/issues/1203

> Wrap it in a `#[repr(transparent)]` newtype so each conversion at a
> boundary becomes explicit and reviewable. The representation is
> unchanged, so this is ABI-identical; only the spelling at the FFI
> boundary changes. Provide the conversion surface `from_raw`/`into_raw`,
> `From` in both directions, and a fallible `TryFrom<ResourceSize> for
> usize` for checked narrowing. Update the two producers, `Resource::size`
> and `SGEntry::dma_len`, and the `request_region` consumer. In nova-core,

[Severity: Medium]
Does this miss other producers in the FFI boundary?

Looking at rust/kernel/pci.rs, both resource_start() and resource_len()
continue to return the raw bindings::resource_size_t type rather than the
new ResourceSize type.

Should these functions also be updated to return the new ResourceSize
type to ensure the API remains consistent and fully protected against
implicit casts across the subsystem?

> diff --git a/rust/kernel/io.rs b/rust/kernel/io.rs
> index fcc7678fd9e3c..ebf00b4536d6d 100644
> --- a/rust/kernel/io.rs
> +++ b/rust/kernel/io.rs
> @@ -6,9 +6,12 @@
>  
>  use crate::{
>      bindings,
> +    fmt,
>      prelude::*, //
>  };
>  
> +use core::num::TryFromIntError;

[Severity: Low]
This isn't a bug, but should the core import be placed before the crate
imports?

The kernel's Rust coding guidelines typically require vertical imports
where core and alloc are grouped together and placed before kernel (or crate)
imports.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260719200945.687904-1-lnsdev@proton.me?part=1