From: "Gary Guo" <gary@garyguo.net>
To: "Alexandre Courbot" <acourbot@nvidia.com>, "Gary Guo" <gary@garyguo.net>
Cc: "Zhi Wang" <zhiw@nvidia.com>, <rust-for-linux@vger.kernel.org>,
<linux-pci@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
<dakr@kernel.org>, <aliceryhl@google.com>, <bhelgaas@google.com>,
<kwilczynski@kernel.org>, <ojeda@kernel.org>, <boqun@kernel.org>,
<bjorn3_gh@protonmail.com>, <lossin@kernel.org>,
<a.hindborg@kernel.org>, <tmgross@umich.edu>,
<markus.probst@posteo.de>, <cjia@nvidia.com>, <smitra@nvidia.com>,
<ankita@nvidia.com>, <aniketa@nvidia.com>, <kwankhede@nvidia.com>,
<targupta@nvidia.com>, <kjaju@nvidia.com>, <alkumar@nvidia.com>,
<joelagnelf@nvidia.com>, <jhubbard@nvidia.com>,
<zhiwang@kernel.org>, <daniel.almeida@collabora.com>,
<tamird@kernel.org>, <work@onurozkan.dev>
Subject: Re: [PATCH v8 1/1] rust: pci: add extended capability and SR-IOV support
Date: Mon, 24 Aug 2026 12:59:20 +0100 [thread overview]
Message-ID: <DKX5NPH3DNJR.2MADBU37NMZB4@garyguo.net> (raw)
In-Reply-To: <DKX4P05VHT0E.2O8M39SOVBVP2@nvidia.com>
On Mon Aug 24, 2026 at 12:14 PM BST, Alexandre Courbot wrote:
> On Mon Aug 24, 2026 at 7:48 PM JST, Gary Guo wrote:
>> On Mon Aug 24, 2026 at 9:12 AM BST, Alexandre Courbot wrote:
>>> On Tue Aug 18, 2026 at 5:46 PM JST, Zhi Wang wrote:
>>>> Rust PCI drivers have no typed interface for locating and accessing PCIe
>>>> extended capabilities.
>>>>
>>>> The SR-IOV extended capability describes VF topology and VF BARs. Expose
>>>> this information through the Rust PCI abstraction so drivers can use the
>>>> existing typed configuration-space accessors instead of raw bindings.
>>>>
>>>> Define ExtCapability to associate a capability ID with a register layout,
>>>> and add ConfigSpace::find_ext_capability() to locate and project that
>>>> layout. Bound the view at the next capability or the end of extended
>>>> configuration space. Add ExtSriovRegs and a decoded VF BAR iterator that
>>>> reads and validates all six VF BAR register slots up front, yields decoded
>>>> BAR addresses and widths in logical order, and keeps the raw
>>>> configuration-space slot advancement internal. Since PCI_EXT_CAP_NEXT() is
>>>> a function-like macro, expose it through a Rust helper.
>>>>
>>>> Link: https://lore.kernel.org/rust-for-linux/20260804161612.776752-1-zhiw@nvidia.com/
>>>> Cc: Alexandre Courbot <acourbot@nvidia.com>
>>>> Cc: Gary Guo <gary@garyguo.net>
>>>> Signed-off-by: Zhi Wang <zhiw@nvidia.com>
>>>> ---
>>>> rust/helpers/pci.c | 5 +
>>>> rust/kernel/pci.rs | 8 +
>>>> rust/kernel/pci/cap.rs | 329 +++++++++++++++++++++++++++++++++++++++++
>>>> 3 files changed, 342 insertions(+)
>>>> create mode 100644 rust/kernel/pci/cap.rs
>>>>
>>>> diff --git a/rust/helpers/pci.c b/rust/helpers/pci.c
>>>> index 4ebf256dff23..b946b14d79e4 100644
>>>> --- a/rust/helpers/pci.c
>>>> +++ b/rust/helpers/pci.c
>>>> @@ -24,6 +24,11 @@ __rust_helper bool rust_helper_dev_is_pci(const struct device *dev)
>>>> return dev_is_pci(dev);
>>>> }
>>>>
>>>> +__rust_helper u32 rust_helper_pci_ext_cap_next(u32 header)
>>>> +{
>>>> + return PCI_EXT_CAP_NEXT(header);
>>>> +}
>>>> +
>>>> #ifndef CONFIG_PCI_IOV
>>>> __rust_helper unsigned int
>>>> rust_helper_pci_sriov_get_totalvfs(struct pci_dev *pdev)
>>>> diff --git a/rust/kernel/pci.rs b/rust/kernel/pci.rs
>>>> index 9f19ccd5905c..008c2770a3f3 100644
>>>> --- a/rust/kernel/pci.rs
>>>> +++ b/rust/kernel/pci.rs
>>>> @@ -32,10 +32,18 @@
>>>> },
>>>> };
>>>>
>>>> +mod cap;
>>>> mod id;
>>>> mod io;
>>>> mod irq;
>>>>
>>>> +pub use self::cap::{
>>>> + ExtCapId,
>>>> + ExtCapability,
>>>> + ExtSriovCapability,
>>>> + ExtSriovRegs,
>>>> + ExtSriovVfBar, //
>>>> +};
>>>> pub use self::id::{
>>>> Class,
>>>> ClassMask,
>>>> diff --git a/rust/kernel/pci/cap.rs b/rust/kernel/pci/cap.rs
>>>> new file mode 100644
>>>> index 000000000000..ddb3fd73e195
>>>> --- /dev/null
>>>> +++ b/rust/kernel/pci/cap.rs
>>>> @@ -0,0 +1,329 @@
>>>> +// SPDX-License-Identifier: GPL-2.0
>>>> +
>>>> +//! PCI extended capability support.
>>>> +
>>>> +use super::{
>>>> + io::ConfigSpaceBackend,
>>>> + ConfigSpace,
>>>> + Extended, //
>>>> +};
>>>
>>> Let's merge this block with the one below, i.e. using `crate::pci`?
>>>
>>>> +use crate::{
>>>> + bindings,
>>>> + io::{
>>>> + Io,
>>>> + IoBackend,
>>>> + Region, //
>>>> + },
>>>> + num::Bounded,
>>>> + prelude::*,
>>>> +};
>>>> +
>>>> +/// Number of VF BAR register slots in an SR-IOV capability.
>>>> +// CAST: `PCI_SRIOV_NUM_BARS` is the PCIe-specified number of VF BAR register slots and fits in
>>>> +// `usize`.
>>>> +const NUM_VF_BARS: usize = bindings::PCI_SRIOV_NUM_BARS as usize;
>>>
>>> The infallible casts module is now available in `master`. If you import
>>> `crate::num::casts` you can now turn this into
>>>
>>> const NUM_VF_BARS: usize = casts::u32_as_usize(bindings::PCI_SRIOV_NUM_BARS);
>>>
>>> and remove the `CAST` comment.
>>>
>>>> +
>>>> +/// PCI extended capability IDs.
>>>> +#[repr(transparent)]
>>>> +#[derive(Debug, Clone, Copy, PartialEq, Eq)]
>>>> +pub struct ExtCapId(u16);
>>>> +
>>>> +impl ExtCapId {
>>>> + /// Single Root I/O Virtualization.
>>>> + // CAST: PCI extended capability IDs are 16-bit values defined by the PCIe specification.
>>>> + pub const SRIOV: Self = Self(bindings::PCI_EXT_CAP_ID_SRIOV as u16);
>>>
>>> Same here, the `CAST` comment can be removed if you turn this line into
>>>
>>> pub const SRIOV: Self = Self(casts::u32_into_u16::<{ bindings::PCI_EXT_CAP_ID_SRIOV }>());
>>
>> This looks horrible. I'd prefer `as`.
>
> Looks are subjective (or so I like to tell myself), so let's focus on
> what isn't.
>
> What is not subjective is that you don't lose a single bit as long as
> you use these functions, and can do your conversions without a `CAST`
> comment.
Aesthetic and ergnomics is a big part of code, and is what make people like
Rust. In a world where less code is produced by human, I think it's especially
important that code remains easily human readable.
You can probably already tell that I have very strong opinion about this.
>
> These helpers were merged precisely for this use-case; if you want to
> remove them and use `as` instead, that's of course open but also a
> larger discussion than this patch.
I was under impression that the series just provides safe cast from lower width
integer to higher width ones (mostly for u32 -> usize and usize -> u64). If I
see the above snippet, I'd nacked it.
This is not what const generics is designed for and I rather view this as abuse
of language feature.
Best,
Gary
next prev parent reply other threads:[~2026-08-24 11:59 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-18 8:46 [PATCH v8 0/1] Rust PCI capability infrastructure and SR-IOV support Zhi Wang
2026-08-18 8:46 ` [PATCH v8 1/1] rust: pci: add extended capability " Zhi Wang
2026-08-18 8:55 ` sashiko-bot
2026-08-24 8:12 ` Alexandre Courbot
2026-08-24 10:48 ` Gary Guo
2026-08-24 11:14 ` Alexandre Courbot
2026-08-24 11:59 ` Gary Guo [this message]
2026-08-24 15:21 ` Alexandre Courbot
2026-08-24 11:38 ` Danilo Krummrich
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=DKX5NPH3DNJR.2MADBU37NMZB4@garyguo.net \
--to=gary@garyguo.net \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=aliceryhl@google.com \
--cc=alkumar@nvidia.com \
--cc=aniketa@nvidia.com \
--cc=ankita@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun@kernel.org \
--cc=cjia@nvidia.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=jhubbard@nvidia.com \
--cc=joelagnelf@nvidia.com \
--cc=kjaju@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=tamird@kernel.org \
--cc=targupta@nvidia.com \
--cc=tmgross@umich.edu \
--cc=work@onurozkan.dev \
--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.