kernel/linux.git/drivers/pci/endpoint, branch v7.2-rc2

PCI: endpoint: pci-epf-vntb: Implement .db_vector_count()/mask() for doorbells

2026-06-23T16:37:27+00:00

Implement .db_vector_count() and .db_vector_mask() so NTB core/clients can map doorbell events to per-vector work and avoid the thundering-herd behavior. pci-epf-vntb reserves two slots in db_count: slot 0 for link events and slot 1 which is historically unused. Therefore the number of doorbell vectors is (db_count - 2). Report vectors as 0..N-1 and return BIT_ULL(db_vector) for the corresponding doorbell bit. Build db_valid_mask from a validated vector count so out-of-range db_count values cannot create invalid shifts. Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260513024923.451765-8-den@valinux.co.jp

PCI: endpoint: pci-epf-vntb: Exclude reserved slots from db_valid_mask

2026-06-23T15:41:47+00:00

In pci-epf-vntb, db_count represents the total number of doorbell slots exposed to the peer, including: - slot #0 reserved for link events, and - slot #1 historically unused (kept for compatibility). Only the remaining slots correspond to actual doorbell bits. The current db_valid_mask() exposes all slots as valid doorbells. Limit db_valid_mask() to the real doorbell bits by returning BIT_ULL(db_count - 2) - 1, and guard against db_count < 2. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260513024923.451765-7-den@valinux.co.jp

PCI: endpoint: pci-epf-vntb: Guard configfs writes after EPC attach

2026-06-22T20:31:11+00:00

db_count controls how many doorbell slots are allocated and exposed. It is also used by the doorbell mask helpers. After an EPC has been attached, changing it from configfs can leave runtime paths using a different count than the one used to set up the doorbell resources. Reject db_count writes after EPC attach, and reject values outside MIN_DB_COUNT..MAX_DB_COUNT before attach. Now that MIN_DB_COUNT documents the usable doorbell floor, use it in the store path too. While at it, apply the same after-attach guard to the other vNTB configfs knobs. BAR choices, spad_count, memory-window counts and sizes, and the virtual PCI IDs are also consumed during bind, so changing them later at runtime is meaningless and unsafe. Return -EOPNOTSUPP for after-attach writes. The value itself may be valid, but changing it in that state is not supported. Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260513024923.451765-6-den@valinux.co.jp

PCI: endpoint: pci-epf-vntb: Reject unusable doorbell counts

2026-06-22T20:31:11+00:00

pci-epf-vntb reserves slot 0 for link events and keeps slot 1 unused for legacy layout compatibility. A db_count smaller than MIN_DB_COUNT leaves no usable doorbell slot after those reservations. Reject such configurations when configuring interrupts. While at it, move MAX_DB_COUNT next to MIN_DB_COUNT. They are used as a pair in the range check, and keeping them together makes the valid doorbell range easier to read. Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260513024923.451765-5-den@valinux.co.jp

PCI: endpoint: pci-epf-vntb: Report 0-based doorbell vector via ntb_db_event()

2026-06-22T20:31:11+00:00

ntb_db_event() expects the vector number to be relative to the first doorbell vector starting at 0. pci-epf-vntb reserves vector 0 for link events and uses higher vector indices for doorbells. By passing the raw slot index to ntb_db_event(), it effectively assumes that doorbell 0 maps to vector 1. However, because the host uses a legacy slot layout and writes doorbell 0 into the third slot, doorbell 0 ultimately appears as vector 2 from the NTB core perspective. Adjust pci-epf-vntb to: - skip the unused second slot, and - report doorbells as 0-based vectors (DB#0 -> vector 0). This change does not introduce a behavioral difference until .db_vector_count()/.db_vector_mask() are implemented, because without those callbacks NTB clients effectively ignore the vector number. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260513024923.451765-4-den@valinux.co.jp

PCI: endpoint: pci-epf-vntb: Defer pci_epc_raise_irq() out of atomic context

2026-06-22T20:31:11+00:00

The NTB .peer_db_set() callback may be invoked from atomic context. pci-epf-vntb currently calls pci_epc_raise_irq() directly, but pci_epc_raise_irq() may sleep (it takes epc->lock). Avoid sleeping in atomic context by coalescing doorbell bits into an atomic64 pending mask and raising MSIs from a work item. Limit the amount of work per run to avoid monopolizing the workqueue under a doorbell storm. Clear stale pending bits before enabling the work item and after disabling it during cleanup. Also mask requested doorbells against the currently valid doorbell mask before queueing work, and iterate the pending u64 with __ffs64() so high doorbell bits are handled correctly. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260513024923.451765-3-den@valinux.co.jp

PCI: endpoint: pci-epf-vntb: Document legacy MSI doorbell offset

2026-06-22T20:31:10+00:00

vntb_epf_peer_db_set() raises an MSI interrupt to notify the RC side of a doorbell event. pci_epc_raise_irq(..., PCI_IRQ_MSI, interrupt_num) takes a 1-based MSI interrupt number. The ntb_hw_epf driver reserves MSI #1 for link events, so doorbells would naturally start at MSI #2 (doorbell bit 0 -> MSI #2). However, pci-epf-vntb has historically applied an extra offset and mapped doorbell bit 0 to MSI #3. This matches the legacy behavior of ntb_hw_epf and has been preserved since commit e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP"). This offset has not surfaced as a functional issue because: - ntb_hw_epf typically allocates enough MSI vectors, so the off-by-one still hits a valid MSI vector, and - ntb_hw_epf does not implement .db_vector_count()/.db_vector_mask(), so client drivers such as ntb_transport effectively ignore the vector number and schedule all QPs. Correcting the MSI number would break interoperability with peers running older kernels. Document the legacy offset to avoid confusion when enabling per-db-vector handling. Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Frank Li Link: https://patch.msgid.link/20260513024923.451765-2-den@valinux.co.jp

PCI: endpoint: pci-epf-ntb: Add check to detect 'db_count' value of 0

2026-06-22T20:31:10+00:00

epf_ntb->db_count value should be within 1 to MAX_DB_COUNT. Current code only checks for the upper bound, while the lower bound is unchecked. This can cause a lot of issues in the driver if the user passes 'db_count' as 0. Add a check for 0 also. While at it, remove the redundant 'db_count' variable from epf_ntb_configure_interrupt(). Fixes: 8b821cf76150 ("PCI: endpoint: Add EP function driver to provide NTB functionality") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260407124421.282766-3-mani@kernel.org

PCI: endpoint: pci-epf-vntb: Add check to detect 'db_count' value of 0

2026-06-22T20:31:05+00:00

epf_ntb->db_count value should be within 1 to MAX_DB_COUNT. Current code only checks for the upper bound, while the lower bound is unchecked. This can cause a lot of issues in the driver if the user passes 'db_count' as 0. Add a check for 0 also. While at it, remove the redundant 'db_count' assignment. Fixes: e35f56bb0330 ("PCI: endpoint: Support NTB transfer between RC and EP") Signed-off-by: Manivannan Sadhasivam Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Reviewed-by: Koichiro Den Reviewed-by: Frank Li Link: https://patch.msgid.link/20260407124421.282766-2-mani@kernel.org

PCI: endpoint: pci-ep-msi: Add embedded doorbell fallback

2026-05-04T23:01:33+00:00

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 Signed-off-by: Koichiro Den Signed-off-by: Manivannan Sadhasivam Signed-off-by: Bjorn Helgaas Link: https://patch.msgid.link/20260414141514.1341429-8-den@valinux.co.jp