[PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Koichiro Den]

When the BAR subrange mapping test on DWC-based platforms fails due to
insufficient free inbound iATU regions,
pci_epf_test_bar_subrange_setup() returns an error (-ENOSPC) but does
not restore the original BAR mapping. This causes subsequent test runs
to become confusing, since the failure may leave room for the next
subrange mapping test to pass.

Fix this by restoring the original BAR mapping when preparation of the
subrange mapping fails, so that no side effect remains regardless of the
test success or failure.

Fixes: 6c5e6101423b ("PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support")
Reported-by: Christian Bruel <christian.bruel@foss.st.com>
Closes: https://lore.kernel.org/linux-pci/b2b03ebe-9482-4a13-b22f-7b44da096eed@foss.st.com/
Signed-off-by: Koichiro Den <den@valinux.co.jp>
---
 drivers/pci/endpoint/functions/pci-epf-test.c | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
index 14e61ebe1f11..f44c36f5cac5 100644
--- a/drivers/pci/endpoint/functions/pci-epf-test.c
+++ b/drivers/pci/endpoint/functions/pci-epf-test.c
@@ -898,16 +898,22 @@ static void pci_epf_test_bar_subrange_setup(struct pci_epf_test *epf_test,
 	bar->submap = submap;
 	bar->num_submap = nsub;
 
 	ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
 	if (ret) {
 		dev_err(&epf->dev, "pci_epc_set_bar() failed: %d\n", ret);
 		bar->submap = old_submap;
 		bar->num_submap = old_nsub;
+		ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
+		if (ret)
+			dev_warn(&epf->dev,
+				 "failed to restore the original BAR mapping: %d\n",
+				 ret);
+
 		kfree(submap);
 		goto err;
 	}
 	kfree(old_submap);
 
 	/*
 	 * Fill deterministic signatures into the physical regions that
 	 * each BAR subrange maps to. RC verifies these to ensure the
-- 
2.51.0

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Koichiro Den]

On Mon, Mar 16, 2026 at 11:02:25PM +0900, Koichiro Den wrote:
> When the BAR subrange mapping test on DWC-based platforms fails due to
> insufficient free inbound iATU regions,
> pci_epf_test_bar_subrange_setup() returns an error (-ENOSPC) but does
> not restore the original BAR mapping. This causes subsequent test runs
> to become confusing, since the failure may leave room for the next
> subrange mapping test to pass.
> 
> Fix this by restoring the original BAR mapping when preparation of the
> subrange mapping fails, so that no side effect remains regardless of the
> test success or failure.
> 
> Fixes: 6c5e6101423b ("PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support")
> Reported-by: Christian Bruel <christian.bruel@foss.st.com>
> Closes: https://lore.kernel.org/linux-pci/b2b03ebe-9482-4a13-b22f-7b44da096eed@foss.st.com/
> Signed-off-by: Koichiro Den <den@valinux.co.jp>
> ---
>  drivers/pci/endpoint/functions/pci-epf-test.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> index 14e61ebe1f11..f44c36f5cac5 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -898,16 +898,22 @@ static void pci_epf_test_bar_subrange_setup(struct pci_epf_test *epf_test,
>  	bar->submap = submap;
>  	bar->num_submap = nsub;
>  
>  	ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
>  	if (ret) {
>  		dev_err(&epf->dev, "pci_epc_set_bar() failed: %d\n", ret);
>  		bar->submap = old_submap;
>  		bar->num_submap = old_nsub;
> +		ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
> +		if (ret)
> +			dev_warn(&epf->dev,
> +				 "failed to restore the original BAR mapping: %d\n",
> +				 ret);

Ugh, sorry, let me send v2. I accidentally overwrote 'ret'.

Koichiro

> +
>  		kfree(submap);
>  		goto err;
>  	}
>  	kfree(old_submap);
>  
>  	/*
>  	 * Fill deterministic signatures into the physical regions that
>  	 * each BAR subrange maps to. RC verifies these to ensure the
> -- 
> 2.51.0
> 
> 

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Koichiro Den]

On Mon, Mar 16, 2026 at 11:36:07PM +0900, Koichiro Den wrote:
> On Mon, Mar 16, 2026 at 11:02:25PM +0900, Koichiro Den wrote:
> > When the BAR subrange mapping test on DWC-based platforms fails due to
> > insufficient free inbound iATU regions,
> > pci_epf_test_bar_subrange_setup() returns an error (-ENOSPC) but does
> > not restore the original BAR mapping. This causes subsequent test runs
> > to become confusing, since the failure may leave room for the next
> > subrange mapping test to pass.
> > 
> > Fix this by restoring the original BAR mapping when preparation of the
> > subrange mapping fails, so that no side effect remains regardless of the
> > test success or failure.
> > 
> > Fixes: 6c5e6101423b ("PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support")
> > Reported-by: Christian Bruel <christian.bruel@foss.st.com>
> > Closes: https://lore.kernel.org/linux-pci/b2b03ebe-9482-4a13-b22f-7b44da096eed@foss.st.com/
> > Signed-off-by: Koichiro Den <den@valinux.co.jp>
> > ---
> >  drivers/pci/endpoint/functions/pci-epf-test.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> > index 14e61ebe1f11..f44c36f5cac5 100644
> > --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> > @@ -898,16 +898,22 @@ static void pci_epf_test_bar_subrange_setup(struct pci_epf_test *epf_test,
> >  	bar->submap = submap;
> >  	bar->num_submap = nsub;
> >  
> >  	ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
> >  	if (ret) {
> >  		dev_err(&epf->dev, "pci_epc_set_bar() failed: %d\n", ret);
> >  		bar->submap = old_submap;
> >  		bar->num_submap = old_nsub;
> > +		ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
> > +		if (ret)
> > +			dev_warn(&epf->dev,
> > +				 "failed to restore the original BAR mapping: %d\n",
> > +				 ret);
> 
> Ugh, sorry, let me send v2. I accidentally overwrote 'ret'.

Never mind, my mistake. The code is fine as is. Sorry for the noise.

Koichiro

> 
> Koichiro
> 
> > +
> >  		kfree(submap);
> >  		goto err;
> >  	}
> >  	kfree(old_submap);
> >  
> >  	/*
> >  	 * Fill deterministic signatures into the physical regions that
> >  	 * each BAR subrange maps to. RC verifies these to ensure the
> > -- 
> > 2.51.0
> > 
> > 

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Niklas Cassel]

On Mon, Mar 16, 2026 at 11:02:25PM +0900, Koichiro Den wrote:
> When the BAR subrange mapping test on DWC-based platforms fails due to
> insufficient free inbound iATU regions,
> pci_epf_test_bar_subrange_setup() returns an error (-ENOSPC) but does
> not restore the original BAR mapping. This causes subsequent test runs
> to become confusing, since the failure may leave room for the next
> subrange mapping test to pass.
> 
> Fix this by restoring the original BAR mapping when preparation of the
> subrange mapping fails, so that no side effect remains regardless of the
> test success or failure.
> 
> Fixes: 6c5e6101423b ("PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support")
> Reported-by: Christian Bruel <christian.bruel@foss.st.com>
> Closes: https://lore.kernel.org/linux-pci/b2b03ebe-9482-4a13-b22f-7b44da096eed@foss.st.com/
> Signed-off-by: Koichiro Den <den@valinux.co.jp>
> ---
>  drivers/pci/endpoint/functions/pci-epf-test.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> index 14e61ebe1f11..f44c36f5cac5 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -898,16 +898,22 @@ static void pci_epf_test_bar_subrange_setup(struct pci_epf_test *epf_test,
>  	bar->submap = submap;
>  	bar->num_submap = nsub;
>  
>  	ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
>  	if (ret) {
>  		dev_err(&epf->dev, "pci_epc_set_bar() failed: %d\n", ret);
>  		bar->submap = old_submap;
>  		bar->num_submap = old_nsub;
> +		ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
> +		if (ret)
> +			dev_warn(&epf->dev,
> +				 "failed to restore the original BAR mapping: %d\n",

Nit:
I would use a capitalized F:
"Failed to restore ..."

in order to match most other prints in this file.

Reviewed-by: Niklas Cassel <cassel@kernel.org>

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Koichiro Den]

On Mon, Mar 16, 2026 at 05:19:26PM +0100, Niklas Cassel wrote:
> On Mon, Mar 16, 2026 at 11:02:25PM +0900, Koichiro Den wrote:
> > When the BAR subrange mapping test on DWC-based platforms fails due to
> > insufficient free inbound iATU regions,
> > pci_epf_test_bar_subrange_setup() returns an error (-ENOSPC) but does
> > not restore the original BAR mapping. This causes subsequent test runs
> > to become confusing, since the failure may leave room for the next
> > subrange mapping test to pass.
> > 
> > Fix this by restoring the original BAR mapping when preparation of the
> > subrange mapping fails, so that no side effect remains regardless of the
> > test success or failure.
> > 
> > Fixes: 6c5e6101423b ("PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support")
> > Reported-by: Christian Bruel <christian.bruel@foss.st.com>
> > Closes: https://lore.kernel.org/linux-pci/b2b03ebe-9482-4a13-b22f-7b44da096eed@foss.st.com/
> > Signed-off-by: Koichiro Den <den@valinux.co.jp>
> > ---
> >  drivers/pci/endpoint/functions/pci-epf-test.c | 6 ++++++
> >  1 file changed, 6 insertions(+)
> > 
> > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> > index 14e61ebe1f11..f44c36f5cac5 100644
> > --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> > @@ -898,16 +898,22 @@ static void pci_epf_test_bar_subrange_setup(struct pci_epf_test *epf_test,
> >  	bar->submap = submap;
> >  	bar->num_submap = nsub;
> >  
> >  	ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
> >  	if (ret) {
> >  		dev_err(&epf->dev, "pci_epc_set_bar() failed: %d\n", ret);
> >  		bar->submap = old_submap;
> >  		bar->num_submap = old_nsub;
> > +		ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
> > +		if (ret)
> > +			dev_warn(&epf->dev,
> > +				 "failed to restore the original BAR mapping: %d\n",
> 
> Nit:
> I would use a capitalized F:
> "Failed to restore ..."
> 
> in order to match most other prints in this file.

Agree. Bjorn or Mani, please feel free to fix this up (i.e. s/failed/Failed/)
when applying, to avoid a respin for such a minor change.

> 
> Reviewed-by: Niklas Cassel <cassel@kernel.org>

Thanks again for reviewing, Niklas.

Christian, if possible, it would be very helpful if you could take a look or
test this slightly polished version and add a Tested-by or Reviewed-by.

Best regards,
Koichiro

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Manivannan Sadhasivam]

On Tue, Mar 17, 2026 at 11:57:06AM +0900, Koichiro Den wrote:
> On Mon, Mar 16, 2026 at 05:19:26PM +0100, Niklas Cassel wrote:
> > On Mon, Mar 16, 2026 at 11:02:25PM +0900, Koichiro Den wrote:
> > > When the BAR subrange mapping test on DWC-based platforms fails due to
> > > insufficient free inbound iATU regions,
> > > pci_epf_test_bar_subrange_setup() returns an error (-ENOSPC) but does
> > > not restore the original BAR mapping. This causes subsequent test runs
> > > to become confusing, since the failure may leave room for the next
> > > subrange mapping test to pass.
> > > 
> > > Fix this by restoring the original BAR mapping when preparation of the
> > > subrange mapping fails, so that no side effect remains regardless of the
> > > test success or failure.
> > > 
> > > Fixes: 6c5e6101423b ("PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support")
> > > Reported-by: Christian Bruel <christian.bruel@foss.st.com>
> > > Closes: https://lore.kernel.org/linux-pci/b2b03ebe-9482-4a13-b22f-7b44da096eed@foss.st.com/
> > > Signed-off-by: Koichiro Den <den@valinux.co.jp>
> > > ---
> > >  drivers/pci/endpoint/functions/pci-epf-test.c | 6 ++++++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> > > index 14e61ebe1f11..f44c36f5cac5 100644
> > > --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> > > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> > > @@ -898,16 +898,22 @@ static void pci_epf_test_bar_subrange_setup(struct pci_epf_test *epf_test,
> > >  	bar->submap = submap;
> > >  	bar->num_submap = nsub;
> > >  
> > >  	ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
> > >  	if (ret) {
> > >  		dev_err(&epf->dev, "pci_epc_set_bar() failed: %d\n", ret);
> > >  		bar->submap = old_submap;
> > >  		bar->num_submap = old_nsub;
> > > +		ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
> > > +		if (ret)
> > > +			dev_warn(&epf->dev,
> > > +				 "failed to restore the original BAR mapping: %d\n",
> > 
> > Nit:
> > I would use a capitalized F:
> > "Failed to restore ..."
> > 
> > in order to match most other prints in this file.
> 
> Agree. Bjorn or Mani, please feel free to fix this up (i.e. s/failed/Failed/)
> when applying, to avoid a respin for such a minor change.
> 

Reviewed-by: Manivannan Sadhasivam <mani@kernel.org>

I hope Bjorn will merge this patch for -rcX. But it also warrants tested-by from
Christian.

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Christian Bruel]

On 3/17/26 03:57, Koichiro Den wrote:
> On Mon, Mar 16, 2026 at 05:19:26PM +0100, Niklas Cassel wrote:
>> On Mon, Mar 16, 2026 at 11:02:25PM +0900, Koichiro Den wrote:
>>> When the BAR subrange mapping test on DWC-based platforms fails due to
>>> insufficient free inbound iATU regions,
>>> pci_epf_test_bar_subrange_setup() returns an error (-ENOSPC) but does
>>> not restore the original BAR mapping. This causes subsequent test runs
>>> to become confusing, since the failure may leave room for the next
>>> subrange mapping test to pass.
>>>
>>> Fix this by restoring the original BAR mapping when preparation of the
>>> subrange mapping fails, so that no side effect remains regardless of the
>>> test success or failure.
>>>
>>> Fixes: 6c5e6101423b ("PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support")
>>> Reported-by: Christian Bruel <christian.bruel@foss.st.com>
>>> Closes: https://lore.kernel.org/linux-pci/b2b03ebe-9482-4a13-b22f-7b44da096eed@foss.st.com/
>>> Signed-off-by: Koichiro Den <den@valinux.co.jp>
>>> ---
>>>   drivers/pci/endpoint/functions/pci-epf-test.c | 6 ++++++
>>>   1 file changed, 6 insertions(+)
>>>
>>> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
>>> index 14e61ebe1f11..f44c36f5cac5 100644
>>> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
>>> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
>>> @@ -898,16 +898,22 @@ static void pci_epf_test_bar_subrange_setup(struct pci_epf_test *epf_test,
>>>   	bar->submap = submap;
>>>   	bar->num_submap = nsub;
>>>   
>>>   	ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
>>>   	if (ret) {
>>>   		dev_err(&epf->dev, "pci_epc_set_bar() failed: %d\n", ret);
>>>   		bar->submap = old_submap;
>>>   		bar->num_submap = old_nsub;
>>> +		ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
>>> +		if (ret)
>>> +			dev_warn(&epf->dev,
>>> +				 "failed to restore the original BAR mapping: %d\n",
>>
>> Nit:
>> I would use a capitalized F:
>> "Failed to restore ..."
>>
>> in order to match most other prints in this file.
> 
> Agree. Bjorn or Mani, please feel free to fix this up (i.e. s/failed/Failed/)
> when applying, to avoid a respin for such a minor change.
> 
>>
>> Reviewed-by: Niklas Cassel <cassel@kernel.org>
> 
> Thanks again for reviewing, Niklas.
> 
> Christian, if possible, it would be very helpful if you could take a look or
> test this slightly polished version and add a Tested-by or Reviewed-by.

Tested-by: Christian Bruel <christian.bruel@foss.st.com>

with the DISABLE BAR dependency
https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=endpoint&id=33642e9e36dc084e4fc9245a266c9843bc8303b9

I will need to update the pci_epc_features after the merge.

A more general question: I don't understand why only the STM32 is 
impacted. It seems that all targets, even those with 6 IB iATU entries, 
should ensure that one BAR is disabled to handle subranges.

In other words, will there always be at least one BAR_TEST BAR variant 
that is skipped for all platforms, or am I missing something here?

thank you

Christian


> 
> Best regards,
> Koichiro

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Niklas Cassel]

On Tue, Mar 17, 2026 at 10:13:52AM +0100, Christian Bruel wrote:
> 
> Tested-by: Christian Bruel <christian.bruel@foss.st.com>
> 
> with the DISABLE BAR dependency
> https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=endpoint&id=33642e9e36dc084e4fc9245a266c9843bc8303b9
> 
> I will need to update the pci_epc_features after the merge.

I don't think you should update pci_epc_features just to be able to test
the inbound submapping feature.

As I said before, I think a better option would to ensure that the test is
skipped instead of returning failure, for SoCs with too few inbound iATUs.

A real EPF driver (not the test driver), that wants to run on STM32, and
wants to use inbound submapping feature, can simply ensure that it does not
enable all BARs (the test driver obviously enables all BARs, since it wants
to test all BARs). That way, that EPF driver will be able to use multiple
iATUs for a single BAR (as required by this new feature).

This works because all BARs are disabled by default. An EPF driver has to
enable the BARs it wants to use. (E.g. nvmet-pci-epf only enables BAR0.)


> 
> A more general question: I don't understand why only the STM32 is impacted.
> It seems that all targets, even those with 6 IB iATU entries, should ensure
> that one BAR is disabled to handle subranges.

I can't speak for every SoC, but looking at dmesg:
rockchip-dw-pcie a40000000.pcie-ep: iATU: unroll T, 16 ob, 16 ib, align 64K, limit 8G

rk3588 has 16 inbound windows.

Probably most SoCs have more than 6 ib windows?


Kind regards,
Niklas

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Christian Bruel]

On 3/17/26 10:24, Niklas Cassel wrote:
> On Tue, Mar 17, 2026 at 10:13:52AM +0100, Christian Bruel wrote:
>>
>> Tested-by: Christian Bruel <christian.bruel@foss.st.com>
>>
>> with the DISABLE BAR dependency
>> https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=endpoint&id=33642e9e36dc084e4fc9245a266c9843bc8303b9
>>
>> I will need to update the pci_epc_features after the merge.
> 
> I don't think you should update pci_epc_features just to be able to test
> the inbound submapping feature.
> 
> As I said before, I think a better option would to ensure that the test is
> skipped instead of returning failure, for SoCs with too few inbound iATUs.

So we will need to add a SKIP ENOSPC case in TEST_F(pci_ep_bar, 
BAR_SUBRANGE_TEST)

Note this will be equivalent to set .subrange_mapping to false in the 
pci_epc_features. But I agree, it only pertains to the epf test driver, 
not all epf drivers. Touching pci_epc_features is not a good idea

> 
> A real EPF driver (not the test driver), that wants to run on STM32, and
> wants to use inbound submapping feature, can simply ensure that it does not
> enable all BARs (the test driver obviously enables all BARs, since it wants
> to test all BARs). That way, that EPF driver will be able to use multiple
> iATUs for a single BAR (as required by this new feature).
> 
> This works because all BARs are disabled by default. An EPF driver has to
> enable the BARs it wants to use. (E.g. nvmet-pci-epf only enables BAR0.)
> 
> 
>>
>> A more general question: I don't understand why only the STM32 is impacted.
>> It seems that all targets, even those with 6 IB iATU entries, should ensure
>> that one BAR is disabled to handle subranges.
> 
> I can't speak for every SoC, but looking at dmesg:
> rockchip-dw-pcie a40000000.pcie-ep: iATU: unroll T, 16 ob, 16 ib, align 64K, limit 8G
> 
> rk3588 has 16 inbound windows.
> 
> Probably most SoCs have more than 6 ib windows?

Yes, probably, thank you

Cheers

Christian

> 
> 
> Kind regards,
> Niklas

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Manivannan Sadhasivam]

On Tue, Mar 17, 2026 at 10:13:52AM +0100, Christian Bruel wrote:
> 
> 
> On 3/17/26 03:57, Koichiro Den wrote:
> > On Mon, Mar 16, 2026 at 05:19:26PM +0100, Niklas Cassel wrote:
> > > On Mon, Mar 16, 2026 at 11:02:25PM +0900, Koichiro Den wrote:
> > > > When the BAR subrange mapping test on DWC-based platforms fails due to
> > > > insufficient free inbound iATU regions,
> > > > pci_epf_test_bar_subrange_setup() returns an error (-ENOSPC) but does
> > > > not restore the original BAR mapping. This causes subsequent test runs
> > > > to become confusing, since the failure may leave room for the next
> > > > subrange mapping test to pass.
> > > > 
> > > > Fix this by restoring the original BAR mapping when preparation of the
> > > > subrange mapping fails, so that no side effect remains regardless of the
> > > > test success or failure.
> > > > 
> > > > Fixes: 6c5e6101423b ("PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support")
> > > > Reported-by: Christian Bruel <christian.bruel@foss.st.com>
> > > > Closes: https://lore.kernel.org/linux-pci/b2b03ebe-9482-4a13-b22f-7b44da096eed@foss.st.com/
> > > > Signed-off-by: Koichiro Den <den@valinux.co.jp>
> > > > ---
> > > >   drivers/pci/endpoint/functions/pci-epf-test.c | 6 ++++++
> > > >   1 file changed, 6 insertions(+)
> > > > 
> > > > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> > > > index 14e61ebe1f11..f44c36f5cac5 100644
> > > > --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> > > > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> > > > @@ -898,16 +898,22 @@ static void pci_epf_test_bar_subrange_setup(struct pci_epf_test *epf_test,
> > > >   	bar->submap = submap;
> > > >   	bar->num_submap = nsub;
> > > >   	ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
> > > >   	if (ret) {
> > > >   		dev_err(&epf->dev, "pci_epc_set_bar() failed: %d\n", ret);
> > > >   		bar->submap = old_submap;
> > > >   		bar->num_submap = old_nsub;
> > > > +		ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
> > > > +		if (ret)
> > > > +			dev_warn(&epf->dev,
> > > > +				 "failed to restore the original BAR mapping: %d\n",
> > > 
> > > Nit:
> > > I would use a capitalized F:
> > > "Failed to restore ..."
> > > 
> > > in order to match most other prints in this file.
> > 
> > Agree. Bjorn or Mani, please feel free to fix this up (i.e. s/failed/Failed/)
> > when applying, to avoid a respin for such a minor change.
> > 
> > > 
> > > Reviewed-by: Niklas Cassel <cassel@kernel.org>
> > 
> > Thanks again for reviewing, Niklas.
> > 
> > Christian, if possible, it would be very helpful if you could take a look or
> > test this slightly polished version and add a Tested-by or Reviewed-by.
> 
> Tested-by: Christian Bruel <christian.bruel@foss.st.com>
> 
> with the DISABLE BAR dependency
> https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=endpoint&id=33642e9e36dc084e4fc9245a266c9843bc8303b9
> 

Why is this dependency?

- Mani

-- 
மணிவண்ணன் சதாசிவம்

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Christian Bruel]

> 
> So we will need to add a SKIP ENOSPC case in TEST_F(pci_ep_bar, 
> BAR_SUBRANGE_TEST)
> 
Re-checking this, no need for ENOSPC test. The real condition would be 
EBUSY. Which can be handled nicely in a stm32 ep_map_addr helper.

Christian

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Christian Bruel]

On 3/17/26 10:59, Manivannan Sadhasivam wrote:
> On Tue, Mar 17, 2026 at 10:13:52AM +0100, Christian Bruel wrote:
>>
>>
>> On 3/17/26 03:57, Koichiro Den wrote:
>>> On Mon, Mar 16, 2026 at 05:19:26PM +0100, Niklas Cassel wrote:
>>>> On Mon, Mar 16, 2026 at 11:02:25PM +0900, Koichiro Den wrote:
>>>>> When the BAR subrange mapping test on DWC-based platforms fails due to
>>>>> insufficient free inbound iATU regions,
>>>>> pci_epf_test_bar_subrange_setup() returns an error (-ENOSPC) but does
>>>>> not restore the original BAR mapping. This causes subsequent test runs
>>>>> to become confusing, since the failure may leave room for the next
>>>>> subrange mapping test to pass.
>>>>>
>>>>> Fix this by restoring the original BAR mapping when preparation of the
>>>>> subrange mapping fails, so that no side effect remains regardless of the
>>>>> test success or failure.
>>>>>
>>>>> Fixes: 6c5e6101423b ("PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support")
>>>>> Reported-by: Christian Bruel <christian.bruel@foss.st.com>
>>>>> Closes: https://lore.kernel.org/linux-pci/b2b03ebe-9482-4a13-b22f-7b44da096eed@foss.st.com/
>>>>> Signed-off-by: Koichiro Den <den@valinux.co.jp>
>>>>> ---
>>>>>    drivers/pci/endpoint/functions/pci-epf-test.c | 6 ++++++
>>>>>    1 file changed, 6 insertions(+)
>>>>>
>>>>> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
>>>>> index 14e61ebe1f11..f44c36f5cac5 100644
>>>>> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
>>>>> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
>>>>> @@ -898,16 +898,22 @@ static void pci_epf_test_bar_subrange_setup(struct pci_epf_test *epf_test,
>>>>>    	bar->submap = submap;
>>>>>    	bar->num_submap = nsub;
>>>>>    	ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
>>>>>    	if (ret) {
>>>>>    		dev_err(&epf->dev, "pci_epc_set_bar() failed: %d\n", ret);
>>>>>    		bar->submap = old_submap;
>>>>>    		bar->num_submap = old_nsub;
>>>>> +		ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
>>>>> +		if (ret)
>>>>> +			dev_warn(&epf->dev,
>>>>> +				 "failed to restore the original BAR mapping: %d\n",
>>>>
>>>> Nit:
>>>> I would use a capitalized F:
>>>> "Failed to restore ..."
>>>>
>>>> in order to match most other prints in this file.
>>>
>>> Agree. Bjorn or Mani, please feel free to fix this up (i.e. s/failed/Failed/)
>>> when applying, to avoid a respin for such a minor change.
>>>
>>>>
>>>> Reviewed-by: Niklas Cassel <cassel@kernel.org>
>>>
>>> Thanks again for reviewing, Niklas.
>>>
>>> Christian, if possible, it would be very helpful if you could take a look or
>>> test this slightly polished version and add a Tested-by or Reviewed-by.
>>
>> Tested-by: Christian Bruel <christian.bruel@foss.st.com>
>>
>> with the DISABLE BAR dependency
>> https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=endpoint&id=33642e9e36dc084e4fc9245a266c9843bc8303b9
>>
> 
> Why is this dependency?

no not needed, sorry. will be handler in the stm32 part.

> 
> - Mani
> 

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Niklas Cassel]

On Tue, Mar 17, 2026 at 03:29:30PM +0530, Manivannan Sadhasivam wrote:
> > On 3/17/26 03:57, Koichiro Den wrote:
> > > On Mon, Mar 16, 2026 at 05:19:26PM +0100, Niklas Cassel wrote:
> > > > On Mon, Mar 16, 2026 at 11:02:25PM +0900, Koichiro Den wrote:
> > > > > When the BAR subrange mapping test on DWC-based platforms fails due to
> > > > > insufficient free inbound iATU regions,
> > > > > pci_epf_test_bar_subrange_setup() returns an error (-ENOSPC) but does
> > > > > not restore the original BAR mapping. This causes subsequent test runs
> > > > > to become confusing, since the failure may leave room for the next
> > > > > subrange mapping test to pass.
> > > > > 
> > > > > Fix this by restoring the original BAR mapping when preparation of the
> > > > > subrange mapping fails, so that no side effect remains regardless of the
> > > > > test success or failure.
> > > > > 
> > > > > Fixes: 6c5e6101423b ("PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support")
> > > > > Reported-by: Christian Bruel <christian.bruel@foss.st.com>
> > > > > Closes: https://lore.kernel.org/linux-pci/b2b03ebe-9482-4a13-b22f-7b44da096eed@foss.st.com/
> > > > > Signed-off-by: Koichiro Den <den@valinux.co.jp>
> > > > > ---
> > > > >   drivers/pci/endpoint/functions/pci-epf-test.c | 6 ++++++
> > > > >   1 file changed, 6 insertions(+)
> > > > > 
> > > > > diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> > > > > index 14e61ebe1f11..f44c36f5cac5 100644
> > > > > --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> > > > > +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> > > > > @@ -898,16 +898,22 @@ static void pci_epf_test_bar_subrange_setup(struct pci_epf_test *epf_test,
> > > > >   	bar->submap = submap;
> > > > >   	bar->num_submap = nsub;
> > > > >   	ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
> > > > >   	if (ret) {
> > > > >   		dev_err(&epf->dev, "pci_epc_set_bar() failed: %d\n", ret);
> > > > >   		bar->submap = old_submap;
> > > > >   		bar->num_submap = old_nsub;
> > > > > +		ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
> > > > > +		if (ret)
> > > > > +			dev_warn(&epf->dev,
> > > > > +				 "failed to restore the original BAR mapping: %d\n",
> > > > 
> > > > Nit:
> > > > I would use a capitalized F:
> > > > "Failed to restore ..."
> > > > 
> > > > in order to match most other prints in this file.
> > > 
> > > Agree. Bjorn or Mani, please feel free to fix this up (i.e. s/failed/Failed/)
> > > when applying, to avoid a respin for such a minor change.
> > > 
> > > > 
> > > > Reviewed-by: Niklas Cassel <cassel@kernel.org>
> > > 
> > > Thanks again for reviewing, Niklas.
> > > 
> > > Christian, if possible, it would be very helpful if you could take a look or
> > > test this slightly polished version and add a Tested-by or Reviewed-by.
> > 
> > Tested-by: Christian Bruel <christian.bruel@foss.st.com>
> > 
> > with the DISABLE BAR dependency
> > https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=endpoint&id=33642e9e36dc084e4fc9245a266c9843bc8303b9
> > 
> 
> Why is this dependency?

It is not.

I just suggested to force disable a BAR on STM32, using this patch, so that
Christian could verify that the new feature can actually work on STM32.

(Another option would have been to modify pci-epf-test to not enable all
6 BARs.)


Kind regards,
Niklas

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Niklas Cassel]

On Tue, Mar 17, 2026 at 11:01:28AM +0100, Christian Bruel wrote:
> 
> 
> > 
> > So we will need to add a SKIP ENOSPC case in TEST_F(pci_ep_bar,
> > BAR_SUBRANGE_TEST)
> > 
> Re-checking this, no need for ENOSPC test. The real condition would be
> EBUSY. Which can be handled nicely in a stm32 ep_map_addr helper.

Are you sure that it returns EBUSY and not ENOSPC?

I would have expected the error to be ENOSPC when there are no free inbound
window:
https://github.com/torvalds/linux/blob/v7.0-rc4/drivers/pci/controller/dwc/pcie-designware-ep.c#L307-L312


I think a SKIP ENOSPC case in TEST_F(pci_ep_bar, BAR_SUBRANGE_TEST) in
a better solution than modifying a STM32 specific helper.

Because the former will ensure that we skip/handle this issue on all SoCs
with few inbound windows, not only on STM32.


Kind regards,
Niklas

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Christian Bruel]

On 3/17/26 11:12, Niklas Cassel wrote:
> On Tue, Mar 17, 2026 at 11:01:28AM +0100, Christian Bruel wrote:
>>
>>
>>>
>>> So we will need to add a SKIP ENOSPC case in TEST_F(pci_ep_bar,
>>> BAR_SUBRANGE_TEST)
>>>
>> Re-checking this, no need for ENOSPC test. The real condition would be
>> EBUSY. Which can be handled nicely in a stm32 ep_map_addr helper.
> 
> Are you sure that it returns EBUSY and not ENOSPC?
> 
> I would have expected the error to be ENOSPC when there are no free inbound
> window:
> https://github.com/torvalds/linux/blob/v7.0-rc4/drivers/pci/controller/dwc/pcie-designware-ep.c#L307-L312

dw_pcie_ep_ib_atu_addr() returns ENOSPC. I was thinking to overload 
.set_bar with a stm32 helper to return EBUSY if the subrange bar is 
already reserved.

So whatever is best
  - modify TEST_F to SKIP if ENOSPC
or
  - Add a specific platform .set_bar helper to return EBUSY, already 
handled in the test.

thank you

Christian

> 
> 
> I think a SKIP ENOSPC case in TEST_F(pci_ep_bar, BAR_SUBRANGE_TEST) in
> a better solution than modifying a STM32 specific helper.
> 
> Because the former will ensure that we skip/handle this issue on all SoCs
> with few inbound windows, not only on STM32.
> 
> 
> Kind regards,
> Niklas

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Niklas Cassel]

On Tue, Mar 17, 2026 at 11:29:41AM +0100, Christian Bruel wrote:
> 
> 
> On 3/17/26 11:12, Niklas Cassel wrote:
> > On Tue, Mar 17, 2026 at 11:01:28AM +0100, Christian Bruel wrote:
> > > 
> > > 
> > > > 
> > > > So we will need to add a SKIP ENOSPC case in TEST_F(pci_ep_bar,
> > > > BAR_SUBRANGE_TEST)
> > > > 
> > > Re-checking this, no need for ENOSPC test. The real condition would be
> > > EBUSY. Which can be handled nicely in a stm32 ep_map_addr helper.
> > 
> > Are you sure that it returns EBUSY and not ENOSPC?
> > 
> > I would have expected the error to be ENOSPC when there are no free inbound
> > window:
> > https://github.com/torvalds/linux/blob/v7.0-rc4/drivers/pci/controller/dwc/pcie-designware-ep.c#L307-L312
> 
> dw_pcie_ep_ib_atu_addr() returns ENOSPC. I was thinking to overload .set_bar
> with a stm32 helper to return EBUSY if the subrange bar is already reserved.
> 
> So whatever is best
>  - modify TEST_F to SKIP if ENOSPC
> or
>  - Add a specific platform .set_bar helper to return EBUSY, already handled
> in the test.

I think "modify TEST_F to SKIP if ENOSPC",
since it will solve the problem for all platforms that have few inbound iATUs.


Kind regards,
Niklas

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Koichiro Den]

On Tue, Mar 17, 2026 at 11:46:03AM +0100, Niklas Cassel wrote:
> On Tue, Mar 17, 2026 at 11:29:41AM +0100, Christian Bruel wrote:
> > 
> > 
> > On 3/17/26 11:12, Niklas Cassel wrote:
> > > On Tue, Mar 17, 2026 at 11:01:28AM +0100, Christian Bruel wrote:
> > > > 
> > > > 
> > > > > 
> > > > > So we will need to add a SKIP ENOSPC case in TEST_F(pci_ep_bar,
> > > > > BAR_SUBRANGE_TEST)
> > > > > 
> > > > Re-checking this, no need for ENOSPC test. The real condition would be
> > > > EBUSY. Which can be handled nicely in a stm32 ep_map_addr helper.
> > > 
> > > Are you sure that it returns EBUSY and not ENOSPC?
> > > 
> > > I would have expected the error to be ENOSPC when there are no free inbound
> > > window:
> > > https://github.com/torvalds/linux/blob/v7.0-rc4/drivers/pci/controller/dwc/pcie-designware-ep.c#L307-L312
> > 
> > dw_pcie_ep_ib_atu_addr() returns ENOSPC. I was thinking to overload .set_bar
> > with a stm32 helper to return EBUSY if the subrange bar is already reserved.
> > 
> > So whatever is best
> >  - modify TEST_F to SKIP if ENOSPC
> > or
> >  - Add a specific platform .set_bar helper to return EBUSY, already handled
> > in the test.
> 
> I think "modify TEST_F to SKIP if ENOSPC",
> since it will solve the problem for all platforms that have few inbound iATUs.

That sounds like the right direction, though I think we would first need a way
to propagate -ENOSPC back to the host side, instead of just collapsing all
EP-side setup failures into STATUS_BAR_SUBRANGE_SETUP_FAIL, which
pci_endpoint_test currently maps to -EIO.

One question is whether it's always safe to treat -ENOSPC as a pure resource
limitation, rather than something that could also be triggered by other issues
(e.g. a bug).

That said, if preferred, I can prepare a patch (series) for that.

Thanks,
Koichiro

> 
> 
> Kind regards,
> Niklas

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Koichiro Den]

On Tue, Mar 17, 2026 at 10:55:31AM +0100, Christian Bruel wrote:
> 
> 
> On 3/17/26 10:24, Niklas Cassel wrote:
> > On Tue, Mar 17, 2026 at 10:13:52AM +0100, Christian Bruel wrote:
> > > 
> > > Tested-by: Christian Bruel <christian.bruel@foss.st.com>
> > > 
> > > with the DISABLE BAR dependency
> > > https://git.kernel.org/pub/scm/linux/kernel/git/pci/pci.git/commit/?h=endpoint&id=33642e9e36dc084e4fc9245a266c9843bc8303b9
> > > 
> > > I will need to update the pci_epc_features after the merge.
> > 
> > I don't think you should update pci_epc_features just to be able to test
> > the inbound submapping feature.
> > 
> > As I said before, I think a better option would to ensure that the test is
> > skipped instead of returning failure, for SoCs with too few inbound iATUs.
> 
> So we will need to add a SKIP ENOSPC case in TEST_F(pci_ep_bar,
> BAR_SUBRANGE_TEST)
> 
> Note this will be equivalent to set .subrange_mapping to false in the
> pci_epc_features. But I agree, it only pertains to the epf test driver, not
> all epf drivers. Touching pci_epc_features is not a good idea
> 
> > 
> > A real EPF driver (not the test driver), that wants to run on STM32, and
> > wants to use inbound submapping feature, can simply ensure that it does not
> > enable all BARs (the test driver obviously enables all BARs, since it wants
> > to test all BARs). That way, that EPF driver will be able to use multiple
> > iATUs for a single BAR (as required by this new feature).
> > 
> > This works because all BARs are disabled by default. An EPF driver has to
> > enable the BARs it wants to use. (E.g. nvmet-pci-epf only enables BAR0.)
> > 
> > 
> > > 
> > > A more general question: I don't understand why only the STM32 is impacted.
> > > It seems that all targets, even those with 6 IB iATU entries, should ensure
> > > that one BAR is disabled to handle subranges.
> > 
> > I can't speak for every SoC, but looking at dmesg:
> > rockchip-dw-pcie a40000000.pcie-ep: iATU: unroll T, 16 ob, 16 ib, align 64K, limit 8G
> > 
> > rk3588 has 16 inbound windows.
> > 
> > Probably most SoCs have more than 6 ib windows?
> 
> Yes, probably, thank you

Just for reference, on R-Car S4 Spider (r8a779f0), the number of IB iATU regions
is 16:
pcie-rcar-gen4 e65d0000.pcie-ep: iATU: unroll T, 16 ob, 16 ib, align 4K, limit 4G

I'm not sure how many IB iATU regions are typical for DWC-based platforms,
within the valid CX_ATU_NUM_INBOUND_REGIONS [0, 256] range.

Best regards,
Koichiro

> 
> Cheers
> 
> Christian
> 
> > 
> > 
> > Kind regards,
> > Niklas
> 

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Bjorn Helgaas]

On Mon, Mar 16, 2026 at 11:02:25PM +0900, Koichiro Den wrote:
> When the BAR subrange mapping test on DWC-based platforms fails due to
> insufficient free inbound iATU regions,
> pci_epf_test_bar_subrange_setup() returns an error (-ENOSPC) but does
> not restore the original BAR mapping. This causes subsequent test runs
> to become confusing, since the failure may leave room for the next
> subrange mapping test to pass.
> 
> Fix this by restoring the original BAR mapping when preparation of the
> subrange mapping fails, so that no side effect remains regardless of the
> test success or failure.
> 
> Fixes: 6c5e6101423b ("PCI: endpoint: pci-epf-test: Add BAR subrange mapping test support")
> Reported-by: Christian Bruel <christian.bruel@foss.st.com>
> Closes: https://lore.kernel.org/linux-pci/b2b03ebe-9482-4a13-b22f-7b44da096eed@foss.st.com/
> Signed-off-by: Koichiro Den <den@valinux.co.jp>

Applied to pci/for-linus for v7.0, thanks.

> ---
>  drivers/pci/endpoint/functions/pci-epf-test.c | 6 ++++++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/pci/endpoint/functions/pci-epf-test.c b/drivers/pci/endpoint/functions/pci-epf-test.c
> index 14e61ebe1f11..f44c36f5cac5 100644
> --- a/drivers/pci/endpoint/functions/pci-epf-test.c
> +++ b/drivers/pci/endpoint/functions/pci-epf-test.c
> @@ -898,16 +898,22 @@ static void pci_epf_test_bar_subrange_setup(struct pci_epf_test *epf_test,
>  	bar->submap = submap;
>  	bar->num_submap = nsub;
>  
>  	ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
>  	if (ret) {
>  		dev_err(&epf->dev, "pci_epc_set_bar() failed: %d\n", ret);
>  		bar->submap = old_submap;
>  		bar->num_submap = old_nsub;
> +		ret = pci_epc_set_bar(epc, epf->func_no, epf->vfunc_no, bar);
> +		if (ret)
> +			dev_warn(&epf->dev,
> +				 "failed to restore the original BAR mapping: %d\n",
> +				 ret);
> +
>  		kfree(submap);
>  		goto err;
>  	}
>  	kfree(old_submap);
>  
>  	/*
>  	 * Fill deterministic signatures into the physical regions that
>  	 * each BAR subrange maps to. RC verifies these to ensure the
> -- 
> 2.51.0
> 

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Christian Bruel]

On 3/17/26 16:14, Koichiro Den wrote:
> On Tue, Mar 17, 2026 at 11:46:03AM +0100, Niklas Cassel wrote:
>> On Tue, Mar 17, 2026 at 11:29:41AM +0100, Christian Bruel wrote:
>>>
>>>
>>> On 3/17/26 11:12, Niklas Cassel wrote:
>>>> On Tue, Mar 17, 2026 at 11:01:28AM +0100, Christian Bruel wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> So we will need to add a SKIP ENOSPC case in TEST_F(pci_ep_bar,
>>>>>> BAR_SUBRANGE_TEST)
>>>>>>
>>>>> Re-checking this, no need for ENOSPC test. The real condition would be
>>>>> EBUSY. Which can be handled nicely in a stm32 ep_map_addr helper.
>>>>
>>>> Are you sure that it returns EBUSY and not ENOSPC?
>>>>
>>>> I would have expected the error to be ENOSPC when there are no free inbound
>>>> window:
>>>> https://github.com/torvalds/linux/blob/v7.0-rc4/drivers/pci/controller/dwc/pcie-designware-ep.c#L307-L312
>>>
>>> dw_pcie_ep_ib_atu_addr() returns ENOSPC. I was thinking to overload .set_bar
>>> with a stm32 helper to return EBUSY if the subrange bar is already reserved.
>>>
>>> So whatever is best
>>>   - modify TEST_F to SKIP if ENOSPC
>>> or
>>>   - Add a specific platform .set_bar helper to return EBUSY, already handled
>>> in the test.
>>
>> I think "modify TEST_F to SKIP if ENOSPC",
>> since it will solve the problem for all platforms that have few inbound iATUs.
> 
> That sounds like the right direction, though I think we would first need a way
> to propagate -ENOSPC back to the host side, instead of just collapsing all
> EP-side setup failures into STATUS_BAR_SUBRANGE_SETUP_FAIL, which
> pci_endpoint_test currently maps to -EIO.
> 

I think the epf test function can return several bits in the status 
mask, in addition of STATUS_BAR_SUBRANGE_SETUP_FAIL. e.g 
STATUS_BAR_SUBRANGE_SETUP_SKIP, or STATUS_BAR_SUBRANGE_SETUP_NOSPC.
I prefer the former since we want to pass the cause, not the action and 
let the skip decision to the host

> One question is whether it's always safe to treat -ENOSPC as a pure resource
> limitation, rather than something that could also be triggered by other issues
> (e.g. a bug).

Looking at the execution path, it seems that the only ENOSPC return 
point for the DWC controller is from dw_pcie_ep_ib_atu_addr() during 
allocation in the ib_window_map. If there is a bug in this part I 
expected it would be caught by the BAR_TEST

> 
> That said, if preferred, I can prepare a patch (series) for that.
> 
> Thanks,
> Koichiro
> 

Oh, sorry, I'm already testing the patch.

thank you,

Christian

>>
>>
>> Kind regards,
>> Niklas

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Christian Bruel]

>>>
>>> I think "modify TEST_F to SKIP if ENOSPC",
>>> since it will solve the problem for all platforms that have few 
>>> inbound iATUs.
>>
>> That sounds like the right direction, though I think we would first 
>> need a way
>> to propagate -ENOSPC back to the host side, instead of just collapsing 
>> all
>> EP-side setup failures into STATUS_BAR_SUBRANGE_SETUP_FAIL, which
>> pci_endpoint_test currently maps to -EIO.
>>
> 
> I think the epf test function can return several bits in the status 
> mask, in addition of STATUS_BAR_SUBRANGE_SETUP_FAIL. e.g 
> STATUS_BAR_SUBRANGE_SETUP_SKIP, or STATUS_BAR_SUBRANGE_SETUP_NOSPC.
> I prefer the former since we want to pass the cause, not the action and 
> let the skip decision to the host
> 

Rethinking this, having a pci_epc_feature to limit the maximum number of 
simultaneously allocatable BARs might be a useful addition to the EPC 
driver. The epc driver would need to keep track of the allocated BARs 
and check it before calling set_bar() for skipping or not.

Do you think this added (minor) complexity is worth it compared to 
simply returning ENOSPC in the status?

thank you,

Christian

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Niklas Cassel]

On Wed, Mar 18, 2026 at 09:35:10AM +0100, Christian Bruel wrote:
> 
> 
> > > > 
> > > > I think "modify TEST_F to SKIP if ENOSPC",
> > > > since it will solve the problem for all platforms that have few
> > > > inbound iATUs.
> > > 
> > > That sounds like the right direction, though I think we would first
> > > need a way
> > > to propagate -ENOSPC back to the host side, instead of just
> > > collapsing all
> > > EP-side setup failures into STATUS_BAR_SUBRANGE_SETUP_FAIL, which
> > > pci_endpoint_test currently maps to -EIO.
> > > 
> > 
> > I think the epf test function can return several bits in the status
> > mask, in addition of STATUS_BAR_SUBRANGE_SETUP_FAIL. e.g
> > STATUS_BAR_SUBRANGE_SETUP_SKIP, or STATUS_BAR_SUBRANGE_SETUP_NOSPC.
> > I prefer the former since we want to pass the cause, not the action and
> > let the skip decision to the host
> > 
> 
> Rethinking this, having a pci_epc_feature to limit the maximum number of
> simultaneously allocatable BARs might be a useful addition to the EPC
> driver. The epc driver would need to keep track of the allocated BARs and
> check it before calling set_bar() for skipping or not.

The limitation is not allocatable BARs, it is the number of inbound/outbound
iATUs/windows.

(E.g. with inbound subrange mapping one BAR could be split in 3, and require
three different iATUs, but another BAR is not split, so just requires one
iATU.)


Right now, a big limitation in the PCI endpoint framework, is that there is
currently no API to see how many inbound/outbound iATUs that are currently
in use.

So the only thing you can do is to call mem_map() and see if you get an
error. This is a bit wasteful, as in some cases, you could probably
skip/wait with a lot of processing, if you knew that there was no free
iATUs windows available.

However, I think such API would be most useful for outbound mapping.
I.e. endpoint to host transfers. Think of e.g. nvmet-pci-epf, you can
easily have a queue depth of 128, so 128 outbound mappings at the same
time.


For inbound mappings, you can only ever map BARs, so in comparison
to outbound mappings, inbound mappings are very limited.
6 BARs, and sure, with inbound subrange mapping you can have a few
windows per BAR, but this is usually something the EPF driver does a
.bind() time, even before any transfers have taken place.

If set_bar() fails with -ENOSPC or something to indicate no free window,
I would imagine that that that is good enough for most EPF drivers.


> 
> Do you think this added (minor) complexity is worth it compared to simply
> returning ENOSPC in the status?

TL;DL: I think a number of free windows API would be a good addition,
but for outbound windows.

For inbound windows, it seems a bit unnecessary IMO.


Kind regards,
Niklas

Re: [PATCH] PCI: endpoint: pci-epf-test: Roll back BAR mapping when subrange setup fails

[Christian Bruel]

On 3/18/26 09:58, Niklas Cassel wrote:
> On Wed, Mar 18, 2026 at 09:35:10AM +0100, Christian Bruel wrote:
>>
>>
>>>>>
>>>>> I think "modify TEST_F to SKIP if ENOSPC",
>>>>> since it will solve the problem for all platforms that have few
>>>>> inbound iATUs.
>>>>
>>>> That sounds like the right direction, though I think we would first
>>>> need a way
>>>> to propagate -ENOSPC back to the host side, instead of just
>>>> collapsing all
>>>> EP-side setup failures into STATUS_BAR_SUBRANGE_SETUP_FAIL, which
>>>> pci_endpoint_test currently maps to -EIO.
>>>>
>>>
>>> I think the epf test function can return several bits in the status
>>> mask, in addition of STATUS_BAR_SUBRANGE_SETUP_FAIL. e.g
>>> STATUS_BAR_SUBRANGE_SETUP_SKIP, or STATUS_BAR_SUBRANGE_SETUP_NOSPC.
>>> I prefer the former since we want to pass the cause, not the action and
>>> let the skip decision to the host
>>>
>>
>> Rethinking this, having a pci_epc_feature to limit the maximum number of
>> simultaneously allocatable BARs might be a useful addition to the EPC
>> driver. The epc driver would need to keep track of the allocated BARs and
>> check it before calling set_bar() for skipping or not.
> 
> The limitation is not allocatable BARs, it is the number of inbound/outbound
> iATUs/windows.
> 
> (E.g. with inbound subrange mapping one BAR could be split in 3, and require
> three different iATUs, but another BAR is not split, so just requires one
> iATU.)
> 
> 
> Right now, a big limitation in the PCI endpoint framework, is that there is
> currently no API to see how many inbound/outbound iATUs that are currently
> in use.
> 
> So the only thing you can do is to call mem_map() and see if you get an
> error. This is a bit wasteful, as in some cases, you could probably
> skip/wait with a lot of processing, if you knew that there was no free
> iATUs windows available.


Ah yes, I didn't consider mem_map(). For the record, the idea was to 
expose num_ib_windows in the epc_features to cap the number of BARs. 
subranges would consume multiple entries.

But we need to track counts for that, and I'm afraid this is a fragile 
abstraction from the iATU

Today, with the stm32mp2 iATU limitation, the epf test fails not 
gracefully : (unless we disable 2 bars)

[   13.453253] stm32-ep-pcie 48400000.pcie-ep: iATU: unroll T, 4 ob, 4 
ib, align 64K, limit 4G
[   13.456074] pci_epf_test pci_epf_test.0: Failed to get private DMA rx 
channel. Falling back to generic one
[   13.466149] stm32-ep-pcie 48400000.pcie-ep: No free inbound window
[   13.472061] pci_epf_test pci_epf_test.0: Failed to set BAR4
[   13.477626] stm32-ep-pcie 48400000.pcie-ep: No free inbound window
[   13.483981] pci_epf_test pci_epf_test.0: Failed to set BAR5

This could be solved by monitoring the iATU free spaces based on the 
feature, but that's another subject.

For now and the subrange skip, reporting ENOSPC is good enough indeed

Thank you for your advice,

Christian

> However, I think such API would be most useful for outbound mapping.
> I.e. endpoint to host transfers. Think of e.g. nvmet-pci-epf, you can
> easily have a queue depth of 128, so 128 outbound mappings at the same
> time.
>
> 
> For inbound mappings, you can only ever map BARs, so in comparison
> to outbound mappings, inbound mappings are very limited.
> 6 BARs, and sure, with inbound subrange mapping you can have a few
> windows per BAR, but this is usually something the EPF driver does a
> .bind() time, even before any transfers have taken place.
> 
> If set_bar() fails with -ENOSPC or something to indicate no free window,
> I would imagine that that that is good enough for most EPF drivers.
> 
> 
>>
>> Do you think this added (minor) complexity is worth it compared to simply
>> returning ENOSPC in the status?
> 
> TL;DL: I think a number of free windows API would be a good addition,
> but for outbound windows.
> 
> For inbound windows, it seems a bit unnecessary IMO.
> 
> 
> Kind regards,
> Niklas