linux-kernel - Re: [PATCH] PCI / ACPI / PM: Resume bridges w/o drivers on suspend-to-RAM

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0gt+4FiiBxEjdsEYLT+dQq=Q=mC7JtZPsYxps0_a1w-rg@mail.gmail.com>
Date:   Tue, 26 Jun 2018 19:19:29 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     "Rafael J. Wysocki" <rafael@...nel.org>,
        "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux PCI <linux-pci@...r.kernel.org>, n0000b.n000b@...il.com,
        Bjorn Helgaas <bhelgaas@...gle.com>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        LKML <linux-kernel@...r.kernel.org>,
        Linux ACPI <linux-acpi@...r.kernel.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Lukas Wunner <lukas@...ner.de>
Subject: Re: [PATCH] PCI / ACPI / PM: Resume bridges w/o drivers on suspend-to-RAM

On Tue, Jun 26, 2018 at 7:14 PM, Bjorn Helgaas <helgaas@...nel.org> wrote:
> On Tue, Jun 26, 2018 at 04:22:00PM +0200, Rafael J. Wysocki wrote:
>> On Tue, Jun 26, 2018 at 4:01 PM, Bjorn Helgaas <helgaas@...nel.org> wrote:
>> > On Tue, Jun 26, 2018 at 12:06:01PM +0200, Rafael J. Wysocki wrote:
>> >> From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
>
>> >> +     /*
>> >> +      * In some cases (eg. Samsung 305V4A) leaving a bridge in suspend
>> >> +      * confuses the platform firmware, so avoid doing that, unless the
>> >> +      * bridge has a driver that should take care of PM handling.
>> >> +      */
>> >> +     if (pci_is_bridge(dev) && !dev->driver)
>> >> +             return true;
>> >
>> > It sounds like the question of whether leaving a bridge in D3 confuses
>> > the firmware has a platform-specific answer.
>>
>> Well, it may confuse the platform firmware in general.
>>
>> > How does the driver PM handling know how to do the right thing?
>>
>> For endpoints this is not an issue as they always have been expected
>> to be in D3 before passing control to the platform firmware on S3
>> entry, but we've never done that for bridges by default, except for
>> PCIe ports with PM enabled (in which case the driver decides whether
>> or not to enable it).
>
> If there's any spec reference for the expected power states of devices
> when entering S3, that would be useful here.  I can't tell if there's
> any guidance for this or if it's just figured out experimentally.

It is not direct, but Section 16.1.6 of ACPI 6.2 says this in step 4
of the system suspend outline:

OSPM places all device drivers into their respective Dx state. If the
device is enabled for wake,
it enters the Dx state associated with the wake capability. If the
device is not enabled to wake
the system, it enters the D3 state.