All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bjorn Helgaas <helgaas@kernel.org>
To: Rajvi Jingar <rajvi.jingar@linux.intel.com>
Cc: rafael.j.wysocki@intel.com, bhelgaas@google.com,
	david.e.box@linux.intel.com, linux-pci@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org,
	Kai-Heng Feng <kai.heng.feng@canonical.com>
Subject: Re: [RESEND PATCH v3 2/2] PCI/PTM: fix to maintain pci_dev->ptm_enabled
Date: Tue, 30 Aug 2022 11:25:29 -0500	[thread overview]
Message-ID: <20220830162529.GA106073@bhelgaas> (raw)
In-Reply-To: <20220830104913.1620539-2-rajvi.jingar@linux.intel.com>

[+cc Kai-Heng]

On Tue, Aug 30, 2022 at 03:49:13AM -0700, Rajvi Jingar wrote:
> pci_dev->ptm_enabled needs to be maintained to reflect the current PTM
> state of the device. In pci_ptm_disable(), clear ptm_enabled from
> 'struct pci_dev' on disabling PTM state for the device.
> In pci_restore_ptm_state(), set dev->ptm_enabled based on the restored
> PTM state of the device.
> 
> In pci_ptm_disable(), perform ptm_enabled check to avoid config space
> access in case if PTM is already disabled for the device. ptm_enabled
> won't be set for non-PCIe devices so pci_is_pcie(dev) check is not
> needed anymore.

This one sounds like it's supposed to fix something, but I'm not clear
exactly what.

I have a vague memory of config accesses messing up a low power state.
But this is still completely magical and unmaintainable since AFAIK
there is nothing in the PCIe spec about avoiding config accesses when
PTM is disabled.

At the very least, we would need more details in the commit log and
a hint in the code about this.

> Signed-off-by: Rajvi Jingar <rajvi.jingar@linux.intel.com>
> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> ---
>  v1->v2:
>    - add ptm_enabled check in pci_ptm_disable().
>    - set the dev->ptm_enabled value in pci_restore_ptm_state().
>  v2->v3:
>    - remove pci_is_pcie(dev) check in pci_ptm_disable().
>    - add Reviewed-by tag in commit message
> ---
>  drivers/pci/pcie/ptm.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/pci/pcie/ptm.c b/drivers/pci/pcie/ptm.c
> index 368a254e3124..1ce241d4538f 100644
> --- a/drivers/pci/pcie/ptm.c
> +++ b/drivers/pci/pcie/ptm.c
> @@ -34,7 +34,7 @@ void pci_disable_ptm(struct pci_dev *dev)
>  	int ptm;
>  	u16 ctrl;
>  
> -	if (!pci_is_pcie(dev))
> +	if (!dev->ptm_enabled)
>  		return;

This will conflict with a change Kai-Heng Feng and I have been working
on, but I can resolve it when applying.

>  	ptm = pci_find_ext_capability(dev, PCI_EXT_CAP_ID_PTM);
> @@ -44,6 +44,7 @@ void pci_disable_ptm(struct pci_dev *dev)
>  	pci_read_config_word(dev, ptm + PCI_PTM_CTRL, &ctrl);
>  	ctrl &= ~(PCI_PTM_CTRL_ENABLE | PCI_PTM_CTRL_ROOT);
>  	pci_write_config_word(dev, ptm + PCI_PTM_CTRL, ctrl);
> +	dev->ptm_enabled = 0;
>  }
>  
>  void pci_save_ptm_state(struct pci_dev *dev)
> @@ -83,6 +84,7 @@ void pci_restore_ptm_state(struct pci_dev *dev)
>  
>  	cap = (u16 *)&save_state->cap.data[0];
>  	pci_write_config_word(dev, ptm + PCI_PTM_CTRL, *cap);
> +	dev->ptm_enabled = !!(*cap & PCI_PTM_CTRL_ENABLE);
>  }
>  
>  void pci_ptm_init(struct pci_dev *dev)
> -- 
> 2.25.1
> 

  reply	other threads:[~2022-08-30 16:25 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-30 10:49 [RESEND PATCH v3 1/2] PCI/PM: refactor pci_pm_suspend_noirq() Rajvi Jingar
2022-08-30 10:49 ` [RESEND PATCH v3 2/2] PCI/PTM: fix to maintain pci_dev->ptm_enabled Rajvi Jingar
2022-08-30 16:25   ` Bjorn Helgaas [this message]
2022-08-30 16:58     ` Rafael J. Wysocki
2022-08-30 17:37       ` Bjorn Helgaas
2022-08-30 18:03         ` Rafael J. Wysocki
2022-08-30 19:46           ` Bjorn Helgaas
2022-08-31 17:53             ` Rafael J. Wysocki
2022-09-01 21:26               ` Bjorn Helgaas
2022-09-03 17:03                 ` Rafael J. Wysocki
2022-08-30 11:44 ` [RESEND PATCH v3 1/2] PCI/PM: refactor pci_pm_suspend_noirq() Rafael J. Wysocki
2022-08-30 16:17   ` Bjorn Helgaas
2022-08-30 16:20     ` Bjorn Helgaas

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=20220830162529.GA106073@bhelgaas \
    --to=helgaas@kernel.org \
    --cc=bhelgaas@google.com \
    --cc=david.e.box@linux.intel.com \
    --cc=kai.heng.feng@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=rajvi.jingar@linux.intel.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.