From: Niklas Cassel <cassel@kernel.org>
To: Manikanta Maddireddy <mmaddireddy@nvidia.com>
Cc: "Manivannan Sadhasivam" <mani@kernel.org>,
"Vidya Sagar" <vidyas@nvidia.com>,
"Shin'ichiro Kawasaki" <shinichiro.kawasaki@wdc.com>,
stable@vger.kernel.org, "Thierry Reding" <treding@nvidia.com>,
linux-pci@vger.kernel.org, linux-tegra@vger.kernel.org,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Thierry Reding" <thierry.reding@gmail.com>,
"Jonathan Hunter" <jonathanh@nvidia.com>,
"Rob Herring" <robh@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>
Subject: Re: [PATCH v2 2/3] PCI: tegra194: Reset BARs when running in PCIe endpoint mode
Date: Tue, 10 Feb 2026 11:06:04 +0100 [thread overview]
Message-ID: <aYsDDOZA18BBeOsd@ryzen> (raw)
In-Reply-To: <94458c39-587b-4bb4-a410-e921e5d99f10@nvidia.com>
Hello Manikanta,
On Tue, Feb 10, 2026 at 09:40:44AM +0530, Manikanta Maddireddy wrote:
> > On Sun, Feb 08, 2026 at 11:41:42PM +0530, Manikanta Maddireddy wrote:
> > > Hi Niklas,
> > >
> > > Tegra PCIe exposes only DMA register over BAR4, not iATU.
Here you claim that DMA registers are exposed in BAR4.
> Hi Niklas,
>
> In Tegra234 PCIe, BAR1 is MSI-X table and BAR2 is DMA registers backed
> by PCIe HW RAM and registers.
Here you claim that DMA registers are exposed in BAR2.
Which one is it?
> EPF driver shouldn't allocate memory for
> these two BARs. This is the reason for marking them as reserved in
> Tegra PCIe driver. DMA registers are exposed over BAR2 to allow
> PCI client driver in host to transfer data from host to endpoint
> using endpoint remote DMA read functionality. BAR test fails on this
> because not all register bits are writable. Consider NVMe example
> which has RO capability bits at the start of the BAR, it is not correct
> to add BAR test on these bits.
Have you tried running
tools/testing/selftests/pci_endpoint/pci_endpoint_test
?
pci_endpoint_test will run BAR tests against all BARs that are enabled by
default, regardless of the BAR being marked as RESERVED or not, see:
https://github.com/torvalds/linux/blob/v6.19/drivers/misc/pci_endpoint_test.c#L1052-L1061
In the case of nvidia,tegra234-pcie-ep, before my commit 42f9c66a6d0c
("PCI: tegra194: Reset BARs when running in PCIe endpoint mode"):
pcie-tegra194.c marked all BARs except BAR0 as reserved.
pci_endpoint_test would run tests against BAR0, BAR2, BAR3, BAR4, BAR5
(it would not run against BAR1, because BAR0 is marked as "only_64bit").
After my commit 42f9c66a6d0c ("PCI: tegra194: Reset BARs when running in
PCIe endpoint mode"):
pcie-tegra194.c still marks all BARs except BAR0 as reserved (I did not
change this).
pci_endpoint_test would run tests only against BAR0.
I.e. the only BAR that is not marked as reserved.
>
> I think following fixes are required to address this issue,
Could you please define "this issue", because right now I honestly don't
see the issue.
To me it seems like you want pci_endpoint_test to run against BARs that are
marked as reserved (I assume that Vidya marked them as reserved for a good
reason, most likely because all of them map to MMIO registers) and thus you
want multiple test cases in pci_endpoint_test to fail instead of being skipped?
> 1. BAR test in pci_endpoint_test should skip MSI-X table.
> 2. BAR test in pci_endpoint_test should provide option to
> skip this test on known reserved BARs, maybe we can use
> pci_endpoint_test_data for this.
pci_endpoint_test already skips disabled BARs by default.
They way it works is that you disable all BARs in you EPC driver's init()
callback (i.e. what my patch does), pci-epf-test will then allocate backing
memory + enable all BARs that are not marked as RESERVED.
> 3. EPC driver should provide BAR_DISABLED enum to disable
> unused BARs.
BAR_RESERVED already means disabled, it just assumes that an EPC driver
disables all BARs by default, which is the case for:
pci-dra7xx.c, pci-imx6.c, pci-layerscape-ep.c, pcie-artpec6.c,
pcie-designware-plat.c, pcie-dw-rockchip.c, pcie-qcom-ep.c, pcie-rcar-gen4.c,
pcie-stm32-ep.c, pcie-uniphier-ep.c.
(All drivers which disables all BARs by default in the init() callback using
dw_pcie_ep_reset_bar(). pci-epf-test will later enable all BARs that are not
marked as BAR_RESERVED.)
That leaves: pcie-keembay.c, pci-keystone.c, pcie-tegra194.c (before my patch).
For pcie-keembay.c, this is not a problem, because BAR0, BAR2, BAR4 are marked
as only_64bit, so pci-epf-test configure these BARs as 64-bit BARs, and thus
BAR1, BAR3, and BAR5 will get disabled implicitly.
For pci-keystone.c, this is the only driver that is a bit weird, it marks
BAR0 and BAR1 as reserved, but does not disable them in the init() callback.
It seems force set BAR0 as a 32-bit BAR in the init() callback.
Thus, for all drivers except for pci-keystone.c, BAR_RESERVED does mean
BAR_DISABLED. Feel free to send a patch that renames BAR_RESERVED to
BAR_DISABLED.
If you send such a patch, perhaps you also want to modify the PCI endpoint
core to call reset_bar() for all BARs marked as BAR_RESERVED/BAR_DISABLED,
instead of each EPC driver doing so in the init() callback. I think the main
reason why this is not done already is that thare is no reset_bar() op in
struct pci_epc_ops epc_ops, there is only clear_bar() which clears an BAR
enabled by an EPF driver. (So you would most likely also need to add a
.disable_bar() op in struct pci_epc_ops epc_ops.)
> 4. Tegra PCIe driver should disable only BAR_DISABLED bars and
> leave BAR_RESERVED untouched.
> 5. Return NO_BAR for both BAR_DISABLED and BAR_RESERVED in
> pci_epc_get_next_free_bar()
A BAR marked as BAR_RESERVED will never be returned by
pci_epc_get_next_free_bar(), so this is the case already.
Kind regards,
Niklas
next prev parent reply other threads:[~2026-02-10 10:06 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-22 14:08 [PATCH v2 0/3] tegra194 PCI endpoint fixes Niklas Cassel
2025-09-22 14:08 ` [PATCH v2 1/3] PCI: tegra194: Fix broken tegra_pcie_ep_raise_msi_irq() Niklas Cassel
2025-09-24 15:54 ` Manivannan Sadhasivam
2025-09-24 16:28 ` Manivannan Sadhasivam
2025-09-25 14:52 ` Niklas Cassel
2025-09-22 14:08 ` [PATCH v2 2/3] PCI: tegra194: Reset BARs when running in PCIe endpoint mode Niklas Cassel
2026-02-08 18:11 ` Manikanta Maddireddy
2026-02-09 18:27 ` Niklas Cassel
2026-02-10 4:10 ` Manikanta Maddireddy
2026-02-10 10:06 ` Niklas Cassel [this message]
2026-02-10 10:39 ` Niklas Cassel
2026-02-12 12:10 ` Aksh Garg
2026-02-12 12:20 ` Niklas Cassel
2026-02-12 13:46 ` Aksh Garg
[not found] ` <c8e42e96-212f-451d-802b-7166611f6fcd@nvidia.com>
2026-02-10 11:04 ` Niklas Cassel
2026-02-08 18:21 ` Manikanta Maddireddy
2025-09-22 14:08 ` [PATCH v2 3/3] PCI: tegra194: Handle errors in BPMP response Niklas Cassel
2025-09-24 16:27 ` [PATCH v2 0/3] tegra194 PCI endpoint fixes Manivannan Sadhasivam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aYsDDOZA18BBeOsd@ryzen \
--to=cassel@kernel.org \
--cc=bhelgaas@google.com \
--cc=jonathanh@nvidia.com \
--cc=kwilczynski@kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=mmaddireddy@nvidia.com \
--cc=robh@kernel.org \
--cc=shinichiro.kawasaki@wdc.com \
--cc=stable@vger.kernel.org \
--cc=thierry.reding@gmail.com \
--cc=treding@nvidia.com \
--cc=vidyas@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.