Message-ID: <olnmctbz5u5xkheciqqqb2fmjuilpxlnkfuc3bjnsgm2o3t5qx@ffc5ct6jbuxn>
Date: Thu, 22 Jan 2026 12:16:22 +0530
From: Manivannan Sadhasivam <mani@...nel.org>
To: Koichiro Den <den@...inux.co.jp>
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 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

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

Powered by blists - more mailing lists