[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aU0Fx_w6ZSi-I7UQ@tardis-2.local>
Date: Thu, 25 Dec 2025 17:37:11 +0800
From: Boqun Feng <boqun.feng@...il.com>
To: Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
Cc: FUJITA Tomonori <fujita.tomonori@...il.com>,
Danilo Krummrich <dakr@...nel.org>,
Bjorn Helgaas <bhelgaas@...gle.com>,
Miguel Ojeda <ojeda@...nel.org>, Gary Guo <gary@...yguo.net>,
Björn Roy Baron <bjorn3_gh@...tonmail.com>,
Benno Lossin <lossin@...nel.org>,
Andreas Hindborg <a.hindborg@...nel.org>,
Alice Ryhl <aliceryhl@...gle.com>, Trevor Gross <tmgross@...ch.edu>,
Joel Fernandes <joelagnelf@...dia.com>, linux-pci@...r.kernel.org,
linux-kernel@...r.kernel.org, rust-for-linux@...r.kernel.org
Subject: Re: [PATCH] PCI: Provide pci_free_irq_vectors() for CONFIG_PCI=n
On Thu, Dec 25, 2025 at 10:10:04AM +0100, Miguel Ojeda wrote:
> On Mon, Dec 15, 2025 at 3:54 AM Boqun Feng <boqun.feng@...il.com> wrote:
> >
> > Commit 473b9f331718 ("rust: pci: fix build failure when CONFIG_PCI_MSI
> > is disabled") fixed a build error by providing rust helpers when
> > CONFIG_PCI_MSI=n. However the rust helpers rely on the
> > pci_alloc_irq_vectors() function is defined, which is not true when
> > CONFIG_PCI=n. There are multiple ways to fix this, e.g. a possible fix
> > could be just remove the calling of pci_alloc_irq_vectors() since it's
> > empty when CONFIG_PCI_MSI=n anyway. However, since PCI irq APIs, such as
> > pci_alloc_irq_vectors(), are already defined even when CONFIG_PCI=n, the
> > more reasonable fix is to define pci_alloc_irq_vectors() when
> > CONFIG_PCI=n and this aligns with the situations of other primitives as
> > well.
> >
> > Fixes: 473b9f331718 ("rust: pci: fix build failure when CONFIG_PCI_MSI is disabled")
> > Signed-off-by: Boqun Feng <boqun.feng@...il.com>
>
> Related: https://lore.kernel.org/rust-for-linux/20251209014312.575940-1-fujita.tomonori@gmail.com/
>
Thanks! I was missing that, and I should have replied Tomo's patch.
> I guess it counts as a report, so we may want a Reported-by (Cc'ing Tomo).
>
Tomo, how do you feel about two fix approaches? I think providing dummy
pci_free_irq_vectors() is better because it's easier and aligned with
other pci_*() APIs.
Regards,
Boqun
> Cheers,
> Miguel
Powered by blists - more mailing lists