linux-kernel - Re: [PATCH v8 0/5] PCI: endpoint: 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: <tvaumsi4ahosz4herbxoc636fj3lhetjzqlwp5n4e34tthmn26@bld32k6xntmw>
Date: Thu, 22 Jan 2026 23:02:42 +0900
From: Koichiro Den <den@...inux.co.jp>
To: Niklas Cassel <cassel@...nel.org>
Cc: Manivannan Sadhasivam <mani@...nel.org>, bhelgaas@...gle.com, 
	kwilczynski@...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 22, 2026 at 09:45:13AM +0100, Niklas Cassel wrote:
> Hello Koichiro,
> 
> On Thu, Jan 22, 2026 at 10:52:31AM +0900, Koichiro Den wrote:
> > > 
> > > In this series you didn't add a consumer of this subrange mapping, which I
> > > believe is the epf-vntb driver [1]. Even so I don't see a justification of why
> > > the BAR needs to be split into multiple subranges. Can you explain that?
> > 
> > Yes, the first consumer I have in mind is epf-vntb / remote eDMA-backed NTB
> > work referenced in [1].
> 
> Another consumer in your RFC series is pci-epf-test, specifically:
> [RFC PATCH v4 35/38] PCI: endpoint: pci-epf-test: Add pci_epf_test_next_free_bar() helper
> [RFC PATCH v4 36/38] PCI: endpoint: pci-epf-test: Add remote eDMA-backed mode
> [RFC PATCH v4 37/38] misc: pci_endpoint_test: Add remote eDMA transfer test mode
> [RFC PATCH v4 38/38] selftests: pci_endpoint: Add remote eDMA transfer coverage
> 
> where the pci-epf-test exports the eDMA registers (using subranges) over a
> BAR, and then in the host side driver, calls dw_edma_probe() on this subrange
> and uses the host side driver to control the eDMA residing in the endpoint.
> 
> Most of your patches in [RFC PATCH v4 35/38] have NTB prefix.
> 
> Would it not be possible to simply include patches 35-38 in this series,
> so we actually have a consumer, or do you need some other patches as well?

Sorry, I sent v9 just a few minutes after your email, without noticing it,
and then I was AFK for several hours.

> 
> E.g., perhaps
> [RFC PATCH v4 01/38] dmaengine: dw-edma: Export helper to get integrated register window
> 
> Would also be required?

Yes, please see the section "Patch layout" in:
https://lore.kernel.org/all/20260118135440.1958279-1-den@valinux.co.jp/

  [...]
  1. dw-edma / DesignWare EP helpers needed for remote embedded-DMA (export
     register/LL windows, IRQ routing control, etc.)

     Patch 01 : dmaengine: dw-edma: Export helper to get integrated register window
     Patch 02 : dmaengine: dw-edma: Add per-channel interrupt routing control
     Patch 03 : dmaengine: dw-edma: Poll completion when local IRQ handling is disabled
     Patch 04 : dmaengine: dw-edma: Add notify-only channels support
     Patch 05 : dmaengine: dw-edma: Add a helper to query linked-list region

Patches [RFC PATCH v4 01/38] through [RFC PATCH v4 05/38] are prerequisites
for the PCI test update, in addition to this "PCI: endpoint: BAR subrange
mapping support" series. Note that this series is described in "Kernel
base / dependencies" section of the large RFC series cover letter.

For this reason, those test cases cannot be included in this series.

Kind regards,
Koichiro

> 
> 
> 
> Kind regards,
> Niklas