From: "Alexandre Courbot" <acourbot@nvidia.com>
To: "Alexandre Courbot" <acourbot@nvidia.com>,
"Zhi Wang" <zhiw@nvidia.com>, <rust-for-linux@vger.kernel.org>,
<linux-pci@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Cc: <dakr@kernel.org>, <aliceryhl@google.com>, <bhelgaas@google.com>,
<kwilczynski@kernel.org>, <ojeda@kernel.org>,
<alex.gaynor@gmail.com>, <boqun.feng@gmail.com>,
<gary@garyguo.net>, <bjorn3_gh@protonmail.com>,
<lossin@kernel.org>, <a.hindborg@kernel.org>, <tmgross@umich.edu>,
<markus.probst@posteo.de>, <helgaas@kernel.org>,
<cjia@nvidia.com>, <smitra@nvidia.com>, <ankita@nvidia.com>,
<aniketa@nvidia.com>, <kwankhede@nvidia.com>,
<targupta@nvidia.com>, <joelagnelf@nvidia.com>,
<jhubbard@nvidia.com>, <zhiwang@kernel.org>
Subject: Re: [PATCH v7 3/6] rust: io: factor common I/O helpers into Io trait
Date: Tue, 25 Nov 2025 23:14:51 +0900 [thread overview]
Message-ID: <DEHU7A4DWOSX.PZ4CCKLAH9QV@nvidia.com> (raw)
In-Reply-To: <DEHU2XNZ50HW.281CCT1CZ79CF@nvidia.com>
On Tue Nov 25, 2025 at 11:09 PM JST, Alexandre Courbot wrote:
> On Wed Nov 19, 2025 at 8:21 PM JST, Zhi Wang wrote:
> <snip>
>> -impl<const SIZE: usize> Io<SIZE> {
>> - /// Converts an `IoRaw` into an `Io` instance, providing the accessors to the MMIO mapping.
>> - ///
>> - /// # Safety
>> - ///
>> - /// Callers must ensure that `addr` is the start of a valid I/O mapped memory region of size
>> - /// `maxsize`.
>> - pub unsafe fn from_raw(raw: &IoRaw<SIZE>) -> &Self {
>> - // SAFETY: `Io` is a transparent wrapper around `IoRaw`.
>> - unsafe { &*core::ptr::from_ref(raw).cast() }
>> +/// Checks whether an access of type `U` at the given `offset`
>> +/// is valid within this region.
>> +#[inline]
>> +const fn offset_valid<U>(offset: usize, size: usize) -> bool {
>> + let type_size = core::mem::size_of::<U>();
>> + if let Some(end) = offset.checked_add(type_size) {
>> + end <= size && offset % type_size == 0
>> + } else {
>> + false
>> }
>> +}
>> +
>> +/// Represents a region of I/O space of a fixed size.
>> +///
>> +/// Provides common helpers for offset validation and address
>> +/// calculation on top of a base address and maximum size.
>> +///
>> +pub trait Io {
>> + /// Minimum usable size of this region.
>> + const MIN_SIZE: usize;
>
> This associated constant should probably be part of `IoInfallible` -
> otherwise what value should it take if some type only implement
> `IoFallible`?
>
>>
>> /// Returns the base address of this mapping.
>> - #[inline]
>> - pub fn addr(&self) -> usize {
>> - self.0.addr()
>> - }
>> + fn addr(&self) -> usize;
>>
>> /// Returns the maximum size of this mapping.
>> - #[inline]
>> - pub fn maxsize(&self) -> usize {
>> - self.0.maxsize()
>> - }
>> -
>> - #[inline]
>> - const fn offset_valid<U>(offset: usize, size: usize) -> bool {
>> - let type_size = core::mem::size_of::<U>();
>> - if let Some(end) = offset.checked_add(type_size) {
>> - end <= size && offset % type_size == 0
>> - } else {
>> - false
>> - }
>> - }
>> + fn maxsize(&self) -> usize;
>>
>> + /// Returns the absolute I/O address for a given `offset`,
>> + /// performing runtime bound checks.
>> #[inline]
>> fn io_addr<U>(&self, offset: usize) -> Result<usize> {
>> - if !Self::offset_valid::<U>(offset, self.maxsize()) {
>> + if !offset_valid::<U>(offset, self.maxsize()) {
>> return Err(EINVAL);
>> }
>
> Similarly I cannot find any context where `maxsize` and `io_addr` are
> used outside of `IoFallible`, hinting that these should be part of this
> trait.
>
>>
>> @@ -239,50 +240,190 @@ fn io_addr<U>(&self, offset: usize) -> Result<usize> {
>> self.addr().checked_add(offset).ok_or(EINVAL)
>> }
>>
>> + /// Returns the absolute I/O address for a given `offset`,
>> + /// performing compile-time bound checks.
>> #[inline]
>> fn io_addr_assert<U>(&self, offset: usize) -> usize {
>> - build_assert!(Self::offset_valid::<U>(offset, SIZE));
>> + build_assert!(offset_valid::<U>(offset, Self::MIN_SIZE));
>>
>> self.addr() + offset
>> }
>
> ... and `io_addr_assert` is only used from `IoFallible`.
>
> So if my gut feeling is correct, we can disband `Io` entirely and only
... except that we can't due to `addr`, unless we find a better way to
provide this base. But even if we need to keep `Io`, the compile-time
and runtime members should be moved to their respective traits.
next prev parent reply other threads:[~2025-11-25 14:14 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-19 11:21 [PATCH v7 0/6] rust: pci: add config space read/write support Zhi Wang
2025-11-19 11:21 ` [PATCH v7 1/6] samples: rust: rust_driver_pci: use "kernel vertical" style for imports Zhi Wang
2025-11-19 11:21 ` [PATCH v7 2/6] rust: devres: " Zhi Wang
2025-11-19 11:21 ` [PATCH v7 3/6] rust: io: factor common I/O helpers into Io trait Zhi Wang
2025-11-21 14:20 ` Alice Ryhl
2025-11-24 10:08 ` Zhi Wang
2025-11-24 10:20 ` Alice Ryhl
2025-11-24 13:32 ` Zhi Wang
2025-11-24 13:53 ` Alexandre Courbot
2025-11-25 13:44 ` Alexandre Courbot
2025-11-25 14:58 ` Alice Ryhl
2025-11-26 0:43 ` Alexandre Courbot
2025-11-26 7:52 ` Alexandre Courbot
2025-11-26 9:50 ` Alice Ryhl
2025-11-26 13:37 ` Alexandre Courbot
2025-11-26 13:39 ` Alexandre Courbot
2025-12-01 11:57 ` Alexandre Courbot
2025-12-01 12:23 ` Alice Ryhl
2025-12-03 13:32 ` Alexandre Courbot
2025-11-25 14:09 ` Alexandre Courbot
2025-11-25 14:14 ` Alexandre Courbot [this message]
2025-11-25 14:22 ` Alice Ryhl
2025-11-25 14:46 ` Alexandre Courbot
2025-11-25 19:19 ` John Hubbard
2025-11-19 11:21 ` [PATCH v7 4/6] rust: io: factor out MMIO read/write macros Zhi Wang
2025-11-19 11:21 ` [PATCH v7 5/6] rust: pci: add config space read/write support Zhi Wang
2025-11-25 14:20 ` Alexandre Courbot
2025-11-19 11:21 ` [PATCH v7 6/6] sample: rust: pci: add tests for config space routines Zhi Wang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DEHU7A4DWOSX.PZ4CCKLAH9QV@nvidia.com \
--to=acourbot@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=aniketa@nvidia.com \
--cc=ankita@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=cjia@nvidia.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=helgaas@kernel.org \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=kwankhede@nvidia.com \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=markus.probst@posteo.de \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=smitra@nvidia.com \
--cc=targupta@nvidia.com \
--cc=tmgross@umich.edu \
--cc=zhiw@nvidia.com \
--cc=zhiwang@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.