Re: [PATCH v8 0/5] PCI: endpoint: BAR subrange mapping support

Manivannan Sadhasivam
2026-01-22T06:46:29Z

On Thu, Jan 22, 2026 at 10:52:31AM +0900, Koichiro Den wrote:
> On Wed, Jan 21, 2026 at 09:08:34PM +0530, Manivannan Sadhasivam wrote:
> > On Mon, Jan 19, 2026 at 10:00:38PM +0900, Koichiro Den wrote:
> > > On Thu, Jan 15, 2026 at 05:49:23PM +0900, Koichiro Den wrote:
> > > > This series proposes support for mapping subranges within a PCIe endpoint
> > > > BAR and enables controllers to program inbound address translation for
> > > > those subranges.
> > > >
> > > > - Patch 1/5 introduces dynamic_inbound_mapping feature bit. This can be
> > > > used as a safeguard to check whether a BAR can really be reconfigured
> > > > without clearing/resetting it.
> > > >
> > > > - Patch 2/5 introduces generic BAR subrange mapping support in the PCI
> > > > endpoint core.
> > > >
> > > > - Patch 3/5 advertises dynamic inbound mapping support via
> > > > DWC_EPC_COMMON_FEATURES for all DWC-based glue drivers.
> > > >
> > > > - Patch 4/5 adds an implementation for the DesignWare PCIe endpoint
> > > > controller using Address Match Mode IB iATU. It also advertises
> > > > subrange_mapping support via DWC_EPC_COMMON_FEATURES.
> > > >
> > > > - Patch 5/5 updates a documentation for pci_epc_set_bar().
> > > >
> > > --(snip)--
> > > > Koichiro Den (5):
> > > > PCI: endpoint: Add dynamic_inbound_mapping EPC feature
> > > > PCI: endpoint: Add BAR subrange mapping support
> > > > PCI: dwc: Advertise dynamic inbound mapping support
> > > > PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match
> > > > Mode iATU
> > > > Documentation: PCI: endpoint: Clarify pci_epc_set_bar() usage
> > > >
> > > > Documentation/PCI/endpoint/pci-endpoint.rst | 24 +++
> > > > drivers/pci/controller/dwc/pci-dra7xx.c | 1 +
> > > > drivers/pci/controller/dwc/pci-imx6.c | 3 +
> > > > drivers/pci/controller/dwc/pci-keystone.c | 1 +
> > > > drivers/pci/controller/dwc/pcie-artpec6.c | 1 +
> > > > .../pci/controller/dwc/pcie-designware-ep.c | 203 +++++++++++++++++-
> > > > .../pci/controller/dwc/pcie-designware-plat.c | 1 +
> > > > drivers/pci/controller/dwc/pcie-designware.h | 8 +
> > > > drivers/pci/controller/dwc/pcie-dw-rockchip.c | 2 +
> > > > drivers/pci/controller/dwc/pcie-keembay.c | 1 +
> > > > drivers/pci/controller/dwc/pcie-qcom-ep.c | 1 +
> > > > drivers/pci/controller/dwc/pcie-rcar-gen4.c | 1 +
> > > > drivers/pci/controller/dwc/pcie-stm32-ep.c | 1 +
> > > > drivers/pci/controller/dwc/pcie-tegra194.c | 1 +
> > > > drivers/pci/controller/dwc/pcie-uniphier-ep.c | 2 +
> > > > drivers/pci/endpoint/pci-epc-core.c | 8 +
> > > > include/linux/pci-epc.h | 9 +
> > > > include/linux/pci-epf.h | 27 +++
> > > > 18 files changed, 285 insertions(+), 10 deletions(-)
> > >
> > > Hi Mani, Bjorn,
> > >
> > > Based on the feedback so far (thanks to Niklas and Frank), the design seems
> > > to be converging. At this point, I would appreciate confirmation on the
> > > following points before proceeding further.
> > >
> > > 1) Does the current (v8) approach for BAR subrange inbound mapping at the
> > > EPC/core level look reasonable?
> > >
>
> Hi Mani,
>
> Thanks for the question.
>
> >
> > In this series you didn't add a consumer of this subrange mapping, which I
> > believe is the epf-vntb driver [1]. Even so I don't see a justification of why
> > the BAR needs to be split into multiple subranges. Can you explain that?
>
> Yes, the first consumer I have in mind is epf-vntb / remote eDMA-backed NTB
> work referenced in [1].
>
> The motivation for BAR subrange mapping is that some EP platforms
> effectively have only two practically usable BARs, while needing multiple
> logically independent inbound mapping.
>
> For example, on Renesas R-Car Gen4 Spider, 64-bit BAR0 and BAR2 are the
> only practically usable BARs, since BAR4 is only 256 bytes. epf-vntb
> already needs two separate regions (config+spad and MW1 for the
> data-plane), leaving no spare BAR. Adding ntb_msi requires yet another MW,
> which simply does not fit unless an existing BAR is further divided.
>
> In theory, some vNTB regions (e.g. config+spad and dynamically allocated
> memory-backed MWs) could be tightly packed into a single physically
> contiguous BAR region to barely make it work. However, it immediately makes
> features mutually exclusive (e.g. ntb_msi / ntb_edma cannot coexist), and
> the layout becomes extremely fragile.
>
> Similarly, for remote eDMA-backed NTB transport, the host needs separate
> inbound access to the eDMA register block and the LL regions, which are
> distinct local address ranges. Without subrange mapping, the only choice is
> unnatural layout (e.g. dedicating one BAR entirely to eDMA register block,
> and another one to everything else that can be packed into a single locally
> contiguous memory region), even when this is barely possible.
>
> So while some cases might be made to work by aggressive packing, they are
> already at the limit on platforms such as R-Car Spider. BAR subrange
> mapping allows these features to be implemented in a straightforward,
> loosely-coupled, and extensible way on platforms with severely constrained
> BAR resources.
>

Thanks for the explanation, makes sense. When you respin this series, please
include it in cover letter and relevant commit message.

- Mani

--
மணிவண்ணன் சதாசிவம்