On Tue, Jan 13, 2026 at 03:26:17PM -0500, Frank Li wrote:
> On Wed, Jan 14, 2026 at 01:27:15AM +0900, Koichiro Den wrote:
> > Extend the PCI endpoint core to support mapping subranges within a BAR.
> > Introduce a new 'submap' field and a 'use_submap' flag in struct
> > pci_epf_bar so an endpoint function driver can request inbound mappings
> > that fully cover the BAR.
> >
> > Add a subrange_mapping feature bit to struct pci_epc_features so EPC
> > drivers can explicitly advertise support. Make pci_epc_set_bar() reject
> > use_submap requests (-EINVAL) when the EPC does not advertise
> > subrange_mapping, to avoid silently accepting a configuration that the
> > controller cannot implement.
> >
> > The submap array describes the complete BAR layout (no overlaps and no
> > gaps are allowed to avoid exposing untranslated address ranges). This
> > provides the generic infrastructure needed to map multiple logical
> > regions into a single BAR at different offsets, without assuming a
> > controller-specific inbound address translation mechanism. Also, the
> > array must be sorted in ascending order by offset.
> >
> > Reviewed-by: Niklas Cassel <[email protected]>
> > Signed-off-by: Koichiro Den <[email protected]>
> > ---
> ...
> >
> > #define to_pci_epf_driver(drv) container_of_const((drv), struct
> > pci_epf_driver, driver)
> >
> > +/**
> > + * struct pci_epf_bar_submap - BAR subrange for inbound mapping
> > + * @phys_addr: target physical/DMA address for this subrange
> > + * @size: the size of the subrange to be mapped
> > + * @offset: byte offset within the BAR base
> > + *
> > + * When pci_epf_bar.use_submap is set, pci_epf_bar.submap describes the
> > + * complete BAR layout. This allows an EPC driver to program multiple
> > + * inbound translation windows for a single BAR when supported by the
> > + * controller.
> > + *
> > + * Note that the subranges:
> > + * - must be non-overlapping
> > + * - must exactly cover the BAR (i.e. no holes)
> > + * - must be sorted (in ascending order by offset)
> > + */
> > +struct pci_epf_bar_submap {
> > + dma_addr_t phys_addr;
> > + size_t size;
> > + size_t offset;
> > +};
>
> I suppose offset is sum of previous all submap's size? If yes, needn't
> offset.
Thanks for pointing this out.
Yes, I agree that @offset has become redundant now that the "no holes"
constraint is enforced for submaps. It should indeed have been dropped
earlier (in v2).
>
> > +
> > /**
> > * struct pci_epf_bar - represents the BAR of EPF device
> > * @phys_addr: physical address that should be mapped to the BAR
> > @@ -119,6 +141,10 @@ 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. See
> > + * struct pci_epf_bar_submap for the restrictions in detail.
> > */
> > struct pci_epf_bar {
> > dma_addr_t phys_addr;
> > @@ -127,6 +153,11 @@ struct pci_epf_bar {
> > size_t mem_size;
> > enum pci_barno barno;
> > int flags;
> > +
> > + /* Optional sub-range mapping */
> > + bool use_submap;
> > + unsigned int num_submap;
>
> can we use num_submap != 0 as use_submap?
Yes. For the same reason, @use_submap has also become redundant.
Calling pci_epc_set_bar() with use_submap == true && num_submap == 0 has
been invalid since v2, so @use_submap no longer adds useful information.
This can likewise be dropped. I'll respin.
Thanks for the review,
Koichiro
>
> Frank
> > + struct pci_epf_bar_submap *submap;
> > };
> >
> > /**
> > --
> > 2.51.0
> >
