.../pci/controller/dwc/pcie-designware-ep.c | 198 ++++++++++++++++-- drivers/pci/controller/dwc/pcie-designware.h | 2 + include/linux/pci-epf.h | 26 +++ 3 files changed, 214 insertions(+), 12 deletions(-)
This series proposes support for mapping subranges within a PCIe endpoint
BAR and enables controllers to program inbound address translation for
those subranges.
The first patch introduces generic BAR subrange mapping support in the
PCI endpoint core. The second patch adds an implementation for the
DesignWare PCIe endpoint controller using Address Match Mode IB iATU.
This series is a spin-off from a larger RFC series posted earlier:
https://lore.kernel.org/all/20251217151609.3162665-4-den@valinux.co.jp/
Base:
git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
branch: controller/dwc
commit: 68ac85fb42cf ("PCI: dwc: Use cfg0_base as iMSI-RX target address
to support 32-bit MSI devices")
Thank you for reviewing,
Koichiro Den (2):
PCI: endpoint: Add BAR subrange mapping support
PCI: dwc: ep: Support BAR subrange inbound mapping via address-match
iATU
.../pci/controller/dwc/pcie-designware-ep.c | 198 ++++++++++++++++--
drivers/pci/controller/dwc/pcie-designware.h | 2 +
include/linux/pci-epf.h | 26 +++
3 files changed, 214 insertions(+), 12 deletions(-)
--
2.51.0
Hello Koichiro,
On Mon, Jan 05, 2026 at 05:02:12PM +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.
>
> The first patch introduces generic BAR subrange mapping support in the
> PCI endpoint core. The second patch adds an implementation for the
> DesignWare PCIe endpoint controller using Address Match Mode IB iATU.
>
> This series is a spin-off from a larger RFC series posted earlier:
> https://lore.kernel.org/all/20251217151609.3162665-4-den@valinux.co.jp/
>
> Base:
> git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
> branch: controller/dwc
> commit: 68ac85fb42cf ("PCI: dwc: Use cfg0_base as iMSI-RX target address
> to support 32-bit MSI devices")
>
> Thank you for reviewing,
>
> Koichiro Den (2):
> PCI: endpoint: Add BAR subrange mapping support
> PCI: dwc: ep: Support BAR subrange inbound mapping via address-match
> iATU
I have nothing against this feature, but the big question here is:
where is the user?
Usually, we don't add a new feature without having a single user of said
feature.
One thing that I would like to see though:
stricter verification of the pci_epf_bar_submap array.
For DWC, we know that the minimum size that an iATU can map is stored in:
(struct dw_pcie *pci) pci->region_align.
Thus, each element in the pci_epf_bar_submap array has to have a size that
is a multiple of pci->region_align.
I don't see that you ever verify this anywhere.
You should also verify that the sum of all the sizes in the pci_epf_bar_submap
array adds up to exactly pci_epf_bar->size.
Also, we currently have code in dw_pcie_prog_inbound_atu() that verifies
that the physical memory address is aligned to the size of the BAR, as that
is a requirement in BAR match mode, see:
129f6af747b2 ("PCI: dwc: ep: Add 'address' alignment to 'size' check in dw_pcie_prog_ep_inbound_atu()")
This is not a requirement in address match mode, so you probably don't
want to do that check in address match mode.
(You will want to keep the check that the physical memory address is
aligned to pci->region_align though.)
Kind regards,
Niklas
On Mon, Jan 05, 2026 at 05:55:30PM +0100, Niklas Cassel wrote:
> Hello Koichiro,
>
> On Mon, Jan 05, 2026 at 05:02:12PM +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.
> >
> > The first patch introduces generic BAR subrange mapping support in the
> > PCI endpoint core. The second patch adds an implementation for the
> > DesignWare PCIe endpoint controller using Address Match Mode IB iATU.
> >
> > This series is a spin-off from a larger RFC series posted earlier:
> > https://lore.kernel.org/all/20251217151609.3162665-4-den@valinux.co.jp/
> >
> > Base:
> > git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
> > branch: controller/dwc
> > commit: 68ac85fb42cf ("PCI: dwc: Use cfg0_base as iMSI-RX target address
> > to support 32-bit MSI devices")
> >
> > Thank you for reviewing,
> >
> > Koichiro Den (2):
> > PCI: endpoint: Add BAR subrange mapping support
> > PCI: dwc: ep: Support BAR subrange inbound mapping via address-match
> > iATU
>
> I have nothing against this feature, but the big question here is:
> where is the user?
>
> Usually, we don't add a new feature without having a single user of said
> feature.
>
The first user will likely be Remote eDMA-backed NTB transport. An RFC
series,
https://lore.kernel.org/all/20251217151609.3162665-4-den@valinux.co.jp/
referenced in the cover letter relies on Address Match Mode support.
In that sense, this split series is prerequisite work, and if this gets
acked, I will post another patch series that utilizes this in the NTB code.
At least for Renesas R-Car S4, where 64-bit BAR0/BAR2 and 32-bit BAR4 are
available, exposing the eDMA regsister and LL regions to the host requires
at least two mappings (one for register and another for a contiguous LL
memory). Address Match Mode allows a flexible and extensible layout for the
required regions.
>
> One thing that I would like to see though:
> stricter verification of the pci_epf_bar_submap array.
>
> For DWC, we know that the minimum size that an iATU can map is stored in:
> (struct dw_pcie *pci) pci->region_align.
>
> Thus, each element in the pci_epf_bar_submap array has to have a size that
> is a multiple of pci->region_align.
>
> I don't see that you ever verify this anywhere.
I missed it, will add the check.
>
> You should also verify that the sum of all the sizes in the pci_epf_bar_submap
> array adds up to exactly pci_epf_bar->size.
I didn't think this was a requirement. I experimented with it just now, and
seems to me that no harm is caused even if the sum of the submap sizes is
less than the BAR size. Could you point me to any description of this
requirement in the databook if available?
>
> Also, we currently have code in dw_pcie_prog_inbound_atu() that verifies
> that the physical memory address is aligned to the size of the BAR, as that
> is a requirement in BAR match mode, see:
> 129f6af747b2 ("PCI: dwc: ep: Add 'address' alignment to 'size' check in dw_pcie_prog_ep_inbound_atu()")
>
> This is not a requirement in address match mode, so you probably don't
> want to do that check in address match mode.
> (You will want to keep the check that the physical memory address is
> aligned to pci->region_align though.)
With this series, the call graph would change as follows:
-> dw_pcie_ep_set_bar()
# For BAR Match Mode:
-> dw_pcie_ep_ib_atu_bar()
-> dw_pcie_prog_ep_inbound_atu()
# For Address Match Mode:
-> dw_pcie_ep_ib_atu_addr()
-> dw_pcie_prog_inbound_atu()
and the size check that was introduced in the commit 129f6af747b2 should
not run for Address Match Mode in any case.
Thank you for the review!
Koichiro
>
>
> Kind regards,
> Niklas
On Tue, Jan 06, 2026 at 10:52:54AM +0900, Koichiro Den wrote: > On Mon, Jan 05, 2026 at 05:55:30PM +0100, Niklas Cassel wrote: > > > > You should also verify that the sum of all the sizes in the pci_epf_bar_submap > > array adds up to exactly pci_epf_bar->size. > > I didn't think this was a requirement. I experimented with it just now, and > seems to me that no harm is caused even if the sum of the submap sizes is > less than the BAR size. Could you point me to any description of this > requirement in the databook if available? 3.10.7 Inbound Features "Without address translation, your application address is passed from the TLPs directly through the application interface." Thus, when there is not an explicit translation, the DWC controller passes through a transaction untranslated. Sure, if there is no physical memory or IO registers at the physical address corresponding to the PCI address trying to be accessed, no harm done. But because of the potential security implications, I think it is good to ensure that the whole PCI address range of the BAR has a physical mapping. Kind regards, Niklas
On Tue, Jan 06, 2026 at 10:30:40AM +0100, Niklas Cassel wrote: > On Tue, Jan 06, 2026 at 10:52:54AM +0900, Koichiro Den wrote: > > On Mon, Jan 05, 2026 at 05:55:30PM +0100, Niklas Cassel wrote: > > > > > > You should also verify that the sum of all the sizes in the pci_epf_bar_submap > > > array adds up to exactly pci_epf_bar->size. > > > > I didn't think this was a requirement. I experimented with it just now, and > > seems to me that no harm is caused even if the sum of the submap sizes is > > less than the BAR size. Could you point me to any description of this > > requirement in the databook if available? > > 3.10.7 Inbound Features > "Without address translation, your application address is passed from the > TLPs directly through the application interface." > > > Thus, when there is not an explicit translation, the DWC controller passes > through a transaction untranslated. I see your point now. Thanks for the clarification. > > Sure, if there is no physical memory or IO registers at the physical address > corresponding to the PCI address trying to be accessed, no harm done. > > But because of the potential security implications, I think it is good to > ensure that the whole PCI address range of the BAR has a physical mapping. That makes sense. This (v1) series implicitly allows incremental iATU programming via multiple dw_pcie_ep_set_bar() invocations with incrementally added submaps, but if we want to prohibit any holes, it seems reasonable to make the API contract stricter such that the caller must prepare all sub-range mappings up front, and a one-shot API call should either map the whole BAR or fail altogether (all-or-nothing). Kind regards, Koichiro > > > Kind regards, > Niklas
On Tue, Jan 06, 2026 at 10:52:54AM +0900, Koichiro Den wrote:
> On Mon, Jan 05, 2026 at 05:55:30PM +0100, Niklas Cassel wrote:
> > Hello Koichiro,
> >
> > On Mon, Jan 05, 2026 at 05:02:12PM +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.
> > >
> > > The first patch introduces generic BAR subrange mapping support in the
> > > PCI endpoint core. The second patch adds an implementation for the
> > > DesignWare PCIe endpoint controller using Address Match Mode IB iATU.
> > >
> > > This series is a spin-off from a larger RFC series posted earlier:
> > > https://lore.kernel.org/all/20251217151609.3162665-4-den@valinux.co.jp/
> > >
> > > Base:
> > > git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
> > > branch: controller/dwc
> > > commit: 68ac85fb42cf ("PCI: dwc: Use cfg0_base as iMSI-RX target address
> > > to support 32-bit MSI devices")
> > >
> > > Thank you for reviewing,
> > >
> > > Koichiro Den (2):
> > > PCI: endpoint: Add BAR subrange mapping support
> > > PCI: dwc: ep: Support BAR subrange inbound mapping via address-match
> > > iATU
> >
> > I have nothing against this feature, but the big question here is:
> > where is the user?
> >
> > Usually, we don't add a new feature without having a single user of said
> > feature.
> >
>
> The first user will likely be Remote eDMA-backed NTB transport. An RFC
> series,
> https://lore.kernel.org/all/20251217151609.3162665-4-den@valinux.co.jp/
> referenced in the cover letter relies on Address Match Mode support.
> In that sense, this split series is prerequisite work, and if this gets
> acked, I will post another patch series that utilizes this in the NTB code.
>
> At least for Renesas R-Car S4, where 64-bit BAR0/BAR2 and 32-bit BAR4 are
> available, exposing the eDMA regsister and LL regions to the host requires
> at least two mappings (one for register and another for a contiguous LL
> memory). Address Match Mode allows a flexible and extensible layout for the
> required regions.
>
> >
> > One thing that I would like to see though:
> > stricter verification of the pci_epf_bar_submap array.
> >
> > For DWC, we know that the minimum size that an iATU can map is stored in:
> > (struct dw_pcie *pci) pci->region_align.
> >
> > Thus, each element in the pci_epf_bar_submap array has to have a size that
> > is a multiple of pci->region_align.
> >
> > I don't see that you ever verify this anywhere.
>
> I missed it, will add the check.
My reply above was wrong, the region_align-related validation is already
handled in dw_pcie_prog_inbound_atu(). I don't think we need to duplicate
the same check at (A) (see below) in dw_pcie_ep_ib_atu_addr(), and would
prefer to keep the code simple as possible since this is not a fast path.
(The below is the code with this series applied)
/* Address match mode */
static int dw_pcie_ep_ib_atu_addr(struct dw_pcie_ep *ep, u8 func_no, int type,
struct pci_epf_bar *epf_bar)
{
[...]
for (i = 0; i < epf_bar->num_submap; i++) {
off = submap[i].offset;
size = submap[i].size;
parent_bus_addr = submap[i].phys_addr;
if (!size)
continue;
# (A)
[...]
ret = dw_pcie_prog_inbound_atu(pci, free_win, type,
parent_bus_addr, pci_addr, size); # (B)
if (ret) {
spin_lock_irqsave(&ep->ib_map_lock, flags);
list_del(&new->list);
clear_bit(free_win, ep->ib_window_map);
spin_unlock_irqrestore(&ep->ib_map_lock, flags);
devm_kfree(dev, new);
return ret;
Kind regards,
Koichiro
>
> >
> > You should also verify that the sum of all the sizes in the pci_epf_bar_submap
> > array adds up to exactly pci_epf_bar->size.
>
> I didn't think this was a requirement. I experimented with it just now, and
> seems to me that no harm is caused even if the sum of the submap sizes is
> less than the BAR size. Could you point me to any description of this
> requirement in the databook if available?
>
> >
> > Also, we currently have code in dw_pcie_prog_inbound_atu() that verifies
> > that the physical memory address is aligned to the size of the BAR, as that
> > is a requirement in BAR match mode, see:
> > 129f6af747b2 ("PCI: dwc: ep: Add 'address' alignment to 'size' check in dw_pcie_prog_ep_inbound_atu()")
> >
> > This is not a requirement in address match mode, so you probably don't
> > want to do that check in address match mode.
> > (You will want to keep the check that the physical memory address is
> > aligned to pci->region_align though.)
>
> With this series, the call graph would change as follows:
>
> -> dw_pcie_ep_set_bar()
> # For BAR Match Mode:
> -> dw_pcie_ep_ib_atu_bar()
> -> dw_pcie_prog_ep_inbound_atu()
> # For Address Match Mode:
> -> dw_pcie_ep_ib_atu_addr()
> -> dw_pcie_prog_inbound_atu()
>
> and the size check that was introduced in the commit 129f6af747b2 should
> not run for Address Match Mode in any case.
>
> Thank you for the review!
> Koichiro
>
> >
> >
> > Kind regards,
> > Niklas
On Tue, Jan 06, 2026 at 12:09:24PM +0900, Koichiro Den wrote:
> On Tue, Jan 06, 2026 at 10:52:54AM +0900, Koichiro Den wrote:
> > On Mon, Jan 05, 2026 at 05:55:30PM +0100, Niklas Cassel wrote:
> > > Hello Koichiro,
> > >
> > > On Mon, Jan 05, 2026 at 05:02:12PM +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.
> > > >
> > > > The first patch introduces generic BAR subrange mapping support in the
> > > > PCI endpoint core. The second patch adds an implementation for the
> > > > DesignWare PCIe endpoint controller using Address Match Mode IB iATU.
> > > >
> > > > This series is a spin-off from a larger RFC series posted earlier:
> > > > https://lore.kernel.org/all/20251217151609.3162665-4-den@valinux.co.jp/
> > > >
> > > > Base:
> > > > git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
> > > > branch: controller/dwc
> > > > commit: 68ac85fb42cf ("PCI: dwc: Use cfg0_base as iMSI-RX target address
> > > > to support 32-bit MSI devices")
> > > >
> > > > Thank you for reviewing,
> > > >
> > > > Koichiro Den (2):
> > > > PCI: endpoint: Add BAR subrange mapping support
> > > > PCI: dwc: ep: Support BAR subrange inbound mapping via address-match
> > > > iATU
> > >
> > > I have nothing against this feature, but the big question here is:
> > > where is the user?
> > >
> > > Usually, we don't add a new feature without having a single user of said
> > > feature.
> > >
> >
> > The first user will likely be Remote eDMA-backed NTB transport. An RFC
> > series,
> > https://lore.kernel.org/all/20251217151609.3162665-4-den@valinux.co.jp/
> > referenced in the cover letter relies on Address Match Mode support.
> > In that sense, this split series is prerequisite work, and if this gets
> > acked, I will post another patch series that utilizes this in the NTB code.
> >
> > At least for Renesas R-Car S4, where 64-bit BAR0/BAR2 and 32-bit BAR4 are
> > available, exposing the eDMA regsister and LL regions to the host requires
> > at least two mappings (one for register and another for a contiguous LL
> > memory). Address Match Mode allows a flexible and extensible layout for the
> > required regions.
> >
> > >
> > > One thing that I would like to see though:
> > > stricter verification of the pci_epf_bar_submap array.
> > >
> > > For DWC, we know that the minimum size that an iATU can map is stored in:
> > > (struct dw_pcie *pci) pci->region_align.
> > >
> > > Thus, each element in the pci_epf_bar_submap array has to have a size that
> > > is a multiple of pci->region_align.
> > >
> > > I don't see that you ever verify this anywhere.
> >
> > I missed it, will add the check.
>
> My reply above was wrong, the region_align-related validation is already
> handled in dw_pcie_prog_inbound_atu(). I don't think we need to duplicate
> the same check at (A) (see below) in dw_pcie_ep_ib_atu_addr(), and would
> prefer to keep the code simple as possible since this is not a fast path.
The region align check in dw_pcie_prog_inbound_atu() validates that the
addresses (pci_addr and parent_bus_addr) are aligned to region_align
(min iATU size).
You also need to check that the size of the region mapped is aligned to
region_align (min iATU size).
Kind regards,
Niklas
On Tue, Jan 06, 2026 at 10:16:15AM +0100, Niklas Cassel wrote:
> On Tue, Jan 06, 2026 at 12:09:24PM +0900, Koichiro Den wrote:
> > On Tue, Jan 06, 2026 at 10:52:54AM +0900, Koichiro Den wrote:
> > > On Mon, Jan 05, 2026 at 05:55:30PM +0100, Niklas Cassel wrote:
> > > > Hello Koichiro,
> > > >
> > > > On Mon, Jan 05, 2026 at 05:02:12PM +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.
> > > > >
> > > > > The first patch introduces generic BAR subrange mapping support in the
> > > > > PCI endpoint core. The second patch adds an implementation for the
> > > > > DesignWare PCIe endpoint controller using Address Match Mode IB iATU.
> > > > >
> > > > > This series is a spin-off from a larger RFC series posted earlier:
> > > > > https://lore.kernel.org/all/20251217151609.3162665-4-den@valinux.co.jp/
> > > > >
> > > > > Base:
> > > > > git://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git
> > > > > branch: controller/dwc
> > > > > commit: 68ac85fb42cf ("PCI: dwc: Use cfg0_base as iMSI-RX target address
> > > > > to support 32-bit MSI devices")
> > > > >
> > > > > Thank you for reviewing,
> > > > >
> > > > > Koichiro Den (2):
> > > > > PCI: endpoint: Add BAR subrange mapping support
> > > > > PCI: dwc: ep: Support BAR subrange inbound mapping via address-match
> > > > > iATU
> > > >
> > > > I have nothing against this feature, but the big question here is:
> > > > where is the user?
> > > >
> > > > Usually, we don't add a new feature without having a single user of said
> > > > feature.
> > > >
> > >
> > > The first user will likely be Remote eDMA-backed NTB transport. An RFC
> > > series,
> > > https://lore.kernel.org/all/20251217151609.3162665-4-den@valinux.co.jp/
> > > referenced in the cover letter relies on Address Match Mode support.
> > > In that sense, this split series is prerequisite work, and if this gets
> > > acked, I will post another patch series that utilizes this in the NTB code.
> > >
> > > At least for Renesas R-Car S4, where 64-bit BAR0/BAR2 and 32-bit BAR4 are
> > > available, exposing the eDMA regsister and LL regions to the host requires
> > > at least two mappings (one for register and another for a contiguous LL
> > > memory). Address Match Mode allows a flexible and extensible layout for the
> > > required regions.
> > >
> > > >
> > > > One thing that I would like to see though:
> > > > stricter verification of the pci_epf_bar_submap array.
> > > >
> > > > For DWC, we know that the minimum size that an iATU can map is stored in:
> > > > (struct dw_pcie *pci) pci->region_align.
> > > >
> > > > Thus, each element in the pci_epf_bar_submap array has to have a size that
> > > > is a multiple of pci->region_align.
> > > >
> > > > I don't see that you ever verify this anywhere.
> > >
> > > I missed it, will add the check.
> >
> > My reply above was wrong, the region_align-related validation is already
> > handled in dw_pcie_prog_inbound_atu(). I don't think we need to duplicate
> > the same check at (A) (see below) in dw_pcie_ep_ib_atu_addr(), and would
> > prefer to keep the code simple as possible since this is not a fast path.
>
> The region align check in dw_pcie_prog_inbound_atu() validates that the
> addresses (pci_addr and parent_bus_addr) are aligned to region_align
> (min iATU size).
>
> You also need to check that the size of the region mapped is aligned to
> region_align (min iATU size).
You're right, thanks for pointing that out.
Koichiro
>
>
> Kind regards,
> Niklas
© 2016 - 2026 Red Hat, Inc.