From: Charalampos Mitrodimas <charmitro@posteo.net>
To: Zijing Zhang <zijing.zhang@ry.rs>
Cc: dakr@kernel.org, ojeda@kernel.org, bhelgaas@google.com,
kwilczynski@kernel.org, boqun.feng@gmail.com, gary@garyguo.net,
bjorn3_gh@protonmail.com, lossin@kernel.org,
a.hindborg@kernel.org, aliceryhl@google.com, tmgross@umich.edu,
linux-pci@vger.kernel.org, rust-for-linux@vger.kernel.org,
linux-kernel@vger.kernel.org, lianux.mm@gmail.com,
zijing.kernel@gmail.com
Subject: Re: [RFC PATCH 0/2] rust: pci: add config space accessors (and a small in-tree user)
Date: Sat, 31 Jan 2026 00:46:39 +0000 [thread overview]
Message-ID: <87sebmzk0i.fsf@posteo.net> (raw)
In-Reply-To: <20260130171026.1138617-1-zijing.zhang@ry.rs>
Zijing Zhang <zijing.zhang@ry.rs> writes:
> This RFC proposes adding basic PCI config space accessors to
> `rust/kernel/pci`.
> It also includes a tiny update to the existing Rust PCI driver sample to
> exercise the new API.
>
> Motivation
> ----------
> Rust PCI drivers occasionally need to access PCI config space (e.g. for
> capability discovery, SR-IOV queries, or MSI-related setup).
>
> Having a small, reviewed API in `kernel::pci` avoids each Rust driver
> growing its own ad-hoc wrappers and error handling around config space.
>
> This RFC is also motivated by the "PCI MISC APIs" TODO item in
> `Documentation/gpu/nova/core/todo.rst`: config space accessors as a first
> step, with capability/MSI/SR-IOV helpers as follow-ups.
>
> Proposed API
> ------------
> Add the following methods to `pci::Device`:
>
> - read_config_u8/u16/u32(offset: u16) -> Result<T>
> - write_config_u8/u16/u32(offset: u16, val: T) -> Result
>
> Notes
> -----
> This is intentionally a thin wrapper: it exposes a safe interface and
> translates errors into `Result`, but it does not try to add policy or extra
> validation.
>
> - No additional range/alignment checks are performed in Rust. If an
> argument needs validation beyond what the C PCI accessors already do,
> it should likely be addressed in the PCI core instead of in a Rust-only
> wrapper.
> - The underlying C helpers may return positive PCIBIOS status codes.
> These are mapped to the corresponding `-errno` values for Rust callers
> (same mapping as `pcibios_err_to_errno()` in `include/linux/pci.h`).
>
> `pcibios_err_to_errno` mapping helper
> -------------------------------------
> The mapping logic is kept as a private helper in the `kernel::pci` module
> rather than inside `Device`: it is not tied to any particular device
> instance and may be reused by future PCI helpers.
>
> Also, the C `pcibios_err_to_errno()` is a `static inline`, so Rust cannot
> call it directly without adding an exported wrapper.
>
> In-tree user
> ------------
> The `samples/rust/rust_driver_pci` sample is updated to read vendor/device
> IDs from config space (0x00/0x02) and print them during probe using
> `dev_dbg!`.
>
> Note: in the current Rust support, `dev_dbg!` does not hook into dynamic
> debug and is compiled out unless Rust debug assertions are enabled.
>
> For local testing, enable `CONFIG_RUST_DEBUG_ASSERTIONS=y` if you want
> to see the `dev_dbg!` line.
>
> Questions for reviewers
> -----------------------
> 1) Does using `u16` for the config-space offset and returning `Result<T>`
> look OK?
IMO using u16 looks good to me, since it covers the full PCIe extended
config space while making negative offsets unrepresentable at the type
level.
> 2) Is mapping PCIBIOS status codes to `-errno` acceptable for Rust callers,
> or would you prefer we add a small exported C wrapper so Rust can reuse
> the existing `pcibios_err_to_errno()` helper directly?
Personally I would prefer a small exported C wrapper. Although the local
re-implementation works, I believe it is an established pattern in the
rust helpers (i.e. to wrap `static inline` helpers), so the Rust side
automatically stays in sync with any changes done in the C side, no
logic duplication etc.
>
> Testing
> -------
> Build:
> - x86_64 defconfig-based kernel with Rust enabled.
> - Out-of-tree build directory (i.e. `make O=...`).
> - Options enabled for this test:
> * CONFIG_SAMPLES_RUST=y
> * CONFIG_SAMPLE_RUST_DRIVER_PCI=y (built-in)
> * CONFIG_RUST_DEBUG_ASSERTIONS=y
>
> Runtime:
> - Booted the resulting bzImage under QEMU x86_64 with:
> * `-device virtio-serial-pci`
> * `-device pci-testdev`
> - Kernel command line included:
> * `loglevel=8`
> - Observed:
> * `pci-testdev data-match count: 1`
> * `Probe Rust PCI driver sample (... cfg: 0x1b36:0x0005).`
Tested-by: Charalampos Mitrodimas <charmitro@posteo.net>
[ 0.176714] rust_driver_pci 0000:00:02.0: Probe Rust PCI driver sample (PCI ID: REDHAT, 0x5; cfg: 0x1b36:0x0005).
[ 0.176727] rust_driver_pci 0000:00:02.0: enabling device (0000 -> 0002)
[ 0.177100] rust_driver_pci 0000:00:02.0: pci-testdev data-match count: 1
Cheers,
C. Mitrodimas
>
> Zijing Zhang (2):
> rust: pci: add config space accessors
> samples: rust: pci: exercise config space accessors
>
> rust/kernel/pci.rs | 86 +++++++++++++++++++++++++++++++++
> samples/rust/rust_driver_pci.rs | 8 ++-
> 2 files changed, 92 insertions(+), 2 deletions(-)
next prev parent reply other threads:[~2026-01-31 0:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-30 17:10 [RFC PATCH 0/2] rust: pci: add config space accessors (and a small in-tree user) Zijing Zhang
2026-01-30 17:10 ` [RFC PATCH 1/2] rust: pci: add config space accessors Zijing Zhang
2026-01-30 17:10 ` [RFC PATCH 2/2] samples: rust: pci: exercise " Zijing Zhang
2026-01-31 0:46 ` Charalampos Mitrodimas [this message]
2026-01-31 2:18 ` [RFC PATCH 0/2] rust: pci: add config space accessors (and a small in-tree user) Zijing Zhang
2026-01-31 2:25 ` Charalampos Mitrodimas
2026-01-31 0:55 ` Gary Guo
2026-01-31 1:03 ` Alexandre Courbot
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=87sebmzk0i.fsf@posteo.net \
--to=charmitro@posteo.net \
--cc=a.hindborg@kernel.org \
--cc=aliceryhl@google.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=gary@garyguo.net \
--cc=kwilczynski@kernel.org \
--cc=lianux.mm@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=tmgross@umich.edu \
--cc=zijing.kernel@gmail.com \
--cc=zijing.zhang@ry.rs \
/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