All of lore.kernel.org
 help / color / mirror / Atom feed
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 12:04:27 +0100	[thread overview]
Message-ID: <aYsQu9lQi4IzfBiP@ryzen> (raw)
In-Reply-To: <c8e42e96-212f-451d-802b-7166611f6fcd@nvidia.com>

On Tue, Feb 10, 2026 at 04:09:05PM +0530, Manikanta Maddireddy wrote:
> > 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.)
> > 
> pci-epc.h defined
> 
>  * @BAR_RESERVED: The BAR should not be touched by an EPF driver.
> 
> I believe you are interpreting this as unused BAR?
> 
> In Tegra PCIe, BAR2 and BAR4 are backed by PCIe HW memory which
> 
> shouldn't be touched by EPF, but should be kept enabled.
> 
> This support is not available. I suggested to add BAR_DISABLED
> 
> for unused and use BAR_RESERVED for bars like above.

I understand what you want. You want to have a BAR_RESERVED and a
BAR_DISABLED.

Sounds like a nice feature. Feel free to add that.


But like I mentioned in my reply, for all existing drivers, except for
pci-keystone.c, in practice BAR_RESERVED actually means BAR_DISABLED.
(Since all drivers except for pci-keystone.c call reset_bar() in init(),
and pci-epf-test will not enable BARs marked as BAR_RESERVED).

So if you add a BAR_DISABLED, make sure that you convert all existing
uses of BAR_RESERVED (except for pci-keystone.c) to BAR_DISABLED.

pci-keystone.c and pcie-tegra194.c can then be the only drivers that
have BARs marked as BAR_RESERVED (all other drivers would use BAR_DISABLED).

Please just make sure that you don't regress the amount of currently passing
pci_endpoint_test test cases that are passing for pcie-tegra194.c.
(Which would be the case if you revert the patch in $subject without first
adding your proposed new BAR_DISABLED, such that we can have a distinction
between BAR_DISABLED and BAR_RESERVED.)


Kind regards,
Niklas

  parent reply	other threads:[~2026-02-10 11:04 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
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 [this message]
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=aYsQu9lQi4IzfBiP@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.