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]

Date:   Tue, 26 Jun 2018 15:32:14 -0500
From:   Bjorn Helgaas <helgaas@...nel.org>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     "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 07:19:29PM +0200, Rafael J. Wysocki wrote:
> 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.

Thanks, that's a very useful citation!

Bjorn