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