Re: [PATCH v2 2/3] PCI: tegra194: Reset BARs when running in PCIe endpoint mode

[Niklas Cassel <cassel@kernel.org>]

On Thu, Feb 12, 2026 at 05:40:59PM +0530, Aksh Garg wrote:
> > since you have a @ti.com email, perhaps you can explain how pci-keystone.c
> > can pass all the pci-epf-test test cases, considering that this is the only
> > driver that has BARs (BAR0 and BAR1) marked as BAR_RESERVED but do not also
> > disable the BARs (using dw_pcie_ep_reset_bar()) in the init() callback.
> > 
> > Or, perhaps the simple answer is that pci-keystone.c does not pass all
> > pci-epf-test test cases?
> 
> Hi Niklas,
> 
> I just joined the organization and have no context on why the
> pci-keystone.c have BAR0 and BAR1 as reserved, without disabling the
> bars using dw_pcie_ep_reset_bar() in the .init() callback. Because the
> AM65 do not use any BARs for any purpose like Tegra194 does (ATU
> registers or eDMA registers exposed in BAR4 for example), there would
> be no issue if the BAR0 and BAR1 are overwritten.
> 
> This was introduced in the driver the time the EP support was added to
> the driver by Kishon in commit 23284ad677a9 ("PCI: keystone: Add support
> for PCIe EP in AM654x Platforms"), where no context is provided in the
> comments or commit message why the BAR0/1 are marked as reserved in the
> features. Perhaps Kishon can provide a better insight over this.

It is extra confusing, since the older driver from TI:
pci-dra7xx.c does have the dw_pcie_ep_reset_bar() calls in init()
(git blame shows added by Kishon), so it is a bit surprising that
the newer driver (pci-keystone.c) does not.

(And like I explained, currently all DWC drivers except keystone and
pcie-keembay.c do have the dw_pcie_ep_reset_bar() calls in init().)


Kind regards,
Niklas