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

[Michal Szpakowski <michi.szpakowski@gmail.com>]

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@brough.org

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