Re: [PATCH v13 7/7] PCI: endpoint: pci-ep-msi: Add embedded doorbell fallback

Koichiro Den <[email protected]> Tue, 7 Apr 2026 23:56:01 +0900
Newsgroups dev.linux.lists.ntb,org.kernel.vger.linux-kernel,org.kernel.vger.linux-pci
Message-ID <7wteqgmnzbkrv5427nwxmjgre3l3vrpvjcubm2bwhr4pkmsqup@a2hrkg33z4ly>
On Tue, Apr 07, 2026 at 05:48:06AM -0400, Frank Li wrote:
> On Tue, Apr 07, 2026 at 12:57:17AM +0900, Koichiro Den wrote:
> > Some endpoint platforms cannot use platform MSI / GIC ITS to implement
> > EP-side doorbells. In those cases, EPF drivers cannot provide an
> > interrupt-driven doorbell and often fall back to polling.
> >
> > Add an "embedded" doorbell backend that uses a controller-integrated
> > doorbell target (e.g. DesignWare integrated eDMA interrupt-emulation
> > doorbell).
> >
> > The backend locates the doorbell register and a corresponding Linux IRQ
> > via the EPC aux-resource API. If the doorbell register is already
> > exposed via a fixed BAR mapping, provide BAR+offset. Otherwise provide
> > the DMA address returned by dma_map_resource() (which may be an IOVA
> > when an IOMMU is enabled) so EPF drivers can map it into BAR space.
> >
> > When MSI doorbell allocation fails with -ENODEV,
> > pci_epf_alloc_doorbell() falls back to this embedded backend.
> >
> > Suggested-by: Manivannan Sadhasivam <[email protected]>
> > Signed-off-by: Koichiro Den <[email protected]>
> > ---
> >
> ...
> > +static int pci_epf_alloc_doorbell_embedded(struct pci_epf *epf, u16 num_db)
> > +{
> > +	const struct pci_epc_aux_resource *doorbell = NULL;
> > +	struct pci_epf_doorbell_msg *msg;
> > +	struct pci_epc *epc = epf->epc;
> > +	size_t map_size = 0, off = 0;
> > +	dma_addr_t iova_base = 0;
> > +	phys_addr_t phys_base;
> > +	int count, ret, i;
> > +	u64 addr;
> > +
> > +	count = pci_epc_get_aux_resources_count(epc, epf->func_no,
> > +						epf->vfunc_no);
> > +	if (count == -EOPNOTSUPP)
> > +		return -ENODEV;
> 
> why need replace error code here ?

Thanks for the comment. I've been somewhat on the fence here, as this conversion
has been in place since v5 without any objections or comments.

I used -ENODEV here as it felt more natural from the caller's point of view,
while -EOPNOTSUPP reflects an EPC-internal detail.

That said, propagating -EOPNOTSUPP should work fine, so this conversion can be
dropped if preferred. Perhaps keeping things simple is better.

Best regards,
Koichiro

> 
> 
> Frank