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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aXI_ny1-5NlN8r_z@ryzen>
Date: Thu, 22 Jan 2026 16:17:51 +0100
From: Niklas Cassel <cassel@...nel.org>
To: Koichiro Den <den@...inux.co.jp>
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 11:02:42PM +0900, Koichiro Den wrote:
> 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.

Ok, I assumed that some of those 5 patches were either eDMA optimizations
or things needed for NTB.

But if you need them even to just probe the eDMA driver on the host side
(using registers from the remote eDMA), then perhaps it is too much.

I was hoping that we could at least have a very simple test,
e.g. pci-endpoint-test only supporting READ or WRITE using remote eDMA.

At least then we would have a consumer part of this series.

pci-endpoint-test could have been further extended in a follow up series
if there were some eDMA driver patches that were needed for more complex
operations than a simple READ or WRITE using remote eDMA.


Kind regards,
Niklas