Re: [RFC PATCH v3 03/35] PCI: dwc: ep: Support BAR subrange inbound mapping via address match iATU

[Koichiro Den]

On Fri, Dec 19, 2025 at 09:19:26AM -0500, Frank Li wrote:
> On Thu, Dec 18, 2025 at 12:15:37AM +0900, Koichiro Den wrote:
> > Extend dw_pcie_ep_set_bar() to support Address Match Mode IB iATU
> > with the new 'submap' field in pci_epf_bar.
> >
> > The existing dw_pcie_ep_inbound_atu(), which is for BAR match mode, is
> > renamed to dw_pcie_ep_ib_atu_bar() and the new dw_pcie_ep_ib_atu_addr()
> > is introduced, which is for Address match mode.
> >
> > Signed-off-by: Koichiro Den <den@xxxxxxxxxxxxx>
> > ---
> >  .../pci/controller/dwc/pcie-designware-ep.c   | 197 ++++++++++++++++--
> >  drivers/pci/controller/dwc/pcie-designware.h  |   2 +
> >  drivers/pci/endpoint/pci-epc-core.c           |   2 +-
> >  include/linux/pci-epf.h                       |  27 +++
> >  4 files changed, 215 insertions(+), 13 deletions(-)
> >
> ...
> >
> >  #define to_pci_epf_driver(drv) container_of_const((drv), struct pci_epf_driver, driver)
> >
> > +/**
> > + * struct pci_epf_bar_submap - represents a BAR subrange for inbound mapping
> > + * @phys_addr: physical address that should be mapped to the BAR subrange
> > + * @size: the size of the subrange to be mapped
> > + * @offset: The byte offset from the BAR base
> > + * @mapped: Set to true if already mapped
> > + *
> > + * When @use_submap is set in struct pci_epf_bar, an EPF driver may describe
> > + * multiple independent mappings within a single BAR. An EPC driver can use
> > + * these descriptors to set up the required address translation (e.g. multiple
> > + * inbound iATU regions) without requiring the whole BAR to be mapped at once.
> > + */
> > +struct pci_epf_bar_submap {
> > +	dma_addr_t	phys_addr;
> > +	size_t		size;
> > +	size_t		offset;
> > +	bool		mapped;
> 
> Can we move dw_pcie_ib_map's neccessary information to here, so needn't
> addition list to map it? such as atu_index.  if atu_index assign, which
> should means mapped.

The 'mapped' field in pci_epf_bar_submap is actually a leftover from an
early draft. I'll drop it, sorry for the confusion.

I would still prefer to keep the atu index in a private structure (ie.
dw_pcie_ib_map). pci_epf_bar_submap is part of the API and I think should
remain a declarative description of the requested sub-range mappings,
without exposing driver-internal state back to the caller.

> 
> > +};
> > +
> >  /**
> >   * struct pci_epf_bar - represents the BAR of EPF device
> >   * @phys_addr: physical address that should be mapped to the BAR
> > @@ -119,6 +138,9 @@ struct pci_epf_driver {
> >   *            requirement
> >   * @barno: BAR number
> >   * @flags: flags that are set for the BAR
> > + * @use_submap: set true to request subrange mappings within this BAR
> > + * @num_submap: number of entries in @submap
> > + * @submap: array of subrange descriptors allocated by the caller
> >   */
> >  struct pci_epf_bar {
> >  	dma_addr_t	phys_addr;
> > @@ -127,6 +149,11 @@ struct pci_epf_bar {
> >  	size_t		mem_size;
> >  	enum pci_barno	barno;
> >  	int		flags;
> > +
> > +	/* Optional sub-range mapping */
> > +	bool		use_submap;
> > +	int		num_submap;
> 
> Can we use num_submap != 0 means request subrange?

Some existing pci_epc_set_bar() callers seem to use a two-stage sequence,
ie. first they only initialize the BAR (with phys_addr == 0), and later
they program the actual BAR-match (re-)mapping (with phys_addr != 0).

If we used only num_submap != 0 as the discriminator, Address Match mode
initialization (num_submap == 0) would be indistinguishable from the
existing BAR-match initialization, and we could end up programming a
meaningless BAR-match mapping with phys_addr == 0. That's why I added an
explicit 'use_submap' flag in addition to 'num_submap'.

Koichiro

> 
> Frank
> > +	struct pci_epf_bar_submap	*submap;
> >  };
> >
> >  /**
> > --
> > 2.51.0
> >