linux-kernel - Re: [PATCH V2 1/2] PCI: Add ACPI StorageD3Enable

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: <e980bc2959b5a959bddfa63adb35aeae8261ab06.camel@linux.intel.com>
Date:   Wed, 24 Jun 2020 15:09:33 -0700
From:   "David E. Box" <david.e.box@...ux.intel.com>
To:     Bjorn Helgaas <helgaas@...nel.org>
Cc:     shyjumon.n@...el.com, rjw@...ysocki.net, lenb@...nel.org,
        bhelgaas@...gle.com, dan.j.williams@...el.com, kbusch@...nel.org,
        axboe@...com, hch@....de, sagi@...mberg.me,
        linux-acpi@...r.kernel.org, linux-nvme@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org
Subject: Re: [PATCH V2 1/2] PCI: Add ACPI StorageD3Enable _DSD support

On Wed, 2020-06-24 at 16:37 -0500, Bjorn Helgaas wrote:
> On Fri, Jun 12, 2020 at 01:48:19PM -0700, David E. Box wrote:
> > StorageD3Enable is a boolean property that indicates that the
> > platform
> > wants to use D3 for PCIe storage drives during suspend-to-idle. 
> 
> Is this something that should apply to plug-in drives, or does this
> only apply to soldered-in things?
> 
> > It is a
> > BIOS work around that is currently in use on shipping systems like
> > some
> > Intel Comet Lake platforms. 
> 
> What is this BIOS work around?  Is there a defect here that's being
> worked around?  What's the defect?

> 
> > It is meant to change default driver policy for
> > suspend that may cause higher power consumption.
> 
> I guess this means that by changing the driver policy from the
> default, we can save some power?

Yes. Maybe 'work around' was a poor choice of words. 'Getting around
default driver policy' is the issue. There is no hardware defect. One
of the uses of the suspend-to-idle flow is to support compliance with
increasingly tighter energy regulations. One of the ways to do this on
desktop systems is to power off the ATX power supply during s2idle and
use the 5V standby rail for self refresh and other low power needs. But
the platforms that support this can't shutdown the PS unless PCI ports
are placed in D3. On Linux this won't happen with NVMe drives because
the default driver policy is to use ASPM (NVMe APST) during s2idle.
Windows has a related concern. So to 'get around' the driver choosing a
policy that will result in higher power consumption, they implemented
this _DSD to inform the OS of its preference for D3 on the PCI port.

David