From: Zhi Wang <zhiw@nvidia.com>
To: <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>, <acourbot@nvidia.com>,
<joelagnelf@nvidia.com>, <jhubbard@nvidia.com>,
<zhiwang@kernel.org>, <daniel.almeida@collabora.com>,
Zhi Wang <zhiw@nvidia.com>
Subject: [RFC 1/2] pci: Add fallible I/O methods to ConfigSpace
Date: Mon, 26 Jan 2026 23:59:56 +0200 [thread overview]
Message-ID: <20260126215957.541180-2-zhiw@nvidia.com> (raw)
In-Reply-To: <20260126215957.541180-1-zhiw@nvidia.com>
Rust PCI drivers might need to access device configuration space with
runtime bound check. The existing ConfigSpace abstraction only provides
infallible methods (read8/16/32) that use compile-time bounds checking via
io_addr_assert, which cannot handle dynamic offsets.
Add fallible I/O methods to ConfigSpace.
Signed-off-by: Zhi Wang <zhiw@nvidia.com>
---
rust/kernel/pci/io.rs | 34 +++++++++++++++++++++++++++++++---
1 file changed, 31 insertions(+), 3 deletions(-)
diff --git a/rust/kernel/pci/io.rs b/rust/kernel/pci/io.rs
index 026e7a3b69bd..9fc9af0f9bfc 100644
--- a/rust/kernel/pci/io.rs
+++ b/rust/kernel/pci/io.rs
@@ -112,6 +112,17 @@ macro_rules! call_config_read {
let _ret = unsafe { bindings::$c_fn($self.pdev.as_raw(), $addr as i32, &mut val) };
val
}};
+
+ (fallible, $c_fn:ident, $self:ident, $ty:ty, $addr:expr) => {{
+ let mut val: $ty = 0;
+ // SAFETY: By the type invariant `$self.pdev` is a valid address.
+ let ret = unsafe { bindings::$c_fn($self.pdev.as_raw(), $addr as i32, &mut val) };
+ if ret != 0 {
+ Err(EIO)
+ } else {
+ Ok(val)
+ }
+ }};
}
/// Internal helper macros used to invoke C PCI configuration space write functions.
@@ -140,6 +151,16 @@ macro_rules! call_config_write {
// Return value from C function is ignored in infallible accessors.
let _ret = unsafe { bindings::$c_fn($self.pdev.as_raw(), $addr as i32, $value) };
};
+
+ (fallible, $c_fn:ident, $self:ident, $ty:ty, $addr:expr, $value:expr) => {{
+ // SAFETY: By the type invariant `$self.pdev` is a valid address.
+ let ret = unsafe { bindings::$c_fn($self.pdev.as_raw(), $addr as i32, $value) };
+ if ret != 0 {
+ Err(EIO)
+ } else {
+ Ok(())
+ }
+ }};
}
// PCI configuration space supports 8, 16, and 32-bit accesses.
@@ -162,9 +183,7 @@ fn maxsize(&self) -> usize {
self.pdev.cfg_size().into_raw()
}
- // PCI configuration space does not support fallible operations.
- // The default implementations from the Io trait are not used.
-
+ // Infallible methods with compile-time bounds checking
define_read!(infallible, read8, call_config_read(pci_read_config_byte) -> u8);
define_read!(infallible, read16, call_config_read(pci_read_config_word) -> u16);
define_read!(infallible, read32, call_config_read(pci_read_config_dword) -> u32);
@@ -172,6 +191,15 @@ fn maxsize(&self) -> usize {
define_write!(infallible, write8, call_config_write(pci_write_config_byte) <- u8);
define_write!(infallible, write16, call_config_write(pci_write_config_word) <- u16);
define_write!(infallible, write32, call_config_write(pci_write_config_dword) <- u32);
+
+ // Fallible methods with runtime bounds checking
+ define_read!(fallible, try_read8, call_config_read(pci_read_config_byte) -> u8);
+ define_read!(fallible, try_read16, call_config_read(pci_read_config_word) -> u16);
+ define_read!(fallible, try_read32, call_config_read(pci_read_config_dword) -> u32);
+
+ define_write!(fallible, try_write8, call_config_write(pci_write_config_byte) <- u8);
+ define_write!(fallible, try_write16, call_config_write(pci_write_config_word) <- u16);
+ define_write!(fallible, try_write32, call_config_write(pci_write_config_dword) <- u32);
}
/// Marker trait indicating ConfigSpace has a known size at compile time.
--
2.51.0
next prev parent reply other threads:[~2026-01-26 22:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-26 21:59 [RFC 0/2] Rust PCI capability infrastructure and SR-IOV support Zhi Wang
2026-01-26 21:59 ` Zhi Wang [this message]
2026-01-26 21:59 ` [RFC 2/2] pci: Add PCI capability infrastructure and SR-IOV capability support Zhi Wang
2026-01-27 15:36 ` Gary Guo
2026-02-05 11:57 ` Zhi Wang
2026-02-05 13:10 ` Gary Guo
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=20260126215957.541180-2-zhiw@nvidia.com \
--to=zhiw@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--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=daniel.almeida@collabora.com \
--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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox