Re: [PATCH] hwmon: (applesmc) Expose the SMC battery charge limit

From: Michal Szpakowski

Date: Thu Sep 24 2026 - 05:49:45 EST


On Thu, Sep 24, 2026 at 09:58:10AM +0200, Lukas Wunner wrote:
> 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@xxxxxxxxxx

Thanks, I had missed that series. Jordan's approach is the better one:
extending the battery hooks to SBS batteries is the proper fix for the
problem I worked around by walking the supplies, and the BFCL/LED
handling covers hardware I do not have. Please consider my patch
withdrawn in favour of his; I am happy to test v3 and add a Tested-by.

Two things from a MacBookPro13,1 (2016, 13", USB-C, no MagSafe) that
may be useful for it, Jordan:

1. This SMC has no BFCL key at all. A dump of all 798 keys has BCLM
but no BFCL (the BF* keys here are BFCT, BFLO and BFWC), and asking
the driver directly, through a debug attribute that calls
applesmc_get_entry_by_key():

BFCL (no such key)
BCLM type=ui8 len=1 flags=0xd0 R W

With v2's set_property, the unconditional applesmc_write_key(BFCL)
after the BCLM write therefore fails with -EINVAL, so userspace gets
an error although the limit was in fact applied. Gating the LED
write on applesmc_has_key(BFCL) at init, like the BCLM check, would
fix that.

2. The SMC silently drops writes it does not like: applesmc_write_key()
returns 0 and the key keeps its old value (seen on this machine with
the CLWK key; BCLM accepted everything I tried between 50 and 100).
Reading BCLM back after the write and returning -EINVAL on a
mismatch costs one read and makes the failure visible.

For what it is worth, BCLM=80 on this machine stops charging at 79% of
charge_full with status "Full", the value survives reboots, and UPower
1.91 picks the property up as charge-end-threshold once it re-reads the
battery.

Michal