Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.37 as permitted sender) client-ip=23.128.96.37;
MIME-Version: 1.0
References: <20231004183455.27797-1-ville.syrjala@linux.intel.com>
 <6d207eef73fb2ad32264921ae7d1a536b6b8da61.camel@intel.com>
 <ZR22I-9YgGW9vADB@intel.com> <ZTf6qwCLR3YEwL9K@intel.com> <CAJZ5v0jzqZBHqh8dxChwJ65wT-pU3+9HxVi5f7DAcOTFpYTb9Q@mail.gmail.com>
 <ZTgRhFbp5wdsTa5W@intel.com>
In-Reply-To: <ZTgRhFbp5wdsTa5W@intel.com>
From:   "Rafael J. Wysocki" <rafael@kernel.org>
Date:   Tue, 24 Oct 2023 20:52:36 +0200
Message-ID: <CAJZ5v0hBdPJB_BL9ux0NDUZQfOBddP7w3mcAO-AUGPnosA+Jhg@mail.gmail.com>
Subject: Re: [Intel-gfx] [PATCH] powercap: intel_rapl: Don't warn about BIOS
 locked limits during resume
To:     =?UTF-8?B?VmlsbGUgU3lyasOkbMOk?= <ville.syrjala@linux.intel.com>
Cc:     "Rafael J. Wysocki" <rafael@kernel.org>,
        "Pandruvada, Srinivas" <srinivas.pandruvada@intel.com>,
        "linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
        "intel-gfx@lists.freedesktop.org" <intel-gfx@lists.freedesktop.org>,
        "Wysocki, Rafael J" <rafael.j.wysocki@intel.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        "Zhang, Rui" <rui.zhang@intel.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8BIT
Precedence: bulk

On Tue, Oct 24, 2023 at 8:48 PM Ville Syrjälä
<ville.syrjala@linux.intel.com> wrote:
>
> On Tue, Oct 24, 2023 at 08:31:34PM +0200, Rafael J. Wysocki wrote:
> > On Tue, Oct 24, 2023 at 7:11 PM Ville Syrjälä
> > <ville.syrjala@linux.intel.com> wrote:
> > >
> > > On Wed, Oct 04, 2023 at 09:59:47PM +0300, Ville Syrjälä wrote:
> > > > On Wed, Oct 04, 2023 at 06:45:22PM +0000, Pandruvada, Srinivas wrote:
> > > > > On Wed, 2023-10-04 at 21:34 +0300, Ville Syrjala wrote:
> > > > > > From: Ville Syrjälä <ville.syrjala@linux.intel.com>
> > > > > >
> > > > > > Restore enough of the original behaviour to stop spamming
> > > > > > dmesg with warnings about BIOS locked limits when trying
> > > > > > to restore them during resume.
> > > > > >
> > > > > > This still doesn't 100% match the original behaviour
> > > > > > as we no longer attempt to blindly restore the BIOS locked
> > > > > > limits. No idea if that makes any difference in practice.
> > > > > >
> > > > > I lost the context here. Why can't we simply change pr_warn to pr_debug
> > > > > here?
> > > >
> > > > I presume someone wanted to make it pr_warn() for a reason.
> > > > I don't mind either way.
> > >
> > > Ping. Can someone make a decision on how this should get fixed
> > > so we get this moving forward?
> >
> > I thought we were going to replace the pr_warn() with pr_debug().
>
> I didn't get any answer whether anyone wants to keep the pr_warn().
> If everyone is happy with pr_debug() that then I can send a patch
> for it.

Yes, please.