public inbox for linux-tegra@vger.kernel.org
 help / color / mirror / Atom feed
From: Niklas Cassel <cassel@kernel.org>
To: "Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Manivannan Sadhasivam" <mani@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	"Thierry Reding" <thierry.reding@gmail.com>,
	"Jonathan Hunter" <jonathanh@nvidia.com>,
	"Vidya Sagar" <vidyas@nvidia.com>
Cc: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>,
	stable@vger.kernel.org, Thierry Reding <treding@nvidia.com>,
	Niklas Cassel <cassel@kernel.org>,
	linux-pci@vger.kernel.org, linux-tegra@vger.kernel.org
Subject: [PATCH v2 3/3] PCI: tegra194: Handle errors in BPMP response
Date: Mon, 22 Sep 2025 16:08:26 +0200	[thread overview]
Message-ID: <20250922140822.519796-8-cassel@kernel.org> (raw)
In-Reply-To: <20250922140822.519796-5-cassel@kernel.org>

From: Vidya Sagar <vidyas@nvidia.com>

The return value from tegra_bpmp_transfer() indicates the success or
failure of the IPC transaction with BPMP. If the transaction
succeeded, we also need to check the actual command's result code.

If we don't have error handling for tegra_bpmp_transfer(), we will
set the pcie->ep_state to EP_STATE_ENABLED (even though the
tegra_bpmp_transfer() command failed). Thus, the pcie->ep_state will
get out of sync with reality, and any further PERST# assert + deassert
will be a no-op (will not trigger the hardware initialization sequence).

This is because pex_ep_event_pex_rst_deassert() checks the current
pcie->ep_state, and does nothing if the current state is already
EP_STATE_ENABLED.

Thus, it is important to have error handling for tegra_bpmp_transfer(),
such that the pcie->ep_state can not get out of sync with reality, so
that we will try to initialize the hardware not only during the first
PERST# assert + deassert, but also during any succeeding PERST# assert +
deassert.

One example where this fix is needed is when using a rock5b as host.
During the initial PERST# assert + deassert (triggered by the bootloader
on the rock5b) pex_ep_event_pex_rst_deassert() will get called, but for
some unknown reason, the tegra_bpmp_transfer() call to initialize the PHY
fails. Once Linux has been loaded on the rock5b, the PCIe driver will once
again assert + deassert PERST#. However, without tegra_bpmp_transfer()
error handling, this second PERST# assert + deassert will not trigger the
hardware initialization sequence.

With tegra_bpmp_transfer() error handling, the second PERST# assert +
deassert will once again trigger the hardware to be initialized and this
time the tegra_bpmp_transfer() succeeds.

Cc: stable@vger.kernel.org
Fixes: c57247f940e8 ("PCI: tegra: Add support for PCIe endpoint mode in Tegra194")
Signed-off-by: Vidya Sagar <vidyas@nvidia.com>
[cassel: improve commit log]
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Signed-off-by: Niklas Cassel <cassel@kernel.org>
---
 drivers/pci/controller/dwc/pcie-tegra194.c | 18 ++++++++++++++++--
 1 file changed, 16 insertions(+), 2 deletions(-)

diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
index 7eb48cc13648e..c4265b3f72048 100644
--- a/drivers/pci/controller/dwc/pcie-tegra194.c
+++ b/drivers/pci/controller/dwc/pcie-tegra194.c
@@ -1223,6 +1223,7 @@ static int tegra_pcie_bpmp_set_ctrl_state(struct tegra_pcie_dw *pcie,
 	struct mrq_uphy_response resp;
 	struct tegra_bpmp_message msg;
 	struct mrq_uphy_request req;
+	int err;
 
 	/*
 	 * Controller-5 doesn't need to have its state set by BPMP-FW in
@@ -1245,7 +1246,13 @@ static int tegra_pcie_bpmp_set_ctrl_state(struct tegra_pcie_dw *pcie,
 	msg.rx.data = &resp;
 	msg.rx.size = sizeof(resp);
 
-	return tegra_bpmp_transfer(pcie->bpmp, &msg);
+	err = tegra_bpmp_transfer(pcie->bpmp, &msg);
+	if (err)
+		return err;
+	if (msg.rx.ret)
+		return -EINVAL;
+
+	return 0;
 }
 
 static int tegra_pcie_bpmp_set_pll_state(struct tegra_pcie_dw *pcie,
@@ -1254,6 +1261,7 @@ static int tegra_pcie_bpmp_set_pll_state(struct tegra_pcie_dw *pcie,
 	struct mrq_uphy_response resp;
 	struct tegra_bpmp_message msg;
 	struct mrq_uphy_request req;
+	int err;
 
 	memset(&req, 0, sizeof(req));
 	memset(&resp, 0, sizeof(resp));
@@ -1273,7 +1281,13 @@ static int tegra_pcie_bpmp_set_pll_state(struct tegra_pcie_dw *pcie,
 	msg.rx.data = &resp;
 	msg.rx.size = sizeof(resp);
 
-	return tegra_bpmp_transfer(pcie->bpmp, &msg);
+	err = tegra_bpmp_transfer(pcie->bpmp, &msg);
+	if (err)
+		return err;
+	if (msg.rx.ret)
+		return -EINVAL;
+
+	return 0;
 }
 
 static void tegra_pcie_downstream_dev_to_D0(struct tegra_pcie_dw *pcie)
-- 
2.51.0


  parent reply	other threads:[~2025-09-22 14:09 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
2026-02-08 18:21   ` Manikanta Maddireddy
2025-09-22 14:08 ` Niklas Cassel [this message]
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=20250922140822.519796-8-cassel@kernel.org \
    --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=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox