mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Kai-Heng Feng <kaihengf@nvidia.com>
To: "Chia-Lin Kao (AceLan)" <acelan.kao@canonical.com>,
	Mario Limonciello <mario.limonciello@amd.com>
Cc: Bjorn Helgaas <helgaas@kernel.org>,
	bhelgaas@google.com, mika.westerberg@linux.intel.com,
	linux-pci@vger.kernel.org, linux-pm@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] PCI/PM: Put devices to low power state on shutdown
Date: Fri, 4 Oct 2024 17:26:25 +0800	[thread overview]
Message-ID: <74f2c388-b622-4304-bbc9-2f1dceaef6c3@nvidia.com> (raw)
In-Reply-To: <Zv9wDGp-7-lC8FhZ@acelan-precision5470>

On 2024/10/4 12:33 PM, Chia-Lin Kao (AceLan) wrote:
> On Wed, Sep 11, 2024 at 02:38:20PM -0500, Mario Limonciello wrote:
>> On 9/11/2024 14:16, Mario Limonciello wrote:
>>> On 9/11/2024 14:05, Bjorn Helgaas wrote:
>>>> On Fri, Jul 12, 2024 at 02:24:11PM +0800, Kai-Heng Feng wrote:
>>>>> Some laptops wake up after poweroff when HP Thunderbolt Dock G4 is
>>>>> connected.
>>>>>
>>>>> The following error message can be found during shutdown:
>>>>> pcieport 0000:00:1d.0: AER: Correctable error message received
>>>>> from 0000:09:04.0
>>>>> pcieport 0000:09:04.0: PCIe Bus Error: severity=Correctable,
>>>>> type=Data Link Layer, (Receiver ID)
>>>>> pcieport 0000:09:04.0:   device [8086:0b26] error
>>>>> status/mask=00000080/00002000
>>>>> pcieport 0000:09:04.0:    [ 7] BadDLLP
>>>>>
>>>>> Calling aer_remove() during shutdown can quiesce the error message,
>>>>> however the spurious wakeup still happens.
>>>>>
>>>>> The issue won't happen if the device is in D3 before system shutdown, so
>>>>> putting device to low power state before shutdown to solve the issue.
>>>>>
>>>>> I don't have a sniffer so this is purely guesswork, however I believe
>>>>> putting device to low power state it's the right thing to do.
>>>>
>>>> My objection here is that we don't have an explanation of why this
>>>> should matter or a pointer to any spec language about this situation,
>>>> so it feels a little bit random.
>>>>
>>>> I suppose the problem wouldn't happen if AER interrupts were disabled?
>>>> We already do disable them in aer_suspend(), but maybe that's not used
>>>> in the shutdown path?
>>>>
>>>> My understanding is that .shutdown() should turn off device interrupts
>>>> and stop DMA.  So maybe we need an aer_shutdown() that disables
>>>> interrupts?
>>>>
>>>
>>> IMO I see this commit as two problems with the same solution.
>>>
>>> I don't doubt that cleaning up AER interrupts in the shutdown path would
>>> help AER messages, but you really don't "want" devices to be in D0 when
>>> the system is "off" because even if the system is off some rails are
>>> still active and the device might still be powered.
>>>
>>> A powered device could cause interrupts (IE a spurious wakeup).
>>
>> It's a bit of a stretch, but ACPI 7.4.2.5 and 7.4.2.6 are the closest
>> corollary to a spec I can find.
>>
>> "Devices states are compatible with the current Power Resource states. In
>> other words, all devices are in the D3 state when the system state is S4."
>>
>> https://uefi.org/htmlspecs/ACPI_Spec_6_4_html/07_Power_and_Performance_Mgmt/oem-supplied-system-level-control-methods.html
> Hi,
> 
> I'd like to revive this thread and support this description from the
> ACPI spec.
> 
> In ACPI 7.4.2.5, it states: "All devices are in the D3 state when the
> system state is S4," and in ACPI 7.4.2.6, it says: "The S5 state is
> similar to the S4 state except that OSPM does not save any context."
> 
> I believe this implies that devices should also be in D3 when the
> system is in S5.

Sorry for the belated response.

I think AceLan found a better explanation on why this patch is needed.

I can resend the patch with modified message if Bjorn agrees.

Kai-Heng

> 
>>
>>>
>>>>> Link: https://bugzilla.kernel.org/show_bug.cgi?id=219036
>>>>> Signed-off-by: Kai-Heng Feng <kai.heng.feng@canonical.com>
>>>>> ---
>>>>>    drivers/pci/pci-driver.c | 8 ++++++++
>>>>>    1 file changed, 8 insertions(+)
>>>>>
>>>>> diff --git a/drivers/pci/pci-driver.c b/drivers/pci/pci-driver.c
>>>>> index af2996d0d17f..4c6f66f3eb54 100644
>>>>> --- a/drivers/pci/pci-driver.c
>>>>> +++ b/drivers/pci/pci-driver.c
>>>>> @@ -510,6 +510,14 @@ static void pci_device_shutdown(struct device *dev)
>>>>>        if (drv && drv->shutdown)
>>>>>            drv->shutdown(pci_dev);
>>>>> +    /*
>>>>> +     * If driver already changed device's power state, it can mean the
>>>>> +     * wakeup setting is in place, or a workaround is used.
>>>>> Hence keep it
>>>>> +     * as is.
>>>>> +     */
>>>>> +    if (!kexec_in_progress && pci_dev->current_state == PCI_D0)
>>>>> +        pci_prepare_to_sleep(pci_dev);
>>>>> +
>>>>>        /*
>>>>>         * If this is a kexec reboot, turn off Bus Master bit on the
>>>>>         * device to tell it to not continue to do DMA. Don't touch
>>>>> -- 
>>>>> 2.43.0
>>>>>
>>>
>>


  reply	other threads:[~2024-10-04  9:26 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-07-12  6:24 Kai-Heng Feng
2024-07-12 14:59 ` Mario Limonciello
2024-08-22 19:28 ` Mario Limonciello
2024-08-26 12:03   ` Kai-Heng Feng
2024-09-11 14:08   ` Mario Limonciello
2024-09-11 19:05 ` Bjorn Helgaas
2024-09-11 19:16   ` Mario Limonciello
2024-09-11 19:38     ` Mario Limonciello
2024-09-12  7:02       ` Kai-Heng Feng
2024-09-12 13:10         ` Mario Limonciello
2024-10-04  4:33       ` Chia-Lin Kao (AceLan)
2024-10-04  9:26         ` Kai-Heng Feng [this message]
2024-09-12  3:00   ` Kai-Heng Feng
2024-09-12 16:57     ` Bjorn Helgaas
2024-09-13  6:00       ` Kai-Heng Feng
2024-09-13  8:01         ` Mika Westerberg
2024-09-13 20:33           ` Mario Limonciello
2024-09-15  7:14             ` Mika Westerberg
2024-10-09 22:24           ` Bjorn Helgaas
2024-10-10  4:52             ` Mika Westerberg

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=74f2c388-b622-4304-bbc9-2f1dceaef6c3@nvidia.com \
    --to=kaihengf@nvidia.com \
    --cc=acelan.kao@canonical.com \
    --cc=bhelgaas@google.com \
    --cc=helgaas@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pci@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mario.limonciello@amd.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

all inboxes | Powered by JetHome®