From: Joel Fernandes <joelagnelf@nvidia.com>
To: Danilo Krummrich <dakr@kernel.org>
Cc: linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org,
nouveau@lists.freedesktop.org, rust-for-linux@vger.kernel.org,
linux-pci@vger.kernel.org, acourbot@nvidia.com,
"Alistair Popple" <apopple@nvidia.com>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Alex Gaynor" <alex.gaynor@gmail.com>,
"Boqun Feng" <boqun.feng@gmail.com>,
"Gary Guo" <gary@garyguo.net>,
"Björn Roy Baron" <bjorn3_gh@protonmail.com>,
"Benno Lossin" <lossin@kernel.org>,
"Andreas Hindborg" <a.hindborg@kernel.org>,
"Alice Ryhl" <aliceryhl@google.com>,
"Trevor Gross" <tmgross@umich.edu>,
"David Airlie" <airlied@gmail.com>,
"Simona Vetter" <simona@ffwll.ch>,
"John Hubbard" <jhubbard@nvidia.com>,
"Timur Tabi" <ttabi@nvidia.com>,
joel@joelfernandes.org,
"Daniel Almeida" <daniel.almeida@collabora.com>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>
Subject: Re: [PATCH] rust: pci: add PCI interrupt allocation and management support
Date: Wed, 10 Sep 2025 15:02:39 -0400 [thread overview]
Message-ID: <20250910190239.GA727765@joelbox2> (raw)
In-Reply-To: <20250910180955.GA598866@joelbox2>
On Wed, Sep 10, 2025 at 02:09:55PM -0400, Joel Fernandes wrote:
[...]
> > > + /// Allocate IRQ vectors for this PCI device.
> > > + ///
> > > + /// Allocates between `min_vecs` and `max_vecs` interrupt vectors for the device.
> > > + /// The allocation will use MSI-X, MSI, or legacy interrupts based on the `irq_types`
> > > + /// parameter and hardware capabilities. When multiple types are specified, the kernel
> > > + /// will try them in order of preference: MSI-X first, then MSI, then legacy interrupts.
> > > + /// This is called during driver probe.
> > > + ///
> > > + /// # Arguments
> > > + ///
> > > + /// * `min_vecs` - Minimum number of vectors required
> > > + /// * `max_vecs` - Maximum number of vectors to allocate
> > > + /// * `irq_types` - Types of interrupts that can be used
> > > + ///
> > > + /// # Returns
> > > + ///
> > > + /// Returns the number of vectors successfully allocated, or an error if the allocation
> > > + /// fails or cannot meet the minimum requirement.
> > > + ///
> > > + /// # Examples
> > > + ///
> > > + /// ```
> > > + /// // Allocate using any available interrupt type in the order mentioned above.
> > > + /// let nvecs = dev.alloc_irq_vectors(1, 32, IrqTypes::all())?;
> > > + ///
> > > + /// // Allocate MSI or MSI-X only (no legacy interrupts)
> > > + /// let msi_only = IrqTypes::default()
> > > + /// .with(IrqType::Msi)
> > > + /// .with(IrqType::MsiX);
> > > + /// let nvecs = dev.alloc_irq_vectors(4, 16, msi_only)?;
> > > + /// ```
> > > + pub fn alloc_irq_vectors(
> > > + &self,
> > > + min_vecs: u32,
> > > + max_vecs: u32,
> > > + irq_types: IrqTypes,
> > > + ) -> Result<u32> {
> > > + // SAFETY: `self.as_raw` is guaranteed to be a pointer to a valid `struct pci_dev`.
> > > + // `pci_alloc_irq_vectors` internally validates all parameters and returns error codes.
> > > + let ret = unsafe {
> > > + bindings::pci_alloc_irq_vectors(self.as_raw(), min_vecs, max_vecs, irq_types.raw())
> > > + };
> > > +
> > > + to_result(ret)?;
> > > + Ok(ret as u32)
> > > + }
> >
> > This is only valid to be called from the Core context, as it modifies internal
> > fields of the inner struct device.
>
> It is called from core context, the diff format confuses.
> >
> > Also, it would be nice if it would return a new type that can serve as argument
> > for irq_vector(), such that we don't have to rely on random integers.
>
> Makes sense, I will do that.
>
By the way, the "ret" value returned by pci_alloc_irq_vectors() is the number
of vectors, not the vector index. So basically there are 3 numbers that mean
different things:
1. Number of vectors (as returned by alloc_irq_vectors).
2. Index of a vector (passed to pci_irq_vector).
3. The Linux IRQ number (passed to request_irq).
And your point is well taken, in fact even in current code there is
ambiguity: irq_vector() accepts a vector index, where as request_irq()
accepts a Linux IRQ number, which are different numbers. I can try to clean
that up as well but let me know if you had any other thoughts. In fact, I
think Device<device::Bound>::request_irq() pci should just accept IrqRequest?
thanks,
- Joel
next prev parent reply other threads:[~2025-09-10 19:02 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-10 3:54 [PATCH] rust: pci: add PCI interrupt allocation and management support Joel Fernandes
2025-09-10 8:47 ` Danilo Krummrich
2025-09-10 18:09 ` Joel Fernandes
2025-09-10 19:02 ` Joel Fernandes [this message]
2025-09-15 9:48 ` Danilo Krummrich
2025-09-17 11:09 ` Joel Fernandes
2025-09-12 6:41 ` kernel test robot
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=20250910190239.GA727765@joelbox2 \
--to=joelagnelf@nvidia.com \
--cc=a.hindborg@kernel.org \
--cc=acourbot@nvidia.com \
--cc=airlied@gmail.com \
--cc=alex.gaynor@gmail.com \
--cc=aliceryhl@google.com \
--cc=apopple@nvidia.com \
--cc=bhelgaas@google.com \
--cc=bjorn3_gh@protonmail.com \
--cc=boqun.feng@gmail.com \
--cc=dakr@kernel.org \
--cc=daniel.almeida@collabora.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=gary@garyguo.net \
--cc=jhubbard@nvidia.com \
--cc=joel@joelfernandes.org \
--cc=kwilczynski@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=lossin@kernel.org \
--cc=nouveau@lists.freedesktop.org \
--cc=ojeda@kernel.org \
--cc=rust-for-linux@vger.kernel.org \
--cc=simona@ffwll.ch \
--cc=tmgross@umich.edu \
--cc=ttabi@nvidia.com \
/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.