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: <aWaqablKcUnHx/mp@lizhi-Precision-Tower-5810>
Date: Tue, 13 Jan 2026 15:26:17 -0500
From: Frank Li <Frank.li@....com>
To: Koichiro Den <den@...inux.co.jp>
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 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.

> +
>  /**
>   * 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?

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