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

[Niklas Cassel <cassel@kernel.org>]

On Tue, Jan 06, 2026 at 12:09:24PM +0900, Koichiro Den wrote:
> On Tue, Jan 06, 2026 at 10:52:54AM +0900, Koichiro Den wrote:
> > On Mon, Jan 05, 2026 at 05:55:30PM +0100, Niklas Cassel wrote:
> > > Hello Koichiro,
> > > 
> > > On Mon, Jan 05, 2026 at 05:02:12PM +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.
> > > > 
> > > > The first patch introduces generic BAR subrange mapping support in the
> > > > PCI endpoint core. The second patch adds an implementation for the
> > > > DesignWare PCIe endpoint controller using Address Match Mode IB iATU.
> > > > 
> > > > This series is a spin-off from a larger RFC series posted earlier:
> > > > https://lore.kernel.org/all/20251217151609.3162665-4-den@valinux.co.jp/
> > > > 
> > > > Base:
> > > >   git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
> > > >   branch: controller/dwc
> > > >   commit: 68ac85fb42cf ("PCI: dwc: Use cfg0_base as iMSI-RX target address
> > > >                          to support 32-bit MSI devices")
> > > > 
> > > > Thank you for reviewing,
> > > > 
> > > > Koichiro Den (2):
> > > >   PCI: endpoint: Add BAR subrange mapping support
> > > >   PCI: dwc: ep: Support BAR subrange inbound mapping via address-match
> > > >     iATU
> > > 
> > > I have nothing against this feature, but the big question here is:
> > > where is the user?
> > > 
> > > Usually, we don't add a new feature without having a single user of said
> > > feature.
> > > 
> > 
> > The first user will likely be Remote eDMA-backed NTB transport. An RFC
> > series,
> > https://lore.kernel.org/all/20251217151609.3162665-4-den@valinux.co.jp/
> > referenced in the cover letter relies on Address Match Mode support.
> > In that sense, this split series is prerequisite work, and if this gets
> > acked, I will post another patch series that utilizes this in the NTB code.
> > 
> > At least for Renesas R-Car S4, where 64-bit BAR0/BAR2 and 32-bit BAR4 are
> > available, exposing the eDMA regsister and LL regions to the host requires
> > at least two mappings (one for register and another for a contiguous LL
> > memory). Address Match Mode allows a flexible and extensible layout for the
> > required regions.
> > 
> > > 
> > > One thing that I would like to see though:
> > > stricter verification of the pci_epf_bar_submap array.
> > > 
> > > For DWC, we know that the minimum size that an iATU can map is stored in:
> > > (struct dw_pcie *pci) pci->region_align.
> > > 
> > > Thus, each element in the pci_epf_bar_submap array has to have a size that
> > > is a multiple of pci->region_align.
> > > 
> > > I don't see that you ever verify this anywhere.
> > 
> > I missed it, will add the check.
> 
> My reply above was wrong, the region_align-related validation is already
> handled in dw_pcie_prog_inbound_atu(). I don't think we need to duplicate
> the same check at (A) (see below) in dw_pcie_ep_ib_atu_addr(), and would
> prefer to keep the code simple as possible since this is not a fast path.

The region align check in dw_pcie_prog_inbound_atu() validates that the
addresses (pci_addr and parent_bus_addr) are aligned to region_align
(min iATU size).

You also need to check that the size of the region mapped is aligned to
region_align (min iATU size).


Kind regards,
Niklas