From: Lukas Wunner <lukas@wunner.de>
To: Michal Szpakowski <michi.szpakowski@gmail.com>,
Jordan Brough <jordan@brough.org>
Cc: linux-hwmon@vger.kernel.org, Henrik Rydberg <rydberg@bitmath.org>,
Guenter Roeck <linux@roeck-us.net>,
Jean Delvare <jdelvare@suse.com>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] hwmon: (applesmc) Expose the SMC battery charge limit
Date: Thu, 24 Sep 2026 09:58:08 +0200 [thread overview]
Message-ID: <arTYEAnYYyDFsmc4@wunner.de> (raw)
In-Reply-To: <20260923144117.295450-1-michi.szpakowski@gmail.com>
[+cc Jordan]
On Wed, Sep 23, 2026 at 04:41:17PM +0200, Michal Szpakowski wrote:
> Intel Macs keep a battery charge limit inside the SMC, in the key BCLM
> (one byte, percent). The SMC enforces it on its own: charging stops at
> the limit and the value survives reboots and operating systems, so the
> only thing an OS has to do is write it. On macOS the tool "bclm" does
> that; on Linux there has been no way, because applesmc exposes keys
> read-only through key_at_index.
>
> Expose it as the standard charge_control_end_threshold property on the
> battery through a power supply extension, so UPower and the desktops
> that read that property pick it up without knowing anything about
> Apple. The battery of an Intel Mac is an ACPI Smart Battery handled by
> the sbs driver, which the ACPI battery hooks do not cover, so the
> supply is found by walking the registered supplies; should it register
> after applesmc, its first property-change notification attaches the
> extension. Nothing happens on machines whose SMC lacks the key. Writes
> are read back, because the SMC silently drops values it does not
> accept; 100 disables the cap.
>
> Tested on a MacBookPro13,1 (2016, 13", no Touch Bar): with the limit at
> 80 and the charger attached, charging ran at a steady 1.55 A and stopped
> at 79% of charge_full with status "Full" and current 0, and the limit
> read back 80 after a reboot.
Jordan Brough is working on similar patches, perhaps you two can
work together to make sure there's no breakage on either of your
laptops an no conflict between your patches:
https://lore.kernel.org/r/20260918175052.85461-1-jordan@brough.org
Thanks,
Lukas
next prev parent reply other threads:[~2026-09-24 7:58 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 14:41 [PATCH] hwmon: (applesmc) Expose the SMC battery charge limit Michal Szpakowski
2026-09-24 7:58 ` Lukas Wunner [this message]
2026-09-24 9:45 ` Michal Szpakowski
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=arTYEAnYYyDFsmc4@wunner.de \
--to=lukas@wunner.de \
--cc=jdelvare@suse.com \
--cc=jordan@brough.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-hwmon@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=michi.szpakowski@gmail.com \
--cc=rydberg@bitmath.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.