Message-ID: <waapztvy6jyjqtfcoo3rbgvagi4z3p5afw6x2acgf5bxatcui6@nkodhtqqtetr>
Date: Thu, 22 Jan 2026 10:52:31 +0900
From: Koichiro Den <den@...inux.co.jp>
To: Manivannan Sadhasivam <mani@...nel.org>
Cc: bhelgaas@...gle.com, kwilczynski@...nel.org, cassel@...nel.org, 
	frank.li@....com, linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 0/5] PCI: endpoint: BAR subrange mapping support

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.

> 
> > 2) From a process perspective, does it make sense to continue this as a PCI
> >    endpoint subsystem-led series, with the dwc-specific changes layered on
> >    top, or would you prefer a different split or ownership?
> > 
> 
> Is is OK to have both controller driver and endpoint changes in one series.

Understood, thank you.

Koichiro

> 
> - Mani
> 
> [1] https://lore.kernel.org/linux-pci/20260118135440.1958279-14-den@valinux.co.jp
> 
> -- 
> மணிவண்ணன் சதாசிவம்

Powered by blists - more mailing lists