The commit 24ede430fa49 ("PCI: designware-ep: Add multiple PFs support
for DWC") added support for multiple PFs in the DWC driver, but the
implementation was incomplete. It did not properly support MSI/MSI-X,
as well as BAR and inbound ATU mapping for multiple PFs. The MSI/MSI-X
issue was later fixed by commit 47a062609a30 ("PCI: designware-ep:
Modify MSI and MSIX CAP way of finding") by introducing a per-PF
struct dw_pcie_ep_func.
However, even with both commits, the multiple PF support in the driver
remains broken because BAR configuration and ATU mappings are managed
globally in struct dw_pcie_ep, meaning all PFs share the same BAR-to-ATU
mapping table. This causes one PF's EPF to overwrite the address
translation of another PF's EPF in the internal ATU region,
creating conflicts when multiple physical functions attempt to
configure their BARs independently.
The commit cfbc98dbf44d ("PCI: dwc: ep: Support BAR subrange inbound
mapping via Address Match Mode iATU") later introduced Address Match
Mode support, which suffers from the same multi-PF conflict issue.
Fix this by moving the required members from struct dw_pcie_ep to
struct dw_pcie_ep_func, similar to what commit 47a062609a30
("PCI: designware-ep: Modify MSI and MSIX CAP way of finding") did for
MSI/MSI-X capability support, to allow proper multi-function endpoint
operation, where each PF can configure its BARs and corresponding
internal ATU region without interfering with other PFs.
Fixes: 24ede430fa49 ("PCI: designware-ep: Add multiple PFs support for DWC")
Fixes: cfbc98dbf44d ("PCI: dwc: ep: Support BAR subrange inbound mapping via Address Match Mode iATU")
Signed-off-by: Aksh Garg <a-garg7@ti.com>
Reviewed-by: Niklas Cassel <cassel@kernel.org>
---
Changes from v3 to v4:
- Fix the similar conflict created by the commit cfbc98dbf44d
Changes from v2 to v3:
- None
Changes from v1 to v2:
- Fixed the suggested nits
- Rephrased the commit message with a proper Fixes tag
v3: https://lore.kernel.org/all/20260127085010.446116-3-a-garg7@ti.com/
v2: https://lore.kernel.org/all/20260122082538.309122-3-a-garg7@ti.com/
v1: https://lore.kernel.org/all/20260121054214.274429-3-a-garg7@ti.com/
.../pci/controller/dwc/pcie-designware-ep.c | 76 +++++++++++--------
drivers/pci/controller/dwc/pcie-designware.h | 12 +--
2 files changed, 51 insertions(+), 37 deletions(-)
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
index 1b3dd07e6004..b9a234b47aab 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -115,11 +115,15 @@ static int dw_pcie_ep_ib_atu_bar(struct dw_pcie_ep *ep, u8 func_no, int type,
int ret;
u32 free_win;
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ struct dw_pcie_ep_func *ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
- if (!ep->bar_to_atu[bar])
+ if (!ep_func)
+ return -EINVAL;
+
+ if (!ep_func->bar_to_atu[bar])
free_win = find_first_zero_bit(ep->ib_window_map, pci->num_ib_windows);
else
- free_win = ep->bar_to_atu[bar] - 1;
+ free_win = ep_func->bar_to_atu[bar] - 1;
if (free_win >= pci->num_ib_windows) {
dev_err(pci->dev, "No free inbound window\n");
@@ -137,14 +141,15 @@ static int dw_pcie_ep_ib_atu_bar(struct dw_pcie_ep *ep, u8 func_no, int type,
* Always increment free_win before assignment, since value 0 is used to identify
* unallocated mapping.
*/
- ep->bar_to_atu[bar] = free_win + 1;
+ ep_func->bar_to_atu[bar] = free_win + 1;
set_bit(free_win, ep->ib_window_map);
return 0;
}
-static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, enum pci_barno bar)
+static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, u8 func_no, enum pci_barno bar)
{
+ struct dw_pcie_ep_func *ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
struct device *dev = pci->dev;
unsigned int i, num;
@@ -152,18 +157,18 @@ static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, enum pci_barno bar)
u32 *indexes;
/* Tear down the BAR Match Mode mapping, if any. */
- if (ep->bar_to_atu[bar]) {
- atu_index = ep->bar_to_atu[bar] - 1;
+ if (ep_func->bar_to_atu[bar]) {
+ atu_index = ep_func->bar_to_atu[bar] - 1;
dw_pcie_disable_atu(pci, PCIE_ATU_REGION_DIR_IB, atu_index);
clear_bit(atu_index, ep->ib_window_map);
- ep->bar_to_atu[bar] = 0;
+ ep_func->bar_to_atu[bar] = 0;
}
/* Tear down all Address Match Mode mappings, if any. */
- indexes = ep->ib_atu_indexes[bar];
- num = ep->num_ib_atu_indexes[bar];
- ep->ib_atu_indexes[bar] = NULL;
- ep->num_ib_atu_indexes[bar] = 0;
+ indexes = ep_func->ib_atu_indexes[bar];
+ num = ep_func->num_ib_atu_indexes[bar];
+ ep_func->ib_atu_indexes[bar] = NULL;
+ ep_func->num_ib_atu_indexes[bar] = 0;
if (!indexes)
return;
for (i = 0; i < num; i++) {
@@ -248,6 +253,7 @@ static int dw_pcie_ep_validate_submap(struct dw_pcie_ep *ep,
static int dw_pcie_ep_ib_atu_addr(struct dw_pcie_ep *ep, u8 func_no, int type,
const struct pci_epf_bar *epf_bar)
{
+ struct dw_pcie_ep_func *ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
const struct pci_epf_bar_submap *submap = epf_bar->submap;
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
enum pci_barno bar = epf_bar->barno;
@@ -258,7 +264,7 @@ static int dw_pcie_ep_ib_atu_addr(struct dw_pcie_ep *ep, u8 func_no, int type,
unsigned int i;
u32 *indexes;
- if (!epf_bar->num_submap || !submap || !epf_bar->size)
+ if (!ep_func || !epf_bar->num_submap || !submap || !epf_bar->size)
return -EINVAL;
ret = dw_pcie_ep_validate_submap(ep, submap, epf_bar->num_submap,
@@ -279,8 +285,8 @@ static int dw_pcie_ep_ib_atu_addr(struct dw_pcie_ep *ep, u8 func_no, int type,
if (!indexes)
return -ENOMEM;
- ep->ib_atu_indexes[bar] = indexes;
- ep->num_ib_atu_indexes[bar] = 0;
+ ep_func->ib_atu_indexes[bar] = indexes;
+ ep_func->num_ib_atu_indexes[bar] = 0;
for (i = 0; i < epf_bar->num_submap; i++) {
size = submap[i].size;
@@ -308,11 +314,11 @@ static int dw_pcie_ep_ib_atu_addr(struct dw_pcie_ep *ep, u8 func_no, int type,
set_bit(free_win, ep->ib_window_map);
indexes[i] = free_win;
- ep->num_ib_atu_indexes[bar] = i + 1;
+ ep_func->num_ib_atu_indexes[bar] = i + 1;
}
return 0;
err:
- dw_pcie_ep_clear_ib_maps(ep, bar);
+ dw_pcie_ep_clear_ib_maps(ep, func_no, bar);
return ret;
}
@@ -346,15 +352,16 @@ static void dw_pcie_ep_clear_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
struct dw_pcie_ep *ep = epc_get_drvdata(epc);
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
enum pci_barno bar = epf_bar->barno;
+ struct dw_pcie_ep_func *ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
- if (!ep->epf_bar[bar])
+ if (!ep_func || !ep_func->epf_bar[bar])
return;
__dw_pcie_ep_reset_bar(pci, func_no, bar, epf_bar->flags);
- dw_pcie_ep_clear_ib_maps(ep, bar);
+ dw_pcie_ep_clear_ib_maps(ep, func_no, bar);
- ep->epf_bar[bar] = NULL;
+ ep_func->epf_bar[bar] = NULL;
}
static unsigned int dw_pcie_ep_get_rebar_offset(struct dw_pcie_ep *ep, u8 func_no,
@@ -481,12 +488,16 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
{
struct dw_pcie_ep *ep = epc_get_drvdata(epc);
struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
+ struct dw_pcie_ep_func *ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
enum pci_barno bar = epf_bar->barno;
size_t size = epf_bar->size;
enum pci_epc_bar_type bar_type;
int flags = epf_bar->flags;
int ret, type;
+ if (!ep_func)
+ return -EINVAL;
+
/*
* DWC does not allow BAR pairs to overlap, e.g. you cannot combine BARs
* 1 and 2 to form a 64-bit BAR.
@@ -500,22 +511,22 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
* calling clear_bar() would clear the BAR's PCI address assigned by the
* host).
*/
- if (ep->epf_bar[bar]) {
+ if (ep_func->epf_bar[bar]) {
/*
* We can only dynamically change a BAR if the new BAR size and
* BAR flags do not differ from the existing configuration.
*/
- if (ep->epf_bar[bar]->barno != bar ||
- ep->epf_bar[bar]->size != size ||
- ep->epf_bar[bar]->flags != flags)
+ if (ep_func->epf_bar[bar]->barno != bar ||
+ ep_func->epf_bar[bar]->size != size ||
+ ep_func->epf_bar[bar]->flags != flags)
return -EINVAL;
/*
* When dynamically changing a BAR, tear down any existing
* mappings before re-programming.
*/
- if (ep->epf_bar[bar]->num_submap || epf_bar->num_submap)
- dw_pcie_ep_clear_ib_maps(ep, bar);
+ if (ep_func->epf_bar[bar]->num_submap || epf_bar->num_submap)
+ dw_pcie_ep_clear_ib_maps(ep, func_no, bar);
/*
* When dynamically changing a BAR, skip writing the BAR reg, as
@@ -573,7 +584,7 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
if (ret)
return ret;
- ep->epf_bar[bar] = epf_bar;
+ ep_func->epf_bar[bar] = epf_bar;
return 0;
}
@@ -968,7 +979,7 @@ int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
bir = FIELD_GET(PCI_MSIX_TABLE_BIR, tbl_offset);
tbl_offset &= PCI_MSIX_TABLE_OFFSET;
- msix_tbl = ep->epf_bar[bir]->addr + tbl_offset;
+ msix_tbl = ep_func->epf_bar[bir]->addr + tbl_offset;
msg_addr = msix_tbl[(interrupt_num - 1)].msg_addr;
msg_data = msix_tbl[(interrupt_num - 1)].msg_data;
vec_ctrl = msix_tbl[(interrupt_num - 1)].vector_ctrl;
@@ -1031,11 +1042,14 @@ EXPORT_SYMBOL_GPL(dw_pcie_ep_deinit);
static void dw_pcie_ep_init_rebar_registers(struct dw_pcie_ep *ep, u8 func_no)
{
- unsigned int offset;
- unsigned int nbars;
+ struct dw_pcie_ep_func *ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
+ unsigned int offset, nbars;
enum pci_barno bar;
u32 reg, i, val;
+ if (!ep_func)
+ return;
+
offset = dw_pcie_ep_find_ext_capability(ep, func_no, PCI_EXT_CAP_ID_REBAR);
if (offset) {
@@ -1062,8 +1076,8 @@ static void dw_pcie_ep_init_rebar_registers(struct dw_pcie_ep *ep, u8 func_no)
*/
val = dw_pcie_ep_readl_dbi(ep, func_no, offset + PCI_REBAR_CTRL);
bar = FIELD_GET(PCI_REBAR_CTRL_BAR_IDX, val);
- if (ep->epf_bar[bar])
- pci_epc_bar_size_to_rebar_cap(ep->epf_bar[bar]->size, &val);
+ if (ep_func->epf_bar[bar])
+ pci_epc_bar_size_to_rebar_cap(ep_func->epf_bar[bar]->size, &val);
else
val = BIT(4);
diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
index 8f170122ad78..43d7606bc987 100644
--- a/drivers/pci/controller/dwc/pcie-designware.h
+++ b/drivers/pci/controller/dwc/pcie-designware.h
@@ -471,6 +471,12 @@ struct dw_pcie_ep_func {
u8 func_no;
u8 msi_cap; /* MSI capability offset */
u8 msix_cap; /* MSI-X capability offset */
+ u8 bar_to_atu[PCI_STD_NUM_BARS];
+ struct pci_epf_bar *epf_bar[PCI_STD_NUM_BARS];
+
+ /* Only for Address Match Mode inbound iATU */
+ u32 *ib_atu_indexes[PCI_STD_NUM_BARS];
+ unsigned int num_ib_atu_indexes[PCI_STD_NUM_BARS];
};
struct dw_pcie_ep {
@@ -480,17 +486,11 @@ struct dw_pcie_ep {
phys_addr_t phys_base;
size_t addr_size;
size_t page_size;
- u8 bar_to_atu[PCI_STD_NUM_BARS];
phys_addr_t *outbound_addr;
unsigned long *ib_window_map;
unsigned long *ob_window_map;
void __iomem *msi_mem;
phys_addr_t msi_mem_phys;
- struct pci_epf_bar *epf_bar[PCI_STD_NUM_BARS];
-
- /* Only for Address Match Mode inbound iATU */
- u32 *ib_atu_indexes[PCI_STD_NUM_BARS];
- unsigned int num_ib_atu_indexes[PCI_STD_NUM_BARS];
/* MSI outbound iATU state */
bool msi_iatu_mapped;
--
2.34.1On Thu, Jan 29, 2026 at 02:47:52PM +0530, Aksh Garg wrote:
> -static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, enum pci_barno bar)
> +static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, u8 func_no, enum pci_barno bar)
> {
> + struct dw_pcie_ep_func *ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> struct device *dev = pci->dev;
> unsigned int i, num;
> @@ -152,18 +157,18 @@ static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, enum pci_barno bar)
> u32 *indexes;
Hello Aksh,
Considering that all other functions that you have modified, you have added a:
if (!ep_func)
return;
I think you should do the same to this function.
>
> /* Tear down the BAR Match Mode mapping, if any. */
> - if (ep->bar_to_atu[bar]) {
> - atu_index = ep->bar_to_atu[bar] - 1;
> + if (ep_func->bar_to_atu[bar]) {
> + atu_index = ep_func->bar_to_atu[bar] - 1;
> dw_pcie_disable_atu(pci, PCIE_ATU_REGION_DIR_IB, atu_index);
> clear_bit(atu_index, ep->ib_window_map);
> - ep->bar_to_atu[bar] = 0;
> + ep_func->bar_to_atu[bar] = 0;
Not related to your patch,
Koichiro (he is on To:),
don't you think that it would be clearer if we had a:
return;
here...
I mean, a BAR can either have a BAR match mode mapping or a subrange mapping,
but not both... So continuing executing code beyond this point seems pointless,
possibly even confusing.
> }
>
> /* Tear down all Address Match Mode mappings, if any. */
> - indexes = ep->ib_atu_indexes[bar];
> - num = ep->num_ib_atu_indexes[bar];
> - ep->ib_atu_indexes[bar] = NULL;
> - ep->num_ib_atu_indexes[bar] = 0;
> + indexes = ep_func->ib_atu_indexes[bar];
> + num = ep_func->num_ib_atu_indexes[bar];
> + ep_func->ib_atu_indexes[bar] = NULL;
> + ep_func->num_ib_atu_indexes[bar] = 0;
> if (!indexes)
> return;
Sure, I see that this code will do a return here...
So there will be no harm done, but, having a simple return above
would make it extra clear to the reader that is is always one or
the other... you cannot have both.
If you agree, perhaps you could send a one liner patch?
> for (i = 0; i < num; i++) {
On 29/01/26 19:44, Niklas Cassel wrote:
> On Thu, Jan 29, 2026 at 02:47:52PM +0530, Aksh Garg wrote:
>> -static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, enum pci_barno bar)
>> +static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, u8 func_no, enum pci_barno bar)
>> {
>> + struct dw_pcie_ep_func *ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
>> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>> struct device *dev = pci->dev;
>> unsigned int i, num;
>> @@ -152,18 +157,18 @@ static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, enum pci_barno bar)
>> u32 *indexes;
>
> Hello Aksh,
>
> Considering that all other functions that you have modified, you have added a:
>
> if (!ep_func)
> return;
>
>
> I think you should do the same to this function.
>
I omitted this NULL check here because all the current call sites of
dw_pcie_ep_clear_ib_maps() already perform this validation. I felt
adding it here would add redundancy in the code.
>
>>
>> /* Tear down the BAR Match Mode mapping, if any. */
>> - if (ep->bar_to_atu[bar]) {
>> - atu_index = ep->bar_to_atu[bar] - 1;
>> + if (ep_func->bar_to_atu[bar]) {
>> + atu_index = ep_func->bar_to_atu[bar] - 1;
>> dw_pcie_disable_atu(pci, PCIE_ATU_REGION_DIR_IB, atu_index);
>> clear_bit(atu_index, ep->ib_window_map);
>> - ep->bar_to_atu[bar] = 0;
>> + ep_func->bar_to_atu[bar] = 0;
On Fri, Jan 30, 2026 at 09:42:43AM +0530, Aksh Garg wrote:
> On 29/01/26 19:44, Niklas Cassel wrote:
> > On Thu, Jan 29, 2026 at 02:47:52PM +0530, Aksh Garg wrote:
> > > -static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, enum pci_barno bar)
> > > +static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, u8 func_no, enum pci_barno bar)
> > > {
> > > + struct dw_pcie_ep_func *ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > struct device *dev = pci->dev;
> > > unsigned int i, num;
> > > @@ -152,18 +157,18 @@ static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, enum pci_barno bar)
> > > u32 *indexes;
> >
> > Hello Aksh,
> >
> > Considering that all other functions that you have modified, you have added a:
> >
> > if (!ep_func)
> > return;
> >
> >
> > I think you should do the same to this function.
> >
>
> I omitted this NULL check here because all the current call sites of
> dw_pcie_ep_clear_ib_maps() already perform this validation. I felt
> adding it here would add redundancy in the code.
Ok, but with that logic, shouldn't we also remove the NULL checks from
dw_pcie_ep_ib_atu_bar() and dw_pcie_ep_ib_atu_addr(), because they are
only called from dw_pcie_ep_set_bar(), which already has the ep_func
NULL check?
Kind regards,
Niklas
On 30/01/26 15:23, Niklas Cassel wrote:
> On Fri, Jan 30, 2026 at 09:42:43AM +0530, Aksh Garg wrote:
>> On 29/01/26 19:44, Niklas Cassel wrote:
>> > On Thu, Jan 29, 2026 at 02:47:52PM +0530, Aksh Garg wrote:
>> > > -static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, enum pci_barno bar)
>> > > +static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, u8 func_no, enum pci_barno bar)
>> > > {
>> > > + struct dw_pcie_ep_func *ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
>> > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>> > > struct device *dev = pci->dev;
>> > > unsigned int i, num;
>> > > @@ -152,18 +157,18 @@ static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, enum pci_barno bar)
>> > > u32 *indexes;
>> >
>> > Hello Aksh,
>> >
>> > Considering that all other functions that you have modified, you have added a:
>> >
>> > if (!ep_func)
>> > return;
>> >
>> >
>> > I think you should do the same to this function.
>> >
>>
>> I omitted this NULL check here because all the current call sites of
>> dw_pcie_ep_clear_ib_maps() already perform this validation. I felt
>> adding it here would add redundancy in the code.
>
> Ok, but with that logic, shouldn't we also remove the NULL checks from
> dw_pcie_ep_ib_atu_bar() and dw_pcie_ep_ib_atu_addr(), because they are
> only called from dw_pcie_ep_set_bar(), which already has the ep_func
> NULL check?
>
Yes, that's correct. Alternatively, we can add the NULL check in
dw_pcie_ep_clear_ib_maps() as well, making all the functions using
ep_func self-contained and defensive, removing the dependency on whether
the callers perform NULL checks. This makes the code more future proof,
as new callers won't need to be aware of the NULL pointer possibility.
Please provide your views on this approach.
>
> Kind regards,
> Niklas
>
On Fri, Jan 30, 2026 at 04:09:26PM +0530, Aksh Garg wrote:
> On 30/01/26 15:23, Niklas Cassel wrote:
> > On Fri, Jan 30, 2026 at 09:42:43AM +0530, Aksh Garg wrote:
> > > On 29/01/26 19:44, Niklas Cassel wrote:
> > > > On Thu, Jan 29, 2026 at 02:47:52PM +0530, Aksh Garg wrote:
> > > > > -static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, enum pci_barno bar)
> > > > > +static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, u8 func_no, enum pci_barno bar)
> > > > > {
> > > > > + struct dw_pcie_ep_func *ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> > > > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > > > > struct device *dev = pci->dev;
> > > > > unsigned int i, num;
> > > > > @@ -152,18 +157,18 @@ static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, enum pci_barno bar)
> > > > > u32 *indexes;
> > > > > Hello Aksh,
> > > > > Considering that all other functions that you have modified, you
> > > have added a:
> > > > > if (!ep_func)
> > > > return;
> > > > > > I think you should do the same to this function.
> > > >
> > >
> > > I omitted this NULL check here because all the current call sites of
> > > dw_pcie_ep_clear_ib_maps() already perform this validation. I felt
> > > adding it here would add redundancy in the code.
> >
> > Ok, but with that logic, shouldn't we also remove the NULL checks from
> > dw_pcie_ep_ib_atu_bar() and dw_pcie_ep_ib_atu_addr(), because they are
> > only called from dw_pcie_ep_set_bar(), which already has the ep_func
> > NULL check?
> >
>
> Yes, that's correct. Alternatively, we can add the NULL check in
> dw_pcie_ep_clear_ib_maps() as well, making all the functions using
> ep_func self-contained and defensive, removing the dependency on whether
> the callers perform NULL checks. This makes the code more future proof,
> as new callers won't need to be aware of the NULL pointer possibility.
Sounds like a good idea to me.
Neither of these functions is in the hot path, so the performance of having
one less NULL check is not super critical.
Kind regards,
Niklas
On 30/01/26 16:17, Niklas Cassel wrote:
> On Fri, Jan 30, 2026 at 04:09:26PM +0530, Aksh Garg wrote:
>> On 30/01/26 15:23, Niklas Cassel wrote:
>> > On Fri, Jan 30, 2026 at 09:42:43AM +0530, Aksh Garg wrote:
>> > > On 29/01/26 19:44, Niklas Cassel wrote:
>> > > > On Thu, Jan 29, 2026 at 02:47:52PM +0530, Aksh Garg wrote:
>> > > > > -static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, enum pci_barno bar)
>> > > > > +static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, u8 func_no, enum pci_barno bar)
>> > > > > {
>> > > > > + struct dw_pcie_ep_func *ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
>> > > > > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
>> > > > > struct device *dev = pci->dev;
>> > > > > unsigned int i, num;
>> > > > > @@ -152,18 +157,18 @@ static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, enum pci_barno bar)
>> > > > > u32 *indexes;
>> > > > > Hello Aksh,
>> > > > > Considering that all other functions that you have modified, you
>> > > have added a:
>> > > > > if (!ep_func)
>> > > > return;
>> > > > > > I think you should do the same to this function.
>> > > >
>> > >
>> > > I omitted this NULL check here because all the current call sites of
>> > > dw_pcie_ep_clear_ib_maps() already perform this validation. I felt
>> > > adding it here would add redundancy in the code.
>> >
>> > Ok, but with that logic, shouldn't we also remove the NULL checks from
>> > dw_pcie_ep_ib_atu_bar() and dw_pcie_ep_ib_atu_addr(), because they are
>> > only called from dw_pcie_ep_set_bar(), which already has the ep_func
>> > NULL check?
>> >
>>
>> Yes, that's correct. Alternatively, we can add the NULL check in
>> dw_pcie_ep_clear_ib_maps() as well, making all the functions using
>> ep_func self-contained and defensive, removing the dependency on whether
>> the callers perform NULL checks. This makes the code more future proof,
>> as new callers won't need to be aware of the NULL pointer possibility.
>
> Sounds like a good idea to me.
>
> Neither of these functions is in the hot path, so the performance of having
> one less NULL check is not super critical.
>
Okay, I will post a new patch series adding the NULL check in the
function.
Regards,
Aksh Garg
>
> Kind regards,
> Niklas
>
On Thu, Jan 29, 2026 at 03:14:51PM +0100, Niklas Cassel wrote:
> On Thu, Jan 29, 2026 at 02:47:52PM +0530, Aksh Garg wrote:
> > -static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, enum pci_barno bar)
> > +static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, u8 func_no, enum pci_barno bar)
> > {
> > + struct dw_pcie_ep_func *ep_func = dw_pcie_ep_get_func_from_ep(ep, func_no);
> > struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> > struct device *dev = pci->dev;
> > unsigned int i, num;
> > @@ -152,18 +157,18 @@ static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, enum pci_barno bar)
> > u32 *indexes;
>
> Hello Aksh,
>
> Considering that all other functions that you have modified, you have added a:
>
> if (!ep_func)
> return;
>
>
> I think you should do the same to this function.
>
>
> >
> > /* Tear down the BAR Match Mode mapping, if any. */
> > - if (ep->bar_to_atu[bar]) {
> > - atu_index = ep->bar_to_atu[bar] - 1;
> > + if (ep_func->bar_to_atu[bar]) {
> > + atu_index = ep_func->bar_to_atu[bar] - 1;
> > dw_pcie_disable_atu(pci, PCIE_ATU_REGION_DIR_IB, atu_index);
> > clear_bit(atu_index, ep->ib_window_map);
> > - ep->bar_to_atu[bar] = 0;
> > + ep_func->bar_to_atu[bar] = 0;
>
> Not related to your patch,
>
> Koichiro (he is on To:),
>
> don't you think that it would be clearer if we had a:
> return;
>
> here...
>
> I mean, a BAR can either have a BAR match mode mapping or a subrange mapping,
> but not both... So continuing executing code beyond this point seems pointless,
> possibly even confusing.
Thanks for pinging. I agree it would be clearer. Since it's orthogonal to
this series, would it be better if I sent a one-line patch?
By the way, Aksh, thank you for addressing the newly added address-match
mode case.
Koichiro
>
>
> > }
> >
> > /* Tear down all Address Match Mode mappings, if any. */
> > - indexes = ep->ib_atu_indexes[bar];
> > - num = ep->num_ib_atu_indexes[bar];
> > - ep->ib_atu_indexes[bar] = NULL;
> > - ep->num_ib_atu_indexes[bar] = 0;
> > + indexes = ep_func->ib_atu_indexes[bar];
> > + num = ep_func->num_ib_atu_indexes[bar];
> > + ep_func->ib_atu_indexes[bar] = NULL;
> > + ep_func->num_ib_atu_indexes[bar] = 0;
> > if (!indexes)
> > return;
>
> Sure, I see that this code will do a return here...
>
> So there will be no harm done, but, having a simple return above
> would make it extra clear to the reader that is is always one or
> the other... you cannot have both.
>
> If you agree, perhaps you could send a one liner patch?
>
>
> > for (i = 0; i < num; i++) {
On Fri, Jan 30, 2026 at 11:21:32AM +0900, Koichiro Den wrote: > > > > Koichiro (he is on To:), > > > > don't you think that it would be clearer if we had a: > > return; > > > > here... > > > > I mean, a BAR can either have a BAR match mode mapping or a subrange mapping, > > but not both... So continuing executing code beyond this point seems pointless, > > possibly even confusing. > > Thanks for pinging. I agree it would be clearer. Since it's orthogonal to > this series, would it be better if I sent a one-line patch? Thank you Koichiro, I think a one liner patch for this would be nice. You can also write in the changelog (after the ----) that Mani can squash your one liner patch into the existing submap commit if he wants. Kind regards, Niklas
On Fri, Jan 30, 2026 at 10:57:18AM +0100, Niklas Cassel wrote:
> On Fri, Jan 30, 2026 at 11:21:32AM +0900, Koichiro Den wrote:
> > >
> > > Koichiro (he is on To:),
> > >
> > > don't you think that it would be clearer if we had a:
> > > return;
> > >
> > > here...
> > >
> > > I mean, a BAR can either have a BAR match mode mapping or a subrange mapping,
> > > but not both... So continuing executing code beyond this point seems pointless,
> > > possibly even confusing.
> >
> > Thanks for pinging. I agree it would be clearer. Since it's orthogonal to
> > this series, would it be better if I sent a one-line patch?
>
> Thank you Koichiro, I think a one liner patch for this would be nice.
>
> You can also write in the changelog (after the ----) that Mani can squash
> your one liner patch into the existing submap commit if he wants.
While looking at this, I spotted a subtle corner case that the missing
'return' has been masking.
Consider the following re-programming sequence for a BAR:
1) The initial set_bar() programs the BAR in BAR Match Mode
2) The second set_bar() switches the BAR to Address Match Mode
- Ad part of this, set_bar() calls dw_pcie_ep_clear_ib_maps() before
re-programming.
3) The third set_bar() switches back to BAR Match Mode.
In step (3), the current behavior depends on how the caller handles the
struct pci_epf_bar passed to set_bar()
a) If the caller passes a freshly prepared epf_bar with .num_submap = 0,
dw_pcie_ep_clear_ib_maps() is called as expected.
b) If the caller updates the same epf_bar in place (i.e. reused the
object that passed in step (2)) and simply updates .num_submap back to
0, dw_pcie_ep_clear_ib_maps() is NOT called because the condition in
[1] evaluates to false. The recently merged (my) pci-epf-test code
follows this patter, see [2].
The point is that ep_func->epf_bar[bar] only stores a pointer, and the
actual object is owned by the API caller. Since struct pci_epf embeds the
BAR descriptors, updating an epf_bar in place (pattern (b)) seems quite
natural and, in my view, should be supported. Requiring callers to always
pass a new epf_bar (pattern (a)) feels contrary to the current
API/data-structure design.
Given that, I think the cleares fix is:
diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
index dd48e60b513c..a20cff98b797 100644
--- a/drivers/pci/controller/dwc/pcie-designware-ep.c
+++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
@@ -165,6 +165,9 @@ static void dw_pcie_ep_clear_ib_maps(struct dw_pcie_ep *ep, u8 func_no, enum pci
dw_pcie_disable_atu(pci, PCIE_ATU_REGION_DIR_IB, atu_index);
clear_bit(atu_index, ep->ib_window_map);
ep_func->bar_to_atu[bar] = 0;
+
+ WARN_ON(ep_func->ib_atu_indexes[bar]);
+ return;
}
/* Tear down all Address Match Mode mappings, if any. */
@@ -528,8 +531,7 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
* When dynamically changing a BAR, tear down any existing
* mappings before re-programming.
*/
- if (ep_func->epf_bar[bar]->num_submap || epf_bar->num_submap)
- dw_pcie_ep_clear_ib_maps(ep, func_no, bar);
+ dw_pcie_ep_clear_ib_maps(ep, func_no, bar);
/*
* When dynamically changing a BAR, skip writing the BAR reg, as
---8<---
One downside is that this introduces a behavioral change in a specific
failure case that already existed prior to this series.
Concretely, this only affects the traditional reprogramming path where a
BAR configured in BAR Match Mode is updated again to BAR Match Mode. If
such an update fails (for example, because the new epf_bar->phys_addr is
not aligned to region_align), the behavior changes as follows:
- Before this change: the previously programmed BAR Match Mode mapping
remains in place.
- After this change: the existing mapping is torn down first, so no mapping
remains after the failure.
I don't think this change is a major issue, since the caller will still
observe the failure and should handle the error accordingly in either case.
That said, I'd appreciate feedback if retaining the old BAR Match Mode
mapping on such failure scenario is considered important for the existing
update path.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/tree/drivers/pci/controller/dwc/pcie-designware-ep.c?h=controller/dwc&id=0e2b9294512c140576c340b7ccd24230a593f30b#n531
[2] https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/tree/drivers/pci/endpoint/functions/pci-epf-test.c?h=controller/dwc&id=0e2b9294512c140576c340b7ccd24230a593f30b#n950
Kind regards,
Koichiro
>
>
> Kind regards,
> Niklas
Hello Koichiro,
On Sat, Jan 31, 2026 at 02:16:37AM +0900, Koichiro Den wrote:
> While looking at this, I spotted a subtle corner case that the missing
> 'return' has been masking.
>
> Consider the following re-programming sequence for a BAR:
>
> 1) The initial set_bar() programs the BAR in BAR Match Mode
> 2) The second set_bar() switches the BAR to Address Match Mode
> - Ad part of this, set_bar() calls dw_pcie_ep_clear_ib_maps() before
> re-programming.
> 3) The third set_bar() switches back to BAR Match Mode.
>
> In step (3), the current behavior depends on how the caller handles the
> struct pci_epf_bar passed to set_bar()
>
> a) If the caller passes a freshly prepared epf_bar with .num_submap = 0,
> dw_pcie_ep_clear_ib_maps() is called as expected.
>
> b) If the caller updates the same epf_bar in place (i.e. reused the
> object that passed in step (2)) and simply updates .num_submap back to
> 0, dw_pcie_ep_clear_ib_maps() is NOT called because the condition in
> [1] evaluates to false. The recently merged (my) pci-epf-test code
> follows this patter, see [2].
>
> The point is that ep_func->epf_bar[bar] only stores a pointer, and the
> actual object is owned by the API caller. Since struct pci_epf embeds the
> BAR descriptors, updating an epf_bar in place (pattern (b)) seems quite
> natural and, in my view, should be supported.
(cut)
> Requiring callers to always pass a new epf_bar (pattern (a)) feels
> contrary to the current API/data-structure design.
I disagree.
I previously suggested that you should look at pci_epf_test_enable_doorbell()
and pci_epf_test_disable_doorbell().
If we look at the workflow in pci-epf-test for the doorbell test case:
1)
pci_epf_test_epc_init() calls pci_epf_test_set_bar() which calls
pci_epc_set_bar(..., &epf->bar[bar]);
2)
pci_epf_test_enable_doorbell()
uses a new struct pci_epf_bar (epf_test->db_bar)
copies the barno, size and flags for the BAR is will dynamically change:
epf_test->db_bar.barno = bar;
epf_test->db_bar.size = epf->bar[bar].size;
epf_test->db_bar.flags = epf->bar[bar].flags;
calls pci_epc_set_bar(..., &epf_test->db_bar);
3)
pci_epf_test_disable_doorbell() calls
pci_epc_set_bar(..., &epf->bar[bar]);
with the original unmodified struct pci_epf_bar.
Your new test case however, reuses epf->bar[bar] in step 1, 2, 3.
I think the solution is to change your test case so that you use same
workflow as the doorbell test case. Just add a new struct pci_epf_bar
to struct pci_epf_test where you store the temporary BAR.
I'm not a big fan of your suggested code changes.
I think adding the early return in dw_pcie_ep_clear_ib_maps() and
modifying your test case to use a new epf_bar are the only things
that should be fixed as soon as possible.
> One downside is that this introduces a behavioral change in a specific
> failure case that already existed prior to this series.
>
> Concretely, this only affects the traditional reprogramming path where a
> BAR configured in BAR Match Mode is updated again to BAR Match Mode. If
> such an update fails (for example, because the new epf_bar->phys_addr is
> not aligned to region_align), the behavior changes as follows:
>
> - Before this change: the previously programmed BAR Match Mode mapping
> remains in place.
> - After this change: the existing mapping is torn down first, so no mapping
> remains after the failure.
>
> I don't think this change is a major issue, since the caller will still
> observe the failure and should handle the error accordingly in either case.
> That said, I'd appreciate feedback if retaining the old BAR Match Mode
> mapping on such failure scenario is considered important for the existing
> update path.
You have found a potential problem with the API though, but like you said,
this problem was there even before your changes, so this problem can take
more time to be addressed.
Since the DWC EP driver only stores pointers to struct pci_epf_bar BARs
in set_bar(), it is theoretically possible for the caller to modify this
struct after calling set_bar(). This means that any future safety check
against values in ep_func->epf_bar (e.g. [1]) is unreliable, as the caller
could have modified the struct after calling set_bar().
[1] https://github.com/torvalds/linux/blob/v6.19-rc7/drivers/pci/controller/dwc/pcie-designware-ep.c#L368-L370
I think the solution to this is to modify struct dw_pcie_ep_func:
@@ -472,7 +472,7 @@ struct dw_pcie_ep_func {
u8 msi_cap; /* MSI capability offset */
u8 msix_cap; /* MSI-X capability offset */
u8 bar_to_atu[PCI_STD_NUM_BARS];
- struct pci_epf_bar *epf_bar[PCI_STD_NUM_BARS];
+ struct pci_epf_bar epf_bar[PCI_STD_NUM_BARS];
/* Only for Address Match Mode inbound iATU */
u32 *ib_atu_indexes[PCI_STD_NUM_BARS];
And then modify set_bar() to something like:
@@ -588,7 +588,7 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
if (ret)
return ret;
- ep_func->epf_bar[bar] = epf_bar;
+ memcpy(&ep_func->epf_bar[bar], epf_bar, sizeof *epf_bar);
return 0;
}
But that would also mean that we need to modify the if (ep_func->epf_bar[bar])
with something like if (ep_func->epf_bar_in_use[bar])
Or... I guess we could keep it as pointers, but use kmemdup() in set_bar()
to get our own immutable copy, and then kfree() the pointer in clear_bar()
(and in set_bar() before kmemduping the memory, if the DWC driver already
has a local copy (i.e. dynamically changing the BAR without first calling
clear_bar()))
Kind regards,
Niklas
On Fri, Jan 30, 2026 at 11:51:33PM +0100, Niklas Cassel wrote:
> Hello Koichiro,
>
> On Sat, Jan 31, 2026 at 02:16:37AM +0900, Koichiro Den wrote:
> > While looking at this, I spotted a subtle corner case that the missing
> > 'return' has been masking.
> >
> > Consider the following re-programming sequence for a BAR:
> >
> > 1) The initial set_bar() programs the BAR in BAR Match Mode
> > 2) The second set_bar() switches the BAR to Address Match Mode
> > - Ad part of this, set_bar() calls dw_pcie_ep_clear_ib_maps() before
> > re-programming.
> > 3) The third set_bar() switches back to BAR Match Mode.
> >
> > In step (3), the current behavior depends on how the caller handles the
> > struct pci_epf_bar passed to set_bar()
> >
> > a) If the caller passes a freshly prepared epf_bar with .num_submap = 0,
> > dw_pcie_ep_clear_ib_maps() is called as expected.
> >
> > b) If the caller updates the same epf_bar in place (i.e. reused the
> > object that passed in step (2)) and simply updates .num_submap back to
> > 0, dw_pcie_ep_clear_ib_maps() is NOT called because the condition in
> > [1] evaluates to false. The recently merged (my) pci-epf-test code
> > follows this patter, see [2].
> >
> > The point is that ep_func->epf_bar[bar] only stores a pointer, and the
> > actual object is owned by the API caller. Since struct pci_epf embeds the
> > BAR descriptors, updating an epf_bar in place (pattern (b)) seems quite
> > natural and, in my view, should be supported.
>
> (cut)
>
> > Requiring callers to always pass a new epf_bar (pattern (a)) feels
> > contrary to the current API/data-structure design.
>
> I disagree.
>
> I previously suggested that you should look at pci_epf_test_enable_doorbell()
> and pci_epf_test_disable_doorbell().
>
> If we look at the workflow in pci-epf-test for the doorbell test case:
>
> 1)
> pci_epf_test_epc_init() calls pci_epf_test_set_bar() which calls
> pci_epc_set_bar(..., &epf->bar[bar]);
>
> 2)
> pci_epf_test_enable_doorbell()
> uses a new struct pci_epf_bar (epf_test->db_bar)
>
> copies the barno, size and flags for the BAR is will dynamically change:
> epf_test->db_bar.barno = bar;
> epf_test->db_bar.size = epf->bar[bar].size;
> epf_test->db_bar.flags = epf->bar[bar].flags;
> calls pci_epc_set_bar(..., &epf_test->db_bar);
>
> 3)
> pci_epf_test_disable_doorbell() calls
> pci_epc_set_bar(..., &epf->bar[bar]);
> with the original unmodified struct pci_epf_bar.
>
>
> Your new test case however, reuses epf->bar[bar] in step 1, 2, 3.
>
> I think the solution is to change your test case so that you use same
> workflow as the doorbell test case. Just add a new struct pci_epf_bar
> to struct pci_epf_test where you store the temporary BAR.
>
>
> I'm not a big fan of your suggested code changes.
>
> I think adding the early return in dw_pcie_ep_clear_ib_maps() and
> modifying your test case to use a new epf_bar are the only things
> that should be fixed as soon as possible.
>
Thanks, that makes sense. I was a bit confused initially, so I'd like to
make the API rule explicit in the documentation to avoid further ambiguity.
I have just submitted a separate patch series:
https://lore.kernel.org/linux-pci/20260131133655.218018-1-den@valinux.co.jp
In this series, [PATCH 3/3] adds text describing the caller ownership and
lifetime rules for pci_epc_set_bar().
>
> > One downside is that this introduces a behavioral change in a specific
> > failure case that already existed prior to this series.
> >
> > Concretely, this only affects the traditional reprogramming path where a
> > BAR configured in BAR Match Mode is updated again to BAR Match Mode. If
> > such an update fails (for example, because the new epf_bar->phys_addr is
> > not aligned to region_align), the behavior changes as follows:
> >
> > - Before this change: the previously programmed BAR Match Mode mapping
> > remains in place.
> > - After this change: the existing mapping is torn down first, so no mapping
> > remains after the failure.
> >
> > I don't think this change is a major issue, since the caller will still
> > observe the failure and should handle the error accordingly in either case.
> > That said, I'd appreciate feedback if retaining the old BAR Match Mode
> > mapping on such failure scenario is considered important for the existing
> > update path.
>
> You have found a potential problem with the API though, but like you said,
> this problem was there even before your changes, so this problem can take
> more time to be addressed.
>
> Since the DWC EP driver only stores pointers to struct pci_epf_bar BARs
> in set_bar(), it is theoretically possible for the caller to modify this
> struct after calling set_bar(). This means that any future safety check
> against values in ep_func->epf_bar (e.g. [1]) is unreliable, as the caller
> could have modified the struct after calling set_bar().
>
> [1] https://github.com/torvalds/linux/blob/v6.19-rc7/drivers/pci/controller/dwc/pcie-designware-ep.c#L368-L370
>
> I think the solution to this is to modify struct dw_pcie_ep_func:
>
> @@ -472,7 +472,7 @@ struct dw_pcie_ep_func {
> u8 msi_cap; /* MSI capability offset */
> u8 msix_cap; /* MSI-X capability offset */
> u8 bar_to_atu[PCI_STD_NUM_BARS];
> - struct pci_epf_bar *epf_bar[PCI_STD_NUM_BARS];
> + struct pci_epf_bar epf_bar[PCI_STD_NUM_BARS];
>
> /* Only for Address Match Mode inbound iATU */
> u32 *ib_atu_indexes[PCI_STD_NUM_BARS];
>
>
>
> And then modify set_bar() to something like:
>
> @@ -588,7 +588,7 @@ static int dw_pcie_ep_set_bar(struct pci_epc *epc, u8 func_no, u8 vfunc_no,
> if (ret)
> return ret;
>
> - ep_func->epf_bar[bar] = epf_bar;
> + memcpy(&ep_func->epf_bar[bar], epf_bar, sizeof *epf_bar);
>
> return 0;
> }
>
>
> But that would also mean that we need to modify the if (ep_func->epf_bar[bar])
> with something like if (ep_func->epf_bar_in_use[bar])
>
> Or... I guess we could keep it as pointers, but use kmemdup() in set_bar()
> to get our own immutable copy, and then kfree() the pointer in clear_bar()
> (and in set_bar() before kmemduping the memory, if the DWC driver already
> has a local copy (i.e. dynamically changing the BAR without first calling
> clear_bar()))
That feels like the right direction. I'll take a closer look at that, but
if you decide to work on it first, please feel free to go ahead. I'd be
happy to help with testing.
Thank you very much for the careful review and discussion.
Kind regards,
Koichiro
>
>
> Kind regards,
> Niklas
© 2016 - 2026 Red Hat, Inc.