linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "David E. Box" <david.e.box@linux.intel.com>
To: Hans de Goede <hdegoede@redhat.com>,
	Sven van Ashbrook <svenva@chromium.org>,
	LKML <linux-kernel@vger.kernel.org>
Cc: platform-driver-x86@vger.kernel.org,
	Rajneesh Bhardwaj <rajneesh.bhardwaj@intel.com>,
	Rafael J Wysocki <rjw@rjwysocki.net>,
	Rajat Jain <rajatja@google.com>,
	David E Box <david.e.box@intel.com>,
	Mark Gross <markgross@kernel.org>,
	Rajneesh Bhardwaj <irenic.rajneesh@gmail.com>
Subject: Re: [PATCH v1] platform/x86: intel_pmc_core: promote S0ix failure warn() to WARN()
Date: Thu, 27 Oct 2022 09:37:45 -0700	[thread overview]
Message-ID: <9b49ea5aeb6c54fd86bf3c02668bf21dd880fd12.camel@linux.intel.com> (raw)
In-Reply-To: <4b7304c0-8dd5-9add-7c84-4e9f0aa9396b@redhat.com>

On Thu, 2022-10-27 at 17:40 +0200, Hans de Goede wrote:
> Hi,
> 
> On 10/27/22 17:19, Sven van Ashbrook wrote:
> > The "failure to enter S0ix" warning is critically important for monitoring
> > and debugging power regressions, both in the field and in the test lab.
> > 
> > Promote from lower-case warn() to upper-case WARN() so that it becomes
> > more prominent, and gets picked up as part of existing monitoring
> > infrastructure, which typically focuses on WARN() and ignores warn()
> > type log messages.
> > 
> > Signed-off-by: Sven van Ashbrook <svenva@chromium.org>
> 
> WARN() is really only intended for internal kernel bugs and not for
> hw misbehaving, so I'm not a fan of the change you are suggesting here.
> 
> Intel folks, do you have an opinion on this ?

I agree that not entering s0ix is a critical failure, but this is a hardware
suspend failure. How we treat this should be akin to how we treat failure to
enter S3 or deeper. S0ix support is indicated by the S0 Low Power Idle bit in
the ACPI FADT table. It's better IMO to create some framework in the suspend or
ACPI core that allows platforms to report whether they have achieved the
hardware state indicated by having this bit set. Rafael, your thoughts?

David

> 
> Regards,
> 
> Hans
> 
> 
> > ---
> > Against v6.1-rc2
> > 
> >  drivers/platform/x86/intel/pmc/core.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/platform/x86/intel/pmc/core.c
> > b/drivers/platform/x86/intel/pmc/core.c
> > index a1fe1e0dcf4a5..834f0352c0edf 100644
> > --- a/drivers/platform/x86/intel/pmc/core.c
> > +++ b/drivers/platform/x86/intel/pmc/core.c
> > @@ -2125,7 +2125,7 @@ static __maybe_unused int pmc_core_resume(struct
> > device *dev)
> >         }
> >  
> >         /* The real interesting case - S0ix failed - lets ask PMC why. */
> > -       dev_warn(dev, "CPU did not enter SLP_S0!!! (S0ix cnt=%llu)\n",
> > +       dev_WARN(dev, "CPU did not enter SLP_S0!!! (S0ix cnt=%llu)\n",
> >                  pmcdev->s0ix_counter);
> >         if (pmcdev->map->slps0_dbg_maps)
> >                 pmc_core_slps0_display(pmcdev, dev, NULL);
> 


      parent reply	other threads:[~2022-10-27 16:37 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-27 15:19 [PATCH v1] platform/x86: intel_pmc_core: promote S0ix failure warn() to WARN() Sven van Ashbrook
2022-10-27 15:40 ` Hans de Goede
2022-10-27 15:47   ` Limonciello, Mario
2022-10-27 15:51     ` Sven van Ashbrook
     [not found]       ` <CAE2upjS6qRGRcuVYuAB5DMf66A7VcfCKKYEkpsr1My7RnKDFtQ@mail.gmail.com>
2022-10-29  4:11         ` Sven van Ashbrook
2022-10-31 19:39           ` Limonciello, Mario
2022-10-31 20:15             ` Hans de Goede
2022-10-31 20:20               ` Sven van Ashbrook
     [not found]             ` <CACK8Z6E7=xt118d47FTpmgKHgUBgH48FQzTi5iL90C3MjHb-3Q@mail.gmail.com>
2022-10-31 20:55               ` Limonciello, Mario
2022-11-01 17:24                 ` Sven van Ashbrook
2022-11-01 20:30                   ` David E. Box
2022-11-01  1:38             ` Sven van Ashbrook
2022-11-01  1:58               ` Mario Limonciello
2022-11-01 13:50                 ` Sven van Ashbrook
2022-10-27 16:37   ` David E. Box [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9b49ea5aeb6c54fd86bf3c02668bf21dd880fd12.camel@linux.intel.com \
    --to=david.e.box@linux.intel.com \
    --cc=david.e.box@intel.com \
    --cc=hdegoede@redhat.com \
    --cc=irenic.rajneesh@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=markgross@kernel.org \
    --cc=platform-driver-x86@vger.kernel.org \
    --cc=rajatja@google.com \
    --cc=rajneesh.bhardwaj@intel.com \
    --cc=rjw@rjwysocki.net \
    --cc=svenva@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).