Linux ACPI
 help / color / mirror / Atom feed
From: Hans de Goede <hansg@kernel.org>
To: Peter Marheine <pmarheine@chromium.org>
Cc: Matthew Schwartz <matthew.schwartz@linux.dev>,
	Sebastian Reichel <sre@kernel.org>,
	regressions@lists.linux.dev, stable@vger.kernel.org,
	rafael.j.wysocki@intel.com, linux-acpi@vger.kernel.org
Subject: Re: [REGRESSION] - Multiple userspace implementations of battery estimate broken after "ACPI: battery: negate current when discharging"
Date: Fri, 4 Jul 2025 10:47:45 +0200	[thread overview]
Message-ID: <cd6a9d6a-d995-47c0-b474-14440c40503f@kernel.org> (raw)
In-Reply-To: <CAG_X_pC0jTe5fuNaK81veif-p9JeJyYpgb2E2R_RXBzfcj4_MQ@mail.gmail.com>

Hi Peter,

On 4-Jul-25 6:56 AM, Peter Marheine wrote:
> I'm not surprised that there exist a number of userspace programs that
> assume the buggy ACPI battery behavior is the only one, but this does
> leave us in the previous situation where there's a clear bug in the
> ACPI driver.
> 
>> But, the patch was actually doing the right thing, according to:
>>
>> Documentation/ABI/testing/sysfs-class-power
> 
> This is the key issue, since it's entirely plausible for a program
> assuming non-negative battery current to run on a non-ACPI platform
> and misbehave in the same way. If we're not going to fix the ACPI
> driver to behave as specified for the kernel ABI, then the ABI needs
> to be redefined to reflect the actual behavior. It's either that or we
> give userspace an opportunity to fix itself (and I'm not sure exactly
> how that would be done such that the clients which need to be fixed
> discover that they need to be) and correct the driver's behavior
> later.

Right, this is why I asked for bugs to be filed against the problematic
userspace programs, so that we can try to fix the ACPI driver again in
say 1 or 2 years from now.

In the mean time you could submit a patch to document the known broken
behavior of the ACPI battery driver in:

Documentation/ABI/testing/sysfs-class-power

with a big warning that userspace should not rely on this behavior.

You could even document how to work around this, e.g.:

"Negative currents are always discharging. Because of the broken ACPI
battery driver behaviour positive currents should be seen as discharging
rather then charging when the "status" sysfs attribute reports discharging."

Regards,

Hans



      reply	other threads:[~2025-07-04  8:47 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-03  1:54 [REGRESSION] - Multiple userspace implementations of battery estimate broken after "ACPI: battery: negate current when discharging" Matthew Schwartz
2025-07-03 10:58 ` Rafael J. Wysocki
2025-07-03 14:47 ` Hans de Goede
2025-07-03 15:51   ` Matthew Schwartz
2025-07-06 22:27     ` Sebastian Reichel
2025-07-04  4:56   ` Peter Marheine
2025-07-04  8:47     ` Hans de Goede [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=cd6a9d6a-d995-47c0-b474-14440c40503f@kernel.org \
    --to=hansg@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=matthew.schwartz@linux.dev \
    --cc=pmarheine@chromium.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=regressions@lists.linux.dev \
    --cc=sre@kernel.org \
    --cc=stable@vger.kernel.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