From: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
To: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>,
David Box <david.e.box@linux.intel.com>
Cc: "Bjorn Helgaas" <bhelgaas@google.com>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Nirmal Patel" <nirmal.patel@linux.intel.com>,
"Jonathan Derrick" <jonathan.derrick@linux.dev>,
"Jeff Johnson" <jjohnson@kernel.org>,
linux-pci@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
linux-arm-msm@vger.kernel.org, linux-wireless@vger.kernel.org,
ath12k@lists.infradead.org, ath11k@lists.infradead.org,
ath10k@lists.infradead.org,
"Krishna Chaitanya Chundru" <krishna.chundru@oss.qualcomm.com>,
"Rafael J. Wysocki" <rafael@kernel.org>
Subject: Re: [PATCH v2 2/8] PCI/ASPM: Fix the behavior of pci_enable_link_state*() APIs
Date: Tue, 26 Aug 2025 15:55:42 +0300 (EEST) [thread overview]
Message-ID: <f644fc83-31cc-1f0e-58cf-7c007e6173e4@linux.intel.com> (raw)
In-Reply-To: <20250825-ath-aspm-fix-v2-2-61b2f2db7d89@oss.qualcomm.com>
[-- Attachment #1: Type: text/plain, Size: 5816 bytes --]
+David
On Mon, 25 Aug 2025, Manivannan Sadhasivam via B4 Relay wrote:
> From: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
>
> pci_enable_link_state() and pci_enable_link_state_locked() APIs are
> supposed to be symmectric with pci_disable_link_state() and
> pci_disable_link_state_locked() APIs.
>
> But unfortunately, they are not symmetric. This behavior was mentioned in
> the kernel-doc of these APIs:
>
> " Clear and set the default device link state..."
>
> and
>
> "Also note that this does not enable states disabled by
> pci_disable_link_state()"
>
> These APIs won't enable all the states specified by the 'state' parameter,
> but only enable the ones not previously disabled by the
> pci_disable_link_state*() APIs. But this behavior doesn't align with the
> naming of these APIs, as they give the impression that these APIs will
> enable all the specified states.
>
> To resolve this ambiguity, allow these APIs to enable the specified states,
> regardeless of whether they were previously disabled or not. This is
> accomplished by clearing the previously disabled states from the
> 'link::aspm_disable' parameter in __pci_enable_link_state() helper. Also,
> reword the kernel-doc to reflect this behavior.
>
> The current callers of pci_enable_link_state_locked() APIs (vmd and
> pcie-qcom) did not disable the ASPM states before calling this API. So it
> is evident that they do not depend on the previous behavior of this API and
> intend to enable all the specified states.
While it might be "safe" in the sense that ->aspm_disable is not set by
anything, I'm still not sure if overloading this function for two
different use cases is a good idea.
I'd like to hear David's opinion on this as he grasps the ->aspm_default
vs ->aspm_disable thing much better than I do.
> And the other API, pci_enable_link_state() doesn't have a caller for now,
> but will be used by the 'atheros' WLAN drivers in the subsequent commits.
>
> Suggested-by: Ilpo Järvinen <ilpo.jarvinen@linux.intel.com>
This tag sound like I'm endorsing this approach which is not the case. I'd
prefer separate functions for each use case, setting aspm_default and
another for the enable state.
--
i.
> Co-developed-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> Signed-off-by: Krishna Chaitanya Chundru <krishna.chundru@oss.qualcomm.com>
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@oss.qualcomm.com>
> ---
> drivers/pci/pcie/aspm.c | 33 ++++++++++++++++++---------------
> 1 file changed, 18 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/pci/pcie/aspm.c b/drivers/pci/pcie/aspm.c
> index be9bd272057c3472f3e31dc9568340b19d52012a..fac46113a90c7fac6c97125e6a7e385045780005 100644
> --- a/drivers/pci/pcie/aspm.c
> +++ b/drivers/pci/pcie/aspm.c
> @@ -1459,6 +1459,7 @@ static int __pci_enable_link_state(struct pci_dev *pdev, int state, bool locked)
> down_read(&pci_bus_sem);
> mutex_lock(&aspm_lock);
> link->aspm_default = pci_calc_aspm_enable_mask(state);
> + link->aspm_disable &= ~state;
> pcie_config_aspm_link(link, policy_to_aspm_state(link));
>
> link->clkpm_default = (state & PCIE_LINK_STATE_CLKPM) ? 1 : 0;
> @@ -1471,17 +1472,18 @@ static int __pci_enable_link_state(struct pci_dev *pdev, int state, bool locked)
> }
>
> /**
> - * pci_enable_link_state - Clear and set the default device link state so that
> - * the link may be allowed to enter the specified states. Note that if the
> - * BIOS didn't grant ASPM control to the OS, this does nothing because we can't
> - * touch the LNKCTL register. Also note that this does not enable states
> - * disabled by pci_disable_link_state(). Return 0 or a negative errno.
> + * pci_enable_link_state - Enable device's link state
> + * @pdev: PCI device
> + * @state: Mask of ASPM link states to enable
> + *
> + * Enable device's link state, so the link will enter the specified states.
> + * Note that if the BIOS didn't grant ASPM control to the OS, this does
> + * nothing because we can't touch the LNKCTL register.
> *
> * Note: Ensure devices are in D0 before enabling PCI-PM L1 PM Substates, per
> * PCIe r6.0, sec 5.5.4.
> *
> - * @pdev: PCI device
> - * @state: Mask of ASPM link states to enable
> + * Return: 0 on success, a negative errno otherwise.
> */
> int pci_enable_link_state(struct pci_dev *pdev, int state)
> {
> @@ -1490,19 +1492,20 @@ int pci_enable_link_state(struct pci_dev *pdev, int state)
> EXPORT_SYMBOL(pci_enable_link_state);
>
> /**
> - * pci_enable_link_state_locked - Clear and set the default device link state
> - * so that the link may be allowed to enter the specified states. Note that if
> - * the BIOS didn't grant ASPM control to the OS, this does nothing because we
> - * can't touch the LNKCTL register. Also note that this does not enable states
> - * disabled by pci_disable_link_state(). Return 0 or a negative errno.
> + * pci_enable_link_state_locked - Enable device's link state
> + * @pdev: PCI device
> + * @state: Mask of ASPM link states to enable
> + *
> + * Enable device's link state, so the link will enter the specified states.
> + * Note that if the BIOS didn't grant ASPM control to the OS, this does
> + * nothing because we can't touch the LNKCTL register.
> *
> * Note: Ensure devices are in D0 before enabling PCI-PM L1 PM Substates, per
> * PCIe r6.0, sec 5.5.4.
> *
> - * @pdev: PCI device
> - * @state: Mask of ASPM link states to enable
> - *
> * Context: Caller holds pci_bus_sem read lock.
> + *
> + * Return: 0 on success, a negative errno otherwise.
> */
> int pci_enable_link_state_locked(struct pci_dev *pdev, int state)
> {
>
>
next prev parent reply other threads:[~2025-08-26 13:02 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-25 17:44 [PATCH v2 0/8] PCI/ASPM: Fix pci_enable_link_state*() APIs behavior Manivannan Sadhasivam via B4 Relay
2025-08-25 17:44 ` [PATCH v2 1/8] PCI/ASPM: Always disable ASPM when driver requests it Manivannan Sadhasivam via B4 Relay
2025-08-25 17:44 ` [PATCH v2 2/8] PCI/ASPM: Fix the behavior of pci_enable_link_state*() APIs Manivannan Sadhasivam via B4 Relay
2025-08-26 12:55 ` Ilpo Järvinen [this message]
2025-08-26 21:24 ` David Box
2025-09-06 15:37 ` Manivannan Sadhasivam
2025-09-06 14:53 ` Manivannan Sadhasivam
2025-09-08 10:24 ` Ilpo Järvinen
2025-08-25 17:44 ` [PATCH v2 3/8] PCI/ASPM: Transition the device to D0 (if required) inside pci_enable_link_state_locked() API Manivannan Sadhasivam via B4 Relay
2025-08-25 17:44 ` [PATCH v2 4/8] PCI/ASPM: Improve the kernel-doc for pci_disable_link_state*() APIs Manivannan Sadhasivam via B4 Relay
2025-08-25 17:44 ` [PATCH v2 5/8] PCI/ASPM: Return enabled ASPM states from pcie_aspm_enabled() API Manivannan Sadhasivam via B4 Relay
2025-08-26 15:19 ` Jeff Johnson
2025-08-25 17:44 ` [PATCH v2 6/8] wifi: ath12k: Use pci_{enable/disable}_link_state() APIs to enable/disable ASPM states Manivannan Sadhasivam via B4 Relay
2025-08-26 15:38 ` Jeff Johnson
2025-08-26 16:00 ` Ilpo Järvinen
2025-08-26 16:40 ` Jeff Johnson
2025-08-25 17:44 ` [PATCH v2 7/8] wifi: ath11k: " Manivannan Sadhasivam via B4 Relay
2025-08-25 17:44 ` [PATCH v2 8/8] wifi: ath10k: " Manivannan Sadhasivam via B4 Relay
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=f644fc83-31cc-1f0e-58cf-7c007e6173e4@linux.intel.com \
--to=ilpo.jarvinen@linux.intel.com \
--cc=ath10k@lists.infradead.org \
--cc=ath11k@lists.infradead.org \
--cc=ath12k@lists.infradead.org \
--cc=bhelgaas@google.com \
--cc=david.e.box@linux.intel.com \
--cc=jjohnson@kernel.org \
--cc=jonathan.derrick@linux.dev \
--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=linux-wireless@vger.kernel.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=manivannan.sadhasivam@oss.qualcomm.com \
--cc=nirmal.patel@linux.intel.com \
--cc=rafael@kernel.org \
--cc=robh@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox