linux-pci.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Mario Limonciello <superm1@kernel.org>
To: "Ilpo Järvinen" <ilpo.jarvinen@linux.intel.com>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	Mathias Nyman <mathias.nyman@intel.com>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	"open list : PCI SUBSYSTEM" <linux-pci@vger.kernel.org>,
	open list <linux-kernel@vger.kernel.org>,
	"open list : USB XHCI DRIVER" <linux-usb@vger.kernel.org>,
	Daniel Drake <drake@endlessos.org>, Gary Li <Gary.Li@amd.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Mario Limonciello <mario.limonciello@amd.com>
Subject: Re: [PATCH v2 1/4] PCI: Check PCI_PM_CTRL in pci_dev_wait()
Date: Thu, 11 Jul 2024 10:10:44 -0500	[thread overview]
Message-ID: <dcaefa84-09f5-4be5-9f66-aac6bf5fabf7@kernel.org> (raw)
In-Reply-To: <15091369-fc5c-af2d-7591-e1732097e84c@linux.intel.com>

On 7/11/2024 10:07, Ilpo Järvinen wrote:
> On Wed, 10 Jul 2024, superm1@kernel.org wrote:
> 
>> From: Mario Limonciello <mario.limonciello@amd.com>
>>
>> A device that has gone through a reset may return a value in PCI_COMMAND
>> but that doesn't mean it's finished transitioning to D0.  On devices that
>> support power management explicitly check PCI_PM_CTRL on everything but
>> system resume to ensure the transition happened.
>>
>> Devices that don't support power management and system resume will
>> continue to use PCI_COMMAND.
>>
>> Signed-off-by: Mario Limonciello <mario.limonciello@amd.com>
>> ---
>>   drivers/pci/pci.c | 27 ++++++++++++++++++++-------
>>   1 file changed, 20 insertions(+), 7 deletions(-)
>>
>> diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
>> index 35fb1f17a589c..4ad02ad640518 100644
>> --- a/drivers/pci/pci.c
>> +++ b/drivers/pci/pci.c
>> @@ -1270,21 +1270,34 @@ static int pci_dev_wait(struct pci_dev *dev, char *reset_type, int timeout)
>>   	 * the read (except when CRS SV is enabled and the read was for the
>>   	 * Vendor ID; in that case it synthesizes 0x0001 data).
>>   	 *
>> -	 * Wait for the device to return a non-CRS completion.  Read the
>> -	 * Command register instead of Vendor ID so we don't have to
>> -	 * contend with the CRS SV value.
>> +	 * Wait for the device to return a non-CRS completion.  On devices
>> +	 * that support PM control and on waits that aren't part of system
>> +	 * resume read the PM control register to ensure the device has
>> +	 * transitioned to D0.  On devices that don't support PM control,
>> +	 * or during system resume read the command register to instead of
>> +	 * Vendor ID so we don't have to contend with the CRS SV value.
>>   	 */
>>   	for (;;) {
>> -		u32 id;
>>   
>>   		if (pci_dev_is_disconnected(dev)) {
>>   			pci_dbg(dev, "disconnected; not waiting\n");
>>   			return -ENOTTY;
>>   		}
>>   
>> -		pci_read_config_dword(dev, PCI_COMMAND, &id);
>> -		if (!PCI_POSSIBLE_ERROR(id))
>> -			break;
>> +		if (dev->pm_cap && strcmp(reset_type, "resume") != 0) {
> 
> Comparing to a string makes me feel reset_type should be changed to
> something that allows direct compare and those values only mapped into
> string while printing it.
> 

Thanks, that's a great suggestion.  I'll add a patch earlier in the 
series to make an enum of the types instead and a mapping function for 
them to get the string as needed.

  reply	other threads:[~2024-07-11 15:10 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-10 20:58 [PATCH v2 0/4] Verify devices transition from D3cold to D0 superm1
2024-07-10 20:58 ` [PATCH v2 1/4] PCI: Check PCI_PM_CTRL in pci_dev_wait() superm1
2024-07-11 15:07   ` Ilpo Järvinen
2024-07-11 15:10     ` Mario Limonciello [this message]
2024-07-10 20:58 ` [PATCH v2 2/4] PCI: Verify functions currently in D3cold have entered D0 superm1
2024-07-11 15:27   ` Ilpo Järvinen
2024-07-10 20:58 ` [PATCH v2 3/4] PCI: Allow Ryzen XHCI controllers into D3cold and drop delays superm1
2024-07-10 20:58 ` [PATCH v2 4/4] PCI: Drop Radeon quirk for Macbook Pro 8.2 superm1

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=dcaefa84-09f5-4be5-9f66-aac6bf5fabf7@kernel.org \
    --to=superm1@kernel.org \
    --cc=Gary.Li@amd.com \
    --cc=bhelgaas@google.com \
    --cc=drake@endlessos.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mario.limonciello@amd.com \
    --cc=mathias.nyman@intel.com \
    --cc=mika.westerberg@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).