Linux PCI subsystem development
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Manikanta Maddireddy" <mmaddireddy@nvidia.com>
Cc: linux-pci@vger.kernel.org
Subject: Re: [PATCH v8 13/14] PCI: tegra194: Disable L1.2 capability of Tegra234 EP
Date: Thu, 13 Aug 2026 23:40:00 +0000	[thread overview]
Message-ID: <20260813234001.3AB341F000E9@smtp.kernel.org> (raw)
In-Reply-To: <20260324190755.1094879-14-mmaddireddy@nvidia.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Endpoint hardware bug workaround is incorrectly conditionalized on CONFIG_PCIEASPM.
--

--- Patch [13]: [PATCH v8 13/14] PCI: tegra194: Disable L1.2 capability of Tegra234 EP ---
commit 565b1a8d658f7e3ba31d5fa1ddf41455dcfe18ed
Author: Vidya Sagar <vidyas@nvidia.com>

    PCI: tegra194: Disable L1.2 capability of Tegra234 EP
    
    When Tegra234 is operating in the Endpoint mode with L1.2 enabled, PCIe
    link goes down during L1.2 exit. This is because Tegra234 is powering up
    UPHY PLL immediately without making sure that the REFCLK is stable.
    This is causing UPHY PLL to not lock to the correct frequency and leading
    to link going down. There is no hardware fix for this, hence do not
    advertise the L1.2 capability in the Endpoint mode.

> diff --git a/drivers/pci/controller/dwc/pcie-tegra194.c b/drivers/pci/controller/dwc/pcie-tegra194.c
> index 47df4c6b5fe0f..b159836b7e9a0 100644
> --- a/drivers/pci/controller/dwc/pcie-tegra194.c
> +++ b/drivers/pci/controller/dwc/pcie-tegra194.c

[ ... ]

> @@ -679,6 +680,22 @@ static void init_host_aspm(struct tegra_pcie_dw *pcie)
>  	if (pcie->supports_clkreq)
>  		pci->l1ss_support = true;
>  
> +	/*
> +	 * Disable L1.2 capability advertisement for Tegra234 Endpoint mode.
> +	 * Tegra234 has a hardware bug where during L1.2 exit, the UPHY PLL is
> +	 * powered up immediately without waiting for REFCLK to stabilize. This
> +	 * causes the PLL to fail to lock to the correct frequency, resulting in
> +	 * PCIe link loss. Since there is no hardware fix available, we prevent
> +	 * the Endpoint from advertising L1.2 support by clearing the L1.2 bits
> +	 * in the L1 PM Substates Capabilities register. This ensures the host
> +	 * will not attempt to enter L1.2 state with this Endpoint.
> +	 */
> +	if (pcie->of_data->disable_l1_2 && pcie->of_data->mode == DW_PCIE_EP_TYPE) {
> +		val = dw_pcie_readl_dbi(pci, l1ss + PCI_L1SS_CAP);
> +		val &= ~(PCI_L1SS_CAP_PCIPM_L1_2 | PCI_L1SS_CAP_ASPM_L1_2);
> +		dw_pcie_writel_dbi(pci, l1ss + PCI_L1SS_CAP, val);
> +	}

[Severity: High]
Does this conditionally compile out the endpoint hardware bug workaround if
CONFIG_PCIEASPM is disabled?

Looking at drivers/pci/controller/dwc/pcie-tegra194.c, init_host_aspm() is
guarded by a configuration check:

#if defined(CONFIG_PCIEASPM)
static void init_host_aspm(struct tegra_pcie_dw *pcie)
{
    ...
}
#else
static inline void init_host_aspm(struct tegra_pcie_dw *pcie) { return; }
#endif

Since ASPM configuration on the root complex (host) can be entirely
independent of the endpoint's kernel configuration, would this allow the host
to still enable L1.2 based on the endpoint's hardware advertisement if the
endpoint kernel is built without CONFIG_PCIEASPM?

> +
>  	/* Program L0s and L1 entrance latencies */
>  	val = dw_pcie_readl_dbi(pci, PCIE_PORT_AFR);
>  	val &= ~PORT_AFR_L0S_ENTRANCE_LAT_MASK;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260324190755.1094879-1-mmaddireddy@nvidia.com?part=13

  reply	other threads:[~2026-08-13 23:40 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-03-24 19:07 [PATCH v8 00/14] Fixes to pcie-tegra194 driver Manikanta Maddireddy
2026-03-24 19:07 ` [PATCH v8 01/14] PCI: tegra194: Fix polling delay for L2 state Manikanta Maddireddy
2026-03-24 19:07 ` [PATCH v8 02/14] PCI: tegra194: Increase LTSSM poll time on surprise down Manikanta Maddireddy
2026-03-24 19:07 ` [PATCH v8 03/14] PCI: tegra194: Disable LTSSM after transition to detect " Manikanta Maddireddy
2026-03-24 19:07 ` [PATCH v8 04/14] PCI: tegra194: Don't force the device into the D0 state before L2 Manikanta Maddireddy
2026-03-24 19:07 ` [PATCH v8 05/14] PCI: tegra194: Disable PERST IRQ only in Endpoint mode Manikanta Maddireddy
2026-03-24 19:07 ` [PATCH v8 06/14] PCI: tegra194: Use devm_gpiod_get_optional() to parse "nvidia,refclk-select" Manikanta Maddireddy
2026-03-24 19:07 ` [PATCH v8 07/14] PCI: tegra194: Disable direct speed change for Endpoint Manikanta Maddireddy
2026-03-24 19:07 ` [PATCH v8 08/14] PCI: tegra194: Set LTR message request before PCIe link up Manikanta Maddireddy
2026-03-24 19:07 ` [PATCH v8 09/14] PCI: tegra194: Allow system suspend when the Endpoint link is not up Manikanta Maddireddy
2026-04-08 20:59   ` Bjorn Helgaas
2026-04-08 21:03     ` Bjorn Helgaas
2026-04-09  6:59       ` Manikanta Maddireddy
2026-08-13 22:41   ` sashiko-bot
2026-03-24 19:07 ` [PATCH v8 10/14] PCI: tegra194: Free up EP resources during remove() Manikanta Maddireddy
2026-08-13 23:00   ` sashiko-bot
2026-03-24 19:07 ` [PATCH v8 11/14] PCI: tegra194: Use DWC IP core version Manikanta Maddireddy
2026-08-13 23:18   ` sashiko-bot
2026-03-24 19:07 ` [PATCH v8 12/14] PCI: dwc: Apply ECRC workaround to DesignWare 5.00a as well Manikanta Maddireddy
2026-04-08 22:24   ` Bjorn Helgaas
2026-04-09  8:51     ` Manikanta Maddireddy
2026-04-09 18:45       ` Bjorn Helgaas
2026-04-10  6:32         ` Manikanta Maddireddy
2026-08-13 23:26   ` sashiko-bot
2026-03-24 19:07 ` [PATCH v8 13/14] PCI: tegra194: Disable L1.2 capability of Tegra234 EP Manikanta Maddireddy
2026-08-13 23:40   ` sashiko-bot [this message]
2026-03-24 19:07 ` [PATCH v8 14/14] PCI: tegra194: Fix CBB timeout caused by DBI access before core power-on Manikanta Maddireddy
2026-08-13 23:56   ` sashiko-bot
2026-04-04 15:10 ` [PATCH v8 00/14] Fixes to pcie-tegra194 driver 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=20260813234001.3AB341F000E9@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=mmaddireddy@nvidia.com \
    --cc=sashiko-reviews@lists.linux.dev \
    /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