public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Max Asbock <masbock@lenovo.com>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Chris McDermott <lcm@lenovo.com>
Subject: Re: [Patch] acpi_power_meter: remove 'ignoring unsafe software power cap' message
Date: Fri, 7 Sep 2018 16:32:02 -0700	[thread overview]
Message-ID: <20180907233201.GA4635@magnolia> (raw)
In-Reply-To: <TY2PR03MB3519C32A5BC640BA41356CBEDE000@TY2PR03MB3519.apcprd03.prod.outlook.com>

On Fri, Sep 07, 2018 at 10:07:39PM +0000, Max Asbock wrote:
> At boot time the acpi_power_meter driver greets users of non-IBM systems with the message: 
> 	
> "Ignoring unsafe software power cap". 
> 
> This message is generally interpreted as meaning: The system is
> operating under an unsafe power  cap and Linux is ignoring this fact,
> thus living dangerously. It, or its presumed origin, has been blamed
> for system crashes. People spent time writing knowledge base articles
> which explain that the message doesn't mean what users think. I now
> have to write another such article telling people to ignore this
> message. To avoid future confusion and unnecessary work, I think the
> best solution is to remove the message. 
> 
> Here is my translation of the 'ignoring unsafe power cap' message:
>
> 'The acpi_power_meter driver discovered an ACPI object that would in
> theory allow software to set power caps. The driver could now create
> files in sysfs to expose this interface to user space, but it chooses
> not to do so'.

TBH that driver safelists the (single) system that is known to have a
working power capping mechanism.  At the time (ten years ago) the AEM
group worried that other vendors would produce ACPI power meters which
advertised the capping ability but did not enforce the limit, hence the
safelist.  I asked "Well can't we just trust vendor firmware?" and peals
of laughter erupted on the phone. ;)

If the user confusion is that Lenovo systems have ACPI power meters with
working power capping, you could consider adding Lenovo to the safelist.

That said, the message is misleading.  It probably should have read:

"Power capping has not been verified to work on this platform.
Please ask the platform vendor email X to have it added to the list."

Alternately, you could remove the safelisting entirely and assume that
if the firmware is malicious there are far more evil things it will try.
Seeing as IBM AEM is a decade old I doubt it's protecting much now.

But /me shrugs and says, "eh, good enough".  Also, nice to hear from you
& lcm again. :)

Reviewed-by: Darrick J. Wong <darrick.wong@oracle.com>

--D

> 
> Patch: Remove error message because it is generally misinterpreted. A replacement
> for the message is not necessary.
> 
> Signed-off-by: Max Asbock <masbock@lenovo.com>
> 
> diff --git a/drivers/hwmon/acpi_power_meter.c b/drivers/hwmon/acpi_power_meter.c
> index 34e45b9..578e886 100644
> --- a/drivers/hwmon/acpi_power_meter.c
> +++ b/drivers/hwmon/acpi_power_meter.c
> @@ -693,11 +693,8 @@ static int setup_attrs(struct acpi_power_meter_resource *resource)
>  	}
>  
>  	if (resource->caps.flags & POWER_METER_CAN_CAP) {
> -		if (!can_cap_in_hardware()) {
> -			dev_err(&resource->acpi_dev->dev,
> -				"Ignoring unsafe software power cap!\n");
> +		if (!can_cap_in_hardware())
>  			goto skip_unsafe_cap;
> -		}
>  
>  		if (resource->caps.configurable_cap)
>  			res = register_attrs(resource, rw_cap_attrs);
> 
> 
> 

      reply	other threads:[~2018-09-07 23:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-09-07 22:07 [Patch] acpi_power_meter: remove 'ignoring unsafe software power cap' message Max Asbock
2018-09-07 23:32 ` Darrick J. Wong [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=20180907233201.GA4635@magnolia \
    --to=darrick.wong@oracle.com \
    --cc=lcm@lenovo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masbock@lenovo.com \
    /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