Linux USB
 help / color / mirror / Atom feed
From: Mario Limonciello <mario.limonciello@amd.com>
To: Bjorn Helgaas <helgaas@kernel.org>,
	"Rafael J. Wysocki" <rafael@kernel.org>
Cc: Bjorn Helgaas <bhelgaas@google.com>,
	"Rafael J . Wysocki" <rjw@rjwysocki.net>,
	Mika Westerberg <mika.westerberg@linux.intel.com>,
	Hans de Goede <hdegoede@redhat.com>,
	Shyam Sundar S K <Shyam-sundar.S-k@amd.com>,
	"open list:X86 PLATFORM DRIVERS"
	<platform-driver-x86@vger.kernel.org>,
	"open list:PCI SUBSYSTEM" <linux-pci@vger.kernel.org>,
	linux-pm@vger.kernel.org,
	"open list:USB XHCI DRIVER" <linux-usb@vger.kernel.org>,
	iain@orangesquash.org.uk
Subject: Re: [PATCH v18 2/2] PCI: Add a quirk for AMD PCIe root ports w/ USB4 controllers
Date: Wed, 13 Sep 2023 23:59:00 -0500	[thread overview]
Message-ID: <75e5175e-406e-41dd-90c7-3dc30741897e@amd.com> (raw)
In-Reply-To: <001d9c72-49df-4a8d-a9bd-10311887c60d@amd.com>

On 9/13/2023 16:16, Mario Limonciello wrote:
> On 9/13/2023 16:05, Bjorn Helgaas wrote:
> [cut]
>>>> I expect it to be an ongoing issue.  I also expect unless we use
>>>> constraints or convince the firmware team to add a _S0W object with a
>>>> value of "0" for the sake of Linux that we will be adding IDs every 
>>>> year
>>>> to wherever this lands as we reproduce it on newer SoCs.
>>>
>>> So maybe the way to go is to make the AMD PMC driver set a flag for
>>> Root Ports on suspend or similar.
>>
>> I like the quirk approach.  When PMC is involved, the device behavior
>> doesn't conform to what it advertised via PME_Support.
>>
>> The v18 quirk isn't connected to PMC at all, so IIUC it avoids
>> D3hot/D3cold unnecessarily when amd/pmc is not loaded.
>>
> 
> Technically someone could; but realistically no one will be using these 
> machines without amd-pmc.
> 
> The battery life over suspend would be abhorrent.
> 
>> I don't object to avoiding D3hot/D3cold unconditionally.  Presumably
>> we *could* save a little power by using them when amd/pci isn't
>> loaded, but amd/pci would have to iterate through all PCI devices when
>> it loads, save previous state, do the quirk, and then restore the
>> previous state on module unload.  And it would have to use notifiers
>> or assume no Root Port hotplug.  All sounds kind of complicated.
>>
> 
> Yeah this does sound needlessly complicated.
> 
>> Maybe it would even be enough to just clear dev->pme_support so we
>> know wakeups don't work.  It would be a pretty big benefit if we
>> didn't have to add another bit and complicate pci_prepare_to_sleep()
>> or pci_target_state().
>>
> 
> I don't think clearing PME support entirely is going to help.  The 
> reason is that pci_target_state() will fall back to PCI_D3hot when 
> dev->pme_support is fully cleared.
> 
> I think that clearing *just the bits* for D3hot and D3cold in PME 
> support should work though.  I'll test this.

I did confirm this works properly.

> 
> Assuming it works how about if we put the quirk to clear the 
> D3hot/D3cold PME support bit in drivers/platform/x86/amd/pmc/pmc-quirks.c?
> 
> It's still a quirk file and it makes it very clear that this behavior is 
> caused by what amd-pmc does.

I've got it coded up like this and working, so please let me know if 
this approach is amenable and I'll drop an updated version.

If you would prefer it to be in pci/quirks.c I believe I can do either.

  reply	other threads:[~2023-09-14  4:59 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-13  4:08 [PATCH v18 0/2] Add quirk for PCIe root port on AMD systems Mario Limonciello
2023-09-13  4:08 ` [PATCH v18 1/2] PCI: Move the `PCI_CLASS_SERIAL_USB_USB4` definition to common header Mario Limonciello
2023-09-13 10:34   ` Mika Westerberg
2023-09-13  4:08 ` [PATCH v18 2/2] PCI: Add a quirk for AMD PCIe root ports w/ USB4 controllers Mario Limonciello
2023-09-13  4:25   ` Lukas Wunner
2023-09-13  4:43     ` Mario Limonciello
2023-09-13  8:14       ` Rafael J. Wysocki
2023-09-13 14:31       ` Lukas Wunner
2023-09-13 16:36         ` Mario Limonciello
2023-09-14 14:17           ` Lukas Wunner
2023-09-14 14:31             ` Mario Limonciello
2023-09-14 14:53               ` Lukas Wunner
2023-09-14 15:33                 ` Bjorn Helgaas
2023-09-14 16:05                   ` Rafael J. Wysocki
2023-09-14 19:04                   ` Lukas Wunner
2023-09-14 19:09                     ` Lukas Wunner
2023-09-13  9:56   ` kernel test robot
2023-09-13 10:17   ` kernel test robot
2023-09-13 10:20   ` Rafael J. Wysocki
2023-09-13 15:40     ` Bjorn Helgaas
2023-09-13 16:35       ` Mario Limonciello
2023-09-13 17:42         ` Rafael J. Wysocki
2023-09-13 21:05           ` Bjorn Helgaas
2023-09-13 21:16             ` Mario Limonciello
2023-09-14  4:59               ` Mario Limonciello [this message]
2023-09-14 12:32                 ` Bjorn Helgaas
2023-09-14 13:57                   ` Mario Limonciello
2023-09-15  0:55                 ` Mario Limonciello
2023-09-15  1:24                   ` 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=75e5175e-406e-41dd-90c7-3dc30741897e@amd.com \
    --to=mario.limonciello@amd.com \
    --cc=Shyam-sundar.S-k@amd.com \
    --cc=bhelgaas@google.com \
    --cc=hdegoede@redhat.com \
    --cc=helgaas@kernel.org \
    --cc=iain@orangesquash.org.uk \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mika.westerberg@linux.intel.com \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rafael@kernel.org \
    --cc=rjw@rjwysocki.net \
    /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