[PATCH 0/3] PCI: endpoint: Support vNTB as a non-first EPF

Hi,

This series allows a vNTB endpoint function to be instantiated as PF1+.

vntb_epf_mw_set_trans() programs the memory-window BAR with hardcoded
function numbers (0, 0), so binding the EPF to any other function
programs the wrong one. Patch 1 resolves it.

The platform-MSI doorbell path can currently populate messages only for
the first EPF attached to the EPC. Supporting multiple EPFs in that path
requires separate work. This series leaves it unchanged and lets a
non-first EPF use the embedded doorbell instead.

The embedded-doorbell auxiliary-resource interface is
vendor-independent. Its current DesignWare provider exposes one EPC-wide
source. Since the generic interface cannot identify which EPF's peer
issued a write to a shared source, patch 2 makes the IRQ exclusive.
Patch 3 lets non-first EPFs try the embedded doorbell. If another EPF
has already requested the IRQ, vNTB retains its polling fallback.

I tested the embedded doorbell path on R-Car S4 with the proposed DMA
endpoint function as PF0 and vNTB as PF1.

Best regards,
Koichiro

Koichiro Den (3):
  PCI: endpoint: pci-epf-vntb: Pass PF/VF number when BAR programming
  PCI: endpoint: pci-ep-msi: Make embedded doorbell IRQ exclusive
  PCI: endpoint: pci-ep-msi: Let non-first EPFs use embedded doorbells

 drivers/pci/endpoint/functions/pci-epf-vntb.c |  3 +-
 drivers/pci/endpoint/pci-ep-msi.c             | 40 ++++++++++---------
 include/linux/pci-epf.h                       |  3 +-
 3 files changed, 26 insertions(+), 20 deletions(-)

base-commit: e6ff30150738af5c7aa20fad08b74cbf9b86d3a2
-- 
2.51.0