All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johan Hovold <johan@kernel.org>
To: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
Cc: "Manivannan Sadhasivam" <mani@kernel.org>,
	"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
	"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
	"Rob Herring" <robh@kernel.org>,
	"Bjorn Helgaas" <bhelgaas@google.com>,
	linux-arm-msm@vger.kernel.org, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org,
	"Krishna Chaitanya Chundru" <krishna.chundru@oss.qualcomm.com>,
	stable@vger.kernel.org
Subject: Re: [PATCH 1/2] PCI: qcom: Switch to bus notifier for enabling ASPM of PCI devices
Date: Tue, 15 Jul 2025 09:48:30 +0200	[thread overview]
Message-ID: <aHYHzrl0DE2HV86S@hovoldconsulting.com> (raw)
In-Reply-To: <20250714-aspm_fix-v1-1-7d04b8c140c8@oss.qualcomm.com>

On Mon, Jul 14, 2025 at 11:31:04PM +0530, Manivannan Sadhasivam wrote:
> Commit 9f4f3dfad8cf ("PCI: qcom: Enable ASPM for platforms supporting 1.9.0
> ops") allowed the Qcom controller driver to enable ASPM for all PCI devices
> enumerated at the time of the controller driver probe. It proved to be
> useful for devices already powered on by the bootloader as it allowed
> devices to enter ASPM without user intervention.
> 
> However, it could not enable ASPM for the hotplug capable devices i.e.,
> devices enumerated *after* the controller driver probe. This limitation
> mostly went unnoticed as the Qcom PCI controllers are not hotplug capable
> and also the bootloader has been enabling the PCI devices before Linux
> Kernel boots (mostly on the Qcom compute platforms which users use on a
> daily basis).
> 
> But with the advent of the commit b458ff7e8176 ("PCI/pwrctl: Ensure that
> pwrctl drivers are probed before PCI client drivers"), the pwrctrl driver
> started to block the PCI device enumeration until it had been probed.
> Though, the intention of the commit was to avoid race between the pwrctrl
> driver and PCI client driver, it also meant that the pwrctrl controlled PCI
> devices may get probed after the controller driver and will no longer have
> ASPM enabled. So users started noticing high runtime power consumption with
> WLAN chipsets on Qcom compute platforms like Thinkpad X13s, and Thinkpad
> T14s, etc...
> 
> Obviously, it is the pwrctrl change that caused regression, but it
> ultimately uncovered a flaw in the ASPM enablement logic of the controller
> driver. So to address the actual issue, switch to the bus notifier for
> enabling ASPM of the PCI devices. The notifier will notify the controller
> driver when a PCI device is attached to the bus, thereby allowing it to
> enable ASPM more reliably. It should be noted that the
> 'pci_dev::link_state', which is required for enabling ASPM by the
> pci_enable_link_state_locked() API, is only set by the time of
> BUS_NOTIFY_BIND_DRIVER stage of the notification. So we cannot enable ASPM
> during BUS_NOTIFY_ADD_DEVICE stage.

A problem with this approach is that ASPM will never be enabled (and
power consumption will be higher) in case an endpoint driver is missing.

I think that's something we should try to avoid.

> So with this, we can also get rid of the controller driver specific
> 'qcom_pcie_ops::host_post_init' callback.
> 
> Cc: stable@vger.kernel.org # v6.7
> Fixes: 9f4f3dfad8cf ("PCI: qcom: Enable ASPM for platforms supporting 1.9.0 ops")
> Reported-by: Johan Hovold <johan@kernel.org>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>

Note that the patch fails to apply to 6.16-rc6 due to changes in
linux-next. Depending on how fast we can come up with a fix it may be
better to target 6.16.

> -static int qcom_pcie_enable_aspm(struct pci_dev *pdev, void *userdata)
> -{
> -	/*
> -	 * Downstream devices need to be in D0 state before enabling PCI PM
> -	 * substates.
> -	 */
> -	pci_set_power_state_locked(pdev, PCI_D0);
> -	pci_enable_link_state_locked(pdev, PCIE_LINK_STATE_ALL);
> -
> -	return 0;
> -}

I think you should consider leaving this helper in place here to keep
the size of the diff down (e.g. as you intend to backport this).

> +static int qcom_pcie_enable_aspm(struct pci_dev *pdev)
> +{
> +	/*
> +	 * Downstream devices need to be in D0 state before enabling PCI PM
> +	 * substates.
> +	 */
> +	pci_set_power_state_locked(pdev, PCI_D0);
> +	pci_enable_link_state_locked(pdev, PCIE_LINK_STATE_ALL);

You need to use the non-locked helpers here since you no longer hold the
bus semaphore (e.g. as reported by lockdep).

Maybe this makes the previous comment about not moving the helper moot.

> +
> +	return 0;
> +}
> +
> +static int pcie_qcom_notify(struct notifier_block *nb, unsigned long action,
> +			      void *data)
> +{
> +	struct qcom_pcie *pcie = container_of(nb, struct qcom_pcie, nb);

This results in an unused variable warning (presumably until the next
patch in the series is applied).

> +	struct device *dev = data;
> +	struct pci_dev *pdev = to_pci_dev(dev);
> +
> +	switch (action) {
> +	case BUS_NOTIFY_BIND_DRIVER:
> +		qcom_pcie_enable_aspm(pdev);
> +		break;
> +	}
> +
> +	return NOTIFY_DONE;
> +}

Missing newline.

>  static int qcom_pcie_probe(struct platform_device *pdev)
>  {
>  	const struct qcom_pcie_cfg *pcie_cfg;

Johan

  reply	other threads:[~2025-07-15  7:48 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-14 18:01 [PATCH 0/2] PCI: qcom: Switch to bus notifier for enabling ASPM of PCI devices Manivannan Sadhasivam
2025-07-14 18:01 ` [PATCH 1/2] " Manivannan Sadhasivam
2025-07-15  7:48   ` Johan Hovold [this message]
2025-07-15  9:11     ` Manivannan Sadhasivam
2025-07-15  9:33       ` Johan Hovold
2025-07-15  9:46         ` Konrad Dybcio
2025-07-15 10:27         ` Manivannan Sadhasivam
2025-07-15 12:31           ` Johan Hovold
2025-07-21  9:32   ` Johan Hovold
2025-07-21 10:56     ` Manivannan Sadhasivam
2025-07-21 12:49       ` Johan Hovold
2025-07-21 15:45         ` Manivannan Sadhasivam
2025-07-14 18:01 ` [PATCH 2/2] PCI: qcom: Move qcom_pcie_icc_opp_update() to notifier callback Manivannan Sadhasivam
2025-07-15  7:51   ` Johan Hovold
2025-07-15  9:13     ` Manivannan Sadhasivam
2025-07-15  9:54   ` Konrad Dybcio
2025-07-15 10:36     ` Manivannan Sadhasivam
2025-07-15 10:45       ` Konrad Dybcio
2025-07-16  5:28         ` Manivannan Sadhasivam
2025-07-16 10:33           ` Konrad Dybcio
2025-07-21  9:15             ` Johan Hovold
2025-07-16  4:54       ` Krishna Chaitanya Chundru
2025-07-16  6:46         ` Manivannan Sadhasivam
2025-07-16  6:53           ` Krishna Chaitanya Chundru
2025-07-16  7:18             ` Manivannan Sadhasivam
2025-07-21  9:02           ` Johan Hovold
2025-07-21 10:59             ` 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=aHYHzrl0DE2HV86S@hovoldconsulting.com \
    --to=johan@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=krishna.chundru@oss.qualcomm.com \
    --cc=kwilczynski@kernel.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=lpieralisi@kernel.org \
    --cc=mani@kernel.org \
    --cc=manivannan.sadhasivam@oss.qualcomm.com \
    --cc=robh@kernel.org \
    --cc=stable@vger.kernel.org \
    /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.