linux-kernel - Re: [PATCH v7 2/6] PCI: endpoint: Add BAR subrange mapping support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ngvqrju3bi6sugynhksxsci6rmgqevzpoijjflp2373c6uxlum@vyepxqghbzvn>
Date: Wed, 14 Jan 2026 12:22:21 +0900
From: Koichiro Den <den@...inux.co.jp>
To: Frank Li <Frank.li@....com>
Cc: jingoohan1@...il.com, mani@...nel.org, lpieralisi@...nel.org, 
	kwilczynski@...nel.org, robh@...nel.org, bhelgaas@...gle.com, cassel@...nel.org, 
	vigneshr@...com, s-vadapalli@...com, hongxing.zhu@....com, l.stach@...gutronix.de, 
	shawnguo@...nel.org, s.hauer@...gutronix.de, kernel@...gutronix.de, 
	festevam@...il.com, minghuan.Lian@....com, mingkai.hu@....com, roy.zang@....com, 
	jesper.nilsson@...s.com, heiko@...ech.de, srikanth.thokala@...el.com, 
	marek.vasut+renesas@...il.com, yoshihiro.shimoda.uh@...esas.com, geert+renesas@...der.be, 
	magnus.damm@...il.com, christian.bruel@...s.st.com, mcoquelin.stm32@...il.com, 
	alexandre.torgue@...s.st.com, thierry.reding@...il.com, jonathanh@...dia.com, 
	hayashi.kunihiko@...ionext.com, mhiramat@...nel.org, kishon@...nel.org, jirislaby@...nel.org, 
	rongqianfeng@...o.com, 18255117159@....com, shawn.lin@...k-chips.com, 
	nicolas.frattaroli@...labora.com, linux.amoon@...il.com, vidyas@...dia.com, 
	linux-omap@...r.kernel.org, linux-pci@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	linux-kernel@...r.kernel.org, imx@...ts.linux.dev, linuxppc-dev@...ts.ozlabs.org, 
	linux-arm-kernel@...s.com, linux-rockchip@...ts.infradead.org, 
	linux-arm-msm@...r.kernel.org, linux-renesas-soc@...r.kernel.org, 
	linux-stm32@...md-mailman.stormreply.com, linux-tegra@...r.kernel.org
Subject: Re: [PATCH v7 2/6] PCI: endpoint: Add BAR subrange mapping support

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 <cassel@...nel.org>
> > Signed-off-by: Koichiro Den <den@...inux.co.jp>
> > ---
> ...
> >
> >  #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
> >