linux-kernel - Re: rtsx_pci not restoring ASPM state after suspend/resume

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: <aaa64572fac0fc411b79a9adb59b5bbcbdf4b1a8.camel@ettle.org.uk>
Date:   Sat, 25 Jul 2020 21:27:11 +0100
From:   James Ettle <james@...le.org.uk>
To:     Bjorn Helgaas <helgaas@...nel.org>,
        吳昊澄 Ricky 
        <ricky_wu@...ltek.com>
Cc:     Rui Feng <rui_feng@...lsil.com.cn>, Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Len Brown <lenb@...nel.org>,
        Puranjay Mohan <puranjay12@...il.com>,
        "linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Jacopo De Simoi <wilderkde@...il.com>
Subject: Re: rtsx_pci not restoring ASPM state after suspend/resume

On Fri, 2020-07-24 at 18:13 -0500, Bjorn Helgaas wrote:
> 
> Maybe we should simplify this a little bit more.  James, if you don't
> touch ASPM config at all, either manually or via udev, does the ASPM
> configuration stay the same across suspend/resume?
> 

Yes, it stays the same. Explicitly: 

With the udev rule disabled, immediately following clean boot from
power-off (and no additional tinkering), ASPM is OFF to the best of my
knowledge:

 - link/l1_aspm in sysfs is 0 for PCI devices 0000:01:00.[01];
 - the processor sleeps no deeper than package C3.

The situation above is the same following a suspend/resume cycle --
both in terms of sysfs, and observed package C-state occupancy.

[Tested on kernel 5.7.10, but the behaviour is the same as prior
kernels.]

Thanks,
James.