Message-ID: <nrvamhbpi4372c4qmb2q3h74irrqkntlb2rwfasiorgavylp25@rx2lp6ldk64j>
Date: Fri, 23 Jan 2026 16:11:08 +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 Fri, Jan 23, 2026 at 09:36:27AM +0900, Koichiro Den wrote:
> On Thu, Jan 22, 2026 at 04:17:51PM +0100, Niklas Cassel wrote:
> > 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.
> 
> If we were to add a simple test in this series, I think it would be
> something like BAR_SUBRANGE_TEST (beside BAR_TEST), which dynamically
> triggers subrange mapping on the EP side if supported, and performs
> read/write to those subranges. That would keep the test focused on
> validating the subrange mapping functionality, and would not involve remote
> eDMA. What do you think?

One additional concern if we were to add a subrange mapping test is that
the EP-side pci-epf-test.c currently defines bar_size as follows:

  static size_t bar_size[] = { 512, 512, 1024, 16384, 131072, 1048576 };
  (see https://github.com/torvalds/linux/blob/v6.19-rc6/drivers/pci/endpoint/functions/pci-epf-test.c#L105)

The values 512 (BAR0/1) and 1024 (BAR2) are even smaller than the minimam
CX_ATU_MIN_REGION_SIZE (=4KB). This means that introducing
BAR_SUBRANGE_TEST would likely require one of the following:

  (a). raising these hard-coded values
  (b). reserving a dedicated BAR for the subrange mapping test
  (c). limiting the testing to BAR3/4/5 if available (though, for
       example, no BAR would pass the test on R-Car Spider which I'm
       testing on, where BAR4 is fixed 256B).

I'm wondering whether there is a clean way to add a subrange mapping test
without significantly reshaping pci-epf-test.

Regards,
Koichiro

> 
> Koichiro
> 
> > 
> > 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

Powered by blists - more mailing lists