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] [day] [month] [year] [list]
Message-ID: <x64g63zkz5t75vxxlzd7rhbvpus2mmhz2phyvxykuax5wm5cnh@zgpomauf75pv>
Date: Mon, 19 Jan 2026 22:00:38 +0900
From: Koichiro Den <den@...inux.co.jp>
To: mani@...nel.org, bhelgaas@...gle.com
Cc: kwilczynski@...nel.org, cassel@...nel.org, frank.li@....com, 
	linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v8 0/5] PCI: endpoint: BAR subrange mapping support

On Thu, Jan 15, 2026 at 05:49:23PM +0900, Koichiro Den wrote:
> This series proposes support for mapping subranges within a PCIe endpoint
> BAR and enables controllers to program inbound address translation for
> those subranges.
> 
> - Patch 1/5 introduces dynamic_inbound_mapping feature bit. This can be
>   used as a safeguard to check whether a BAR can really be reconfigured
>   without clearing/resetting it.
> 
> - Patch 2/5 introduces generic BAR subrange mapping support in the PCI
>   endpoint core.
> 
> - Patch 3/5 advertises dynamic inbound mapping support via
>   DWC_EPC_COMMON_FEATURES for all DWC-based glue drivers.
> 
> - Patch 4/5 adds an implementation for the DesignWare PCIe endpoint
>   controller using Address Match Mode IB iATU. It also advertises
>   subrange_mapping support via DWC_EPC_COMMON_FEATURES.
> 
> - Patch 5/5 updates a documentation for pci_epc_set_bar().
> 
--(snip)--
> Koichiro Den (5):
>   PCI: endpoint: Add dynamic_inbound_mapping EPC feature
>   PCI: endpoint: Add BAR subrange mapping support
>   PCI: dwc: Advertise dynamic inbound mapping support
>   PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match
>     Mode iATU
>   Documentation: PCI: endpoint: Clarify pci_epc_set_bar() usage
> 
>  Documentation/PCI/endpoint/pci-endpoint.rst   |  24 +++
>  drivers/pci/controller/dwc/pci-dra7xx.c       |   1 +
>  drivers/pci/controller/dwc/pci-imx6.c         |   3 +
>  drivers/pci/controller/dwc/pci-keystone.c     |   1 +
>  drivers/pci/controller/dwc/pcie-artpec6.c     |   1 +
>  .../pci/controller/dwc/pcie-designware-ep.c   | 203 +++++++++++++++++-
>  .../pci/controller/dwc/pcie-designware-plat.c |   1 +
>  drivers/pci/controller/dwc/pcie-designware.h  |   8 +
>  drivers/pci/controller/dwc/pcie-dw-rockchip.c |   2 +
>  drivers/pci/controller/dwc/pcie-keembay.c     |   1 +
>  drivers/pci/controller/dwc/pcie-qcom-ep.c     |   1 +
>  drivers/pci/controller/dwc/pcie-rcar-gen4.c   |   1 +
>  drivers/pci/controller/dwc/pcie-stm32-ep.c    |   1 +
>  drivers/pci/controller/dwc/pcie-tegra194.c    |   1 +
>  drivers/pci/controller/dwc/pcie-uniphier-ep.c |   2 +
>  drivers/pci/endpoint/pci-epc-core.c           |   8 +
>  include/linux/pci-epc.h                       |   9 +
>  include/linux/pci-epf.h                       |  27 +++
>  18 files changed, 285 insertions(+), 10 deletions(-)

Hi Mani, Bjorn,

Based on the feedback so far (thanks to Niklas and Frank), the design seems
to be converging. At this point, I would appreciate confirmation on the
following points before proceeding further.

1) Does the current (v8) approach for BAR subrange inbound mapping at the
   EPC/core level look reasonable?

2) From a process perspective, does it make sense to continue this as a PCI
   endpoint subsystem-led series, with the dwc-specific changes layered on
   top, or would you prefer a different split or ownership?

Thanks,
Koichiro

> 
> -- 
> 2.51.0
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ