linux-kernel - RE: [PATCH] intel: thermal: PCH: Drop ACPI_FADT_LOW_POWER

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] [day] [month] [year] [list]

Message-ID: <65fe502db8174defba0f21958499cab0@intel.com>
Date:   Fri, 22 Jul 2022 02:59:53 +0000
From:   "Zhang, Rui" <rui.zhang@...el.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
CC:     "Rafael J. Wysocki" <rjw@...ysocki.net>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux ACPI <linux-acpi@...r.kernel.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Mario Limonciello <mario.limonciello@....com>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
Subject: RE: [PATCH] intel: thermal: PCH: Drop ACPI_FADT_LOW_POWER_S0 check



> -----Original Message-----
> From: Rafael J. Wysocki <rafael@...nel.org>
> Sent: Monday, July 18, 2022 3:39 AM
> To: Zhang, Rui <rui.zhang@...el.com>
> Cc: Rafael J. Wysocki <rjw@...ysocki.net>; Linux PM <linux-
> pm@...r.kernel.org>; Linux ACPI <linux-acpi@...r.kernel.org>; LKML <linux-
> kernel@...r.kernel.org>; Mario Limonciello <mario.limonciello@....com>;
> Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>
> Subject: Re: [PATCH] intel: thermal: PCH: Drop ACPI_FADT_LOW_POWER_S0
> check
> Importance: High
> 
> On Sun, Jul 17, 2022 at 8:14 AM Zhang Rui <rui.zhang@...el.com> wrote:
> >
> > On Thu, 2022-07-14 at 21:11 +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > >
> > > If ACPI_FADT_LOW_POWER_S0 is not set, this doesn't mean that low-
> > > power
> > > S0 idle is not usable.  It merely means that using S3 on the given
> > > system is more beneficial from the energy saving perspective than
> > > using low-power S0 idle, as long as S3 is supported.
> >
> > Agreed.
> >
> > >
> > > Suspend-to-idle is still a valid suspend mode if
> > > ACPI_FADT_LOW_POWER_S0
> > > is not set and the pm_suspend_via_firmware() check in
> > > pch_wpt_suspend()
> > > is sufficient to distinguish suspend-to-idle from S3, so drop the
> > > confusing ACPI_FADT_LOW_POWER_S0 check.
> >
> > the cooling delay in the suspend callback is to make sure PCH
> > temperature won't block S0ix during s2idle. So if S0ix is not
> > supported, it is meaningless to invoke the cooling delay during s2idle.
> 
> But there is no way to determine whether or not S0ix is supported.  In
> particular, ACPI_FADT_LOW_POWER_S0 is not one.
> 
> > so the problem is that we don't have an indicator for S0ix capability.
> > And this also applies to drivers/rtc/rtc-cmos.c, where we use ACPI SCI
> > for runtime RTC wakeup instead of HPET interrupt on "S0ix capable"
> > platforms because the HPET timer may block S0ix.
> 
> "S0ix capable" doesn't matter.  What matters is whether or not the current
> transition under way is into S0 or into suspend-to-idle.  In the latter case
> there is no reason to avoid doing whatever is done in the expectation that
> S0ix may be entered going forward.

Okay. It is not perfect but we have to live with this.

Acked-by: Zhang Rui <rui.zhang@...el.com>