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: <aUVe7r0BkaF1YXrF@lizhi-Precision-Tower-5810>
Date: Fri, 19 Dec 2025 09:19:26 -0500
From: Frank Li <Frank.li@....com>
To: Koichiro Den <den@...inux.co.jp>
Cc: dave.jiang@...el.com, ntb@...ts.linux.dev, linux-pci@...r.kernel.org,
	dmaengine@...r.kernel.org, linux-renesas-soc@...r.kernel.org,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	mani@...nel.org, kwilczynski@...nel.org, kishon@...nel.org,
	bhelgaas@...gle.com, corbet@....net, geert+renesas@...der.be,
	magnus.damm@...il.com, robh@...nel.org, krzk+dt@...nel.org,
	conor+dt@...nel.org, vkoul@...nel.org, joro@...tes.org,
	will@...nel.org, robin.murphy@....com, jdmason@...zu.us,
	allenbh@...il.com, andrew+netdev@...n.ch, davem@...emloft.net,
	edumazet@...gle.com, kuba@...nel.org, pabeni@...hat.com,
	Basavaraj.Natikar@....com, Shyam-sundar.S-k@....com,
	kurt.schwemmer@...rosemi.com, logang@...tatee.com,
	jingoohan1@...il.com, lpieralisi@...nel.org, utkarsh02t@...il.com,
	jbrunet@...libre.com, dlemoal@...nel.org, arnd@...db.de,
	elfring@...rs.sourceforge.net
Subject: Re: [RFC PATCH v3 03/35] PCI: dwc: ep: Support BAR subrange inbound
 mapping via address match iATU

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@...inux.co.jp>
> ---
>  .../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.

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

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ