macsmc-battery: charge_now/energy_now reported at inconsistent scale (under & over); capacity intermittently stuck at 100%

[Alarisco]

macsmc-battery: charge_now/energy_now reported at inconsistent scale (both under and over); capacity intermittently stuck at 100%

Summary

The macsmc-battery power supply driver reports charge_now and energy_now at an inconsistent, time-varying scale relative to charge_full/energy_full. The same *_now pair is, within each sample, scaled by an identical factor, but that factor changes over time and has been observed ranging from ~0.4x to ~10x the physically-correct value. As a result:

• Any percentage computed as now/full is wrong, in both directions (under- and over-reporting).
• The dedicated POWER_SUPPLY_CAPACITY attribute (sourced from a separate fuel-gauge register, not computed from now/full) is closer to reality but is intermittently stuck at 100 even when the battery is not full.

The actual battery level is ~95-96% (confirmed by the user; corroborated by time_to_empty_now). Userspace that follows capacity/upower percentage therefore sees either a stuck 100% or a briefly correct ~95%, while anything that computes from charge_now/energy_now sees garbage (e.g. 54%, 69%, 39%, 652%, 1073%). Low-battery alerts never fire while capacity is stuck at 100.

Hardware / Environment

• Device: Apple MacBook Pro (14-inch, M1 Pro, 2021) — apple,j314s, apple,t6000
• Battery: bq40z651, serial F8Y13660648Q1LT61, 861 charge cycles, health: Good
• Design capacity: charge_full_design=6,075,000 µAh / energy_full_design=69,255,000 µWh (~69.3 Wh)
• Actual full capacity (learned): charge_full≈5,225,000 µAh / energy_full≈59,565,000 µWh (~59.6 Wh) → ~86% health (consistent with 861 cycles). These *_full values are stable and correct.
• System firmware: unknown v1.5.2 (m1n1 stage2)
• OS: Arch Linux ARM (asahi-alarm repo)
• Kernel: 7.0.13.asahi1-1 (linux-asahi package, 7.0.13-1-1-ARCH, aarch64) — this is the latest available in the repo; updating does not fix it.
• upower: 1.91.2-1
• Kernel cmdline: BOOT_IMAGE=/boot/vmlinuz-linux-asahi root=UUID=... rw loglevel=3 quiet splash appledrm.show_notch=1

Key observation: capacity is independent of now/full

Across all samples, POWER_SUPPLY_CAPACITY cannot be derived from charge_now/charge_full or energy_now/energy_full by simple division — e.g. charge_now=3,603,000 / charge_full=5,225,000 = 69%, yet capacity=95. This confirms the driver populates capacity from a separate fuel-gauge source. The *_now fields and the capacity field are independently (and differently) broken.

Reproduction 1 — charge_now/energy_now under-reporting while capacity is correct (battery ~95-96%, discharging)

1-second interval, battery discharging, actual level ~95-96%:

cap=95  raw=69.4%  charge_now=3603000  energy_now=41074200  tte=23100s  power_now=-7519000uW
cap=95  raw=69.4%  charge_now=3603000  energy_now=41074200  tte=23280s  power_now=-8699000uW
cap=95  raw=69.4%  charge_now=3603000  energy_now=41074200  tte=23280s  power_now=-9355000uW
cap=95  raw=69.4%  charge_now=3603000  energy_now=41074200  tte=23280s  power_now=-9320000uW
cap=95  raw=64.5%  charge_now=3347000  energy_now=38155800  tte=23280s  power_now=-9321000uW
cap=95  raw=64.5%  charge_now=3347000  energy_now=38155800  tte=23280s  power_now=-9454000uW
cap=95  raw=64.5%  charge_now=3347000  energy_now=38155800  tte=23280s  power_now=-9417000uW
cap=95  raw=64.5%  charge_now=3347000  energy_now=38155800  tte=23280s  power_now=-9530000uW
cap=95  raw=59.5%  charge_now=3091000  energy_now=35237400  tte=23220s  power_now=-9469000uW
cap=95  raw=59.5%  charge_now=3091000  energy_now=35237400  tte=23220s  power_now=-9368000uW
cap=95  raw=59.5%  charge_now=3091000  energy_now=35237400  tte=23160s  power_now=-9505000uW
cap=95  raw=59.5%  charge_now=3091000  energy_now=35237400  tte=23160s  power_now=-9321000uW
cap=95  raw=59.5%  charge_now=3091000  energy_now=35237400  tte=23220s  power_now=-9357000uW
cap=95  raw=54.6%  charge_now=2835000  energy_now=32319000  tte=23220s  power_now=-9367000uW
cap=95  raw=54.6%  charge_now=2835000  energy_now=32319000  tte=23220s  power_now=-9231000uW

Here charge_now decreases smoothly (3,603,000 → 2,835,000) but reads ~54-69% of charge_full, while capacity=95 and time_to_empty_now≈23,200s (6.4 h). At ~9.4 W, 6.4 h implies ~56-61 Wh remaining ≈ 95-102% of energy_full — consistent with capacity=95 and the user-reported ~96%, and inconsistent with the charge_now-derived 54-69%. So here charge_now/energy_now are under-reporting by ~0.5-0.7x while capacity is correct.

Reproduction 2 — charge_now/energy_now over-reporting and capacity stuck at 100 (battery actually ~96%, discharging)

1-second interval, same session, a few minutes earlier (still discharging, actual level still ~96%):

t=1  status=Discharging  capacity=100  charge_now=34067000 charge_full=5225000 (raw 652.0%)  energy_now=388363800 energy_full=59565000
t=2  status=Discharging  capacity=100  charge_now=34067000 charge_full=5225000 (raw 652.0%)  energy_now=388363800 energy_full=59565000
t=3  status=Discharging  capacity=100  charge_now=33811000 charge_full=5225000 (raw 647.1%)  energy_now=385445400 energy_full=59565000
t=4  status=Discharging  capacity=100  charge_now=33811000 charge_full=5225000 (raw 647.1%)  energy_now=385445400 energy_full=59565000
t=5  status=Discharging  capacity=100  charge_now=33811000 charge_full=5225000 (raw 647.1%)  energy_now=385445400 energy_full=59565000
t=6  status=Discharging  capacity=100  charge_now=33811000 charge_full=5225000 (raw 647.1%)  energy_now=385445400 energy_full=59565000
t=7  status=Discharging  capacity=100  charge_now=33555000 charge_full=5225000 (raw 642.2%)  energy_now=382527000 energy_full=59565000
t=8  status=Discharging  capacity=100  charge_now=33555000 charge_full=5225000 (raw 642.2%)  energy_now=382527000 energy_full=59565000
t=9  status=Discharging  capacity=100  charge_now=33555000 charge_full=5225000 (raw 642.2%)  energy_now=382527000 energy_full=59565000
t=10 status=Discharging  capacity=100  charge_now=33555000 charge_full=5225000 (raw 642.2%)  energy_now=382527000 energy_full=59565000

Here charge_now/charge_full = 652% (over-reporting by ~6.5x; also seen at ~10x: 55,827,000/5,202,000 = 1073%), and capacity is stuck at 100 despite the battery being at ~96%. upower exposes this as percentage: 100%, energy: 639.346 Wh, time to empty: 3.4 days — all absurd for a 69 Wh-design battery.

Reproduction 3 — charge_now/energy_now briefly under-report at ~0.4x

A one-off reading captured during the same discharge:

charge_now=2,068,000  charge_full=5,234,000  -> 39.5%
energy_now=23,575,200 energy_full=59,667,600 -> 39.5%

charge_now and energy_now are internally consistent with each other (both 39.5%) but inconsistent with reality (~96%) and with time_to_empty_now. This is an under-reporting outlier at ~0.4x, not the true state.

Summary of observed *_now scale factors vs. physically-correct value

Observed reading	charge_now/charge_full	Inferred scale vs. true (~96%)
2,068,000 / 5,234,000	39.5%	~0.4x (under)
2,835,000 / 5,225,000	54.6%	~0.6x (under)
3,603,000 / 5,225,000	69.4%	~0.7x (under)
34,067,000 / 5,225,000	652%	~6.5x (over)
55,827,000 / 5,202,000	1073%	~10x (over)

Within each sample, charge_now and energy_now are scaled by the same factor; the *_full values are stable and correct.

capacity behavior

• Sourced independently from now/full (see "Key observation").
• Intermittently stuck at 100 even when the battery is at ~96% (Reproduction 2). When stuck, low-battery alerts never fire (safety/usability concern: unexpected shutdowns).
• At other times reports a value consistent with reality and time_to_empty_now (Reproduction 1: capacity=95).

upower -d excerpt (captured during an over-reporting + stuck-capacity window)

Device: /org/freedesktop/UPower/devices/battery_macsmc_battery
  native-path:          macsmc-battery
  model:                bq40z651
  state:                discharging
  energy:              639.346 Wh          <-- absurd (from inflated *_now)
  energy-full:         639.346 Wh          <-- equals "energy" because now>=full
  energy-full-design:  69.255 Wh
  voltage:             12.535 V
  energy-rate:         7.871 W
  charge-cycles:       861
  percentage:          100%
  capacity:            100%                <-- health also misreported (should be ~86%)
  time to empty:       3.4 days            <-- derived from inflated energy
  charge-start-threshold:        75%
  charge-end-threshold:          80%

Note: upower's capacity (health) is also wrong here (100% instead of ~86% = 59.5/69.3), suggesting energy_full is also occasionally inflated when upower samples it (sysfs polling showed energy_full stable at 59.5 Wh, but upower caught 639 Wh).

Full sysfs uevent (captured during a ~0.4x under-reporting window)

POWER_SUPPLY_NAME=macsmc-battery
POWER_SUPPLY_TYPE=Battery
POWER_SUPPLY_STATUS=Discharging
POWER_SUPPLY_HEALTH=Good
POWER_SUPPLY_PRESENT=1
POWER_SUPPLY_CYCLE_COUNT=861
POWER_SUPPLY_VOLTAGE_MAX=12998000
POWER_SUPPLY_VOLTAGE_MIN=8940000
POWER_SUPPLY_VOLTAGE_MAX_DESIGN=12825000
POWER_SUPPLY_VOLTAGE_MIN_DESIGN=9000000
POWER_SUPPLY_VOLTAGE_NOW=12516000
POWER_SUPPLY_CURRENT_NOW=-815000
POWER_SUPPLY_POWER_NOW=-10200000
POWER_SUPPLY_CHARGE_FULL_DESIGN=6075000
POWER_SUPPLY_CHARGE_FULL=5234000
POWER_SUPPLY_CHARGE_NOW=2068000
POWER_SUPPLY_CHARGE_COUNTER=-769574
POWER_SUPPLY_ENERGY_FULL_DESIGN=69255000
POWER_SUPPLY_ENERGY_FULL=59667600
POWER_SUPPLY_ENERGY_NOW=23575200
POWER_SUPPLY_CAPACITY=100            <-- stuck at 100 even though charge_now/charge_full = 39.5%
POWER_SUPPLY_CAPACITY_LEVEL=Normal
POWER_SUPPLY_TEMP=341
POWER_SUPPLY_TIME_TO_EMPTY_NOW=25680

Suggested investigation

• The macsmc-battery driver appears to source charge_now/energy_now from a register/field whose unit or scaling is unstable across reads (returning anything from ~0.4x to ~10x the correct value), while charge_full/energy_full are stable. Identify which SMC key/register backs *_now and whether it sometimes returns a cumulative counter, a raw ADC value, or a value in a different unit rather than instantaneous remaining charge/energy.
• POWER_SUPPLY_CAPACITY is populated independently of now/full (good) but gets stuck at 100. Worth checking whether the driver caches/clamps it and only refreshes on certain events (e.g. charge state transitions) rather than on every read.
• If helpful, I can collect: longer traces, dmesg output, readings while charging vs. discharging, or concurrent time_to_empty_now/power_now samples to triangulate the true state.
• Separately: upower's health capacity (energy_full/design) was observed as 100% when it should be ~86%; may indicate energy_full is also occasionally inflated at the moments upower samples it.

Workaround in use

None at the kernel level (the latest linux-asahi 7.0.13.asahi1-1 available in asahi-alarm is already installed and exhibits the issue). Userspace workaround under consideration: prefer POWER_SUPPLY_CAPACITY over now/full-derived percentage, and when capacity is stuck at 100 for extended periods while discharging, fall back to time_to_empty_now × power_now / energy_full to estimate the true level.

[hnasheralneam]

I'm having the same issue with the battery reporting wildly different numbers, on the latest Asahi kernel (7.0.13-400.asahi.fc44.aarch64+16k) and the Golden Gate developer beta.

[dotevie]

+1 on 7.0.13-400.asahi.fc44.aarch64+16k

also fluctuating for me, here's a upower -d

Device: /org/freedesktop/UPower/devices/battery_macsmc_battery
  native-path:          macsmc-battery
  model:                bq40z651
  serial:               F8Y2341H0DKQ1LTAG
  power supply:         yes
  updated:              Fri 03 Jul 2026 09:19:03 PM EDT (4 seconds ago)
  has history:          yes
  has statistics:       yes
  battery
    present:             yes
    rechargeable:        yes
    state:               discharging
    warning-level:       none
    energy:              659.65 Wh
    energy-empty:        0 Wh
    energy-full:         712.181 Wh
    energy-full-design:  69.255 Wh
    voltage-min-design:  9 V
    voltage-max-design:  12.825 V
    capacity-level:      Normal
    energy-rate:         11.581 W
    voltage:             11.41 V
    charge-cycles:       433
    time to empty:       57.0 hours
    percentage:          92.6239%
    temperature:         35.4 degrees C
    capacity:            100%
    charge-start-threshold:        75%
    charge-end-threshold:          80%
    charge-threshold-supported:    yes
    icon-name:          'battery-full-symbolic'
  History (charge):
    1783127943  92.624  discharging
    1783127913  95.902  discharging
    1783127883  100.000 discharging
    1783127853  3.976   discharging
  History (rate):
    1783127943  11.581  discharging
    1783127913  12.951  discharging
    1783127883  12.736  discharging
    1783127853  10.683  discharging
  History (voltage):
    1783127943  11.410  discharging
    1783127913  11.381  discharging
    1783127883  11.382  discharging
    1783127853  11.426  discharging

[r1file]

Additional independent reproduction on Fedora Asahi Remix, with a byte-order observation that may pinpoint the bug.

Environment

• Apple MacBook Pro 14-inch (2021), M1 Pro, MacBookPro18,3 / J314s
• Fedora Linux Asahi Remix 44 KDE
• Kernel 7.0.13-400.asahi.fc44.aarch64+16k
• upower 1.91.3, PowerDevil 6.7.2
• macOS 27 developer beta firmware installed
• Battery bq40z651; identifying serial omitted

60-second charging trace

The battery was charging at a stable ~2.02 A / ~25.6 W. Sysfs was sampled once per second.

sample  capacity  charge_now(uAh)  energy_now(uWh)  current_now(uA)  power_now(uW)
1       87        56848000         648067200        2023000          25669000
3       87        57104000         650985600        2024000          25684000
11      87        58128000         662659200        2022000          25663000
21      87        59664000         680169600        2023000          25686000
31      87        61200000         697680000        2022000          25677000
41      87        62480000         712272000        2022000          25685000
51      87        64016000         729782400        2022000          25693000
60      88        65296000         744374400        2023000          25710000

The apparent increase is 8,448 mAh in one minute, in discrete 256 mAh steps. A later snapshot reported charge_now=23,313,000 uAh, so the displayed value also appears to wrap.

B0RM looks byte-swapped on the new firmware

The current driver reads B0RM as u16 and applies swab16(vu16) for both CHARGE_NOW and ENERGY_NOW:

https://github.com/AsahiLinux/linux/blob/asahi/drivers/power/supply/macsmc-power.c

Undoing that swap on the values above produces physically plausible data:

driver output       as u16 hex  swap bytes back  reconstructed charge
56,848 mAh          0xde10      0x10de           4,318 mAh
65,296 mAh          0xff10      0x10ff           4,351 mAh
23,313 mAh (later)  0x5b11      0x115b           4,443 mAh

The reconstructed increase during the 60-second trace is 33 mAh. That matches the expected charge from ~2.02 A for one minute (~33.7 mAh) almost exactly. This strongly suggests that B0RM changed to normal byte order in this macOS 27 SMC firmware, while the driver still applies the old firmware's extra byte swap. It also explains the 256 mAh steps and apparent wraparound.

Stable reference fields during the trace were:

charge_full=4,998,000 uAh
charge_full_design=6,075,000 uAh
energy_full=56,977,200 uWh
energy_full_design=69,255,000 uWh

Userspace impact

upower -d captured impossible values such as:

energy:              624.72 Wh
energy-full:         709.331 Wh
energy-full-design:  69.255 Wh
energy-rate:         25.653 W
percentage:          88.0717%

Its 30-second history jumped 67.089% -> 74.083% -> 81.077% -> 88.072% while charging at ~25.6 W. PowerDevil has also interpreted a downward jump as critically low battery and shown its 60-second sleep countdown.

The kernel log additionally contains repeated messages throughout the boot:

macsmc-power macsmc-power: Emergency notification: Battery status is OK?

I collected a full asahi-diagnose report, the boot kernel journal, upower -d, and the raw 60-second sysfs trace. Identifying values (hostname, machine/boot IDs, filesystem UUIDs, and battery serial) are excluded from this comment; the full trace can be provided if useful.

[x0xt]

Independent reproduction on a different fuel gauge chip (bq20z451 instead of bq40z651).

Environment: Apple MacBook Air (2020), M1 (MacBookAir10,1). Battery: bq20z451, 197 cycles, manufactured 2021 11. Fedora Asahi Remix 44 (GNOME), kernel 7.0.13 400.asahi.fc44.aarch64+16k. macOS 27.0 Beta ("Golden Gate") installed alongside too.

Everyone else reporting this so far seems to have a bq40z651 (M1 Pro/Max). Mine's a bq20z451 on an M1 Air but I'm seeing same behavior. Since both chips are part of the same SBS fuel gauge family I'm thinking the problem is in macsmc power's handling of B0RM rather than something specific to one gauge chip, matches what r1file was seeing too in their comment above.

Here's the charge_now / charge_full ratio at a few points during one session (energy_now / energy_full showed the same ratios each time, makes sense since energy is just charge times a fixed nominal voltage):

Mid charge (about 72% actual): charge_now 46,089,000, charge_full 3,658,000, ratio 12.6x
STATUS=Full, CAPACITY=100: charge_now 24,078,000, charge_full 3,678,000, ratio 6.55x
Shortly after unplugging: charge_now 11,278,000, charge_full 3,662,000, ratio 3.08x
A few minutes later: charge_now 7,950,000, charge_full 3,668,000, ratio 2.17x

POWER_SUPPLY_CAPACITY itself stayed correct the whole time. Changed by about 1% at a time and matched TIME_TO_EMPTY_NOW / TIME_TO_FULL_NOW, so looks like the percentage is coming from a different source and still trustworthy.

Checked a couple things that I thought might explain it. I normally keep charge_control_end_threshold below 100 for battery longevity so I set it to 100 and let the battery complete a full charge cycle until STATUS changed from Charging to Full. Ratio was still 6.55x at full charge so don't think this is just gauge recalibration. Also booted into macOS, disabled Battery Health Management, rebooted back into Fedora. Behavior unchanged.

Ran into the same practical issue dotevie mentioned with PowerDevil too, the one from a few comments back. My UPower.conf uses UsePercentageForPolicy=true, PercentageAction=2.0, CriticalPowerAction=Auto. With charge_now varying by factors of 2x to 18x, seems like this could trigger an automatic hibernate or shutdown on a battery that's actually nowhere near empty, so more than just a cosmetic reporting issue I think.

One other thing I noticed while testing, probably unrelated: the udev rule that restores charge_control_end_threshold on boot (the 93 macsmc battery charge control rules one) only seems to match persisted values with exactly two digits. A saved value of 100 didn't get restored after reboot.

Same reboot, also saw the charge_control_end_threshold sysfs attribute get written around eight times within the first 14 seconds of boot. Seems separate from the regex issue and not sure yet what's doing those writes.

If it'd help I can collect a longer trace or a dmesg with additional logging enabled.

[x0xt]

Tracked this down to the fixed swab16() on the B0RM key in macsmc-power.c:

case POWER_SUPPLY_PROP_CHARGE_NOW:
ret = apple_smc_read_u16(power->smc, SMC_KEY(B0RM), &vu16);
val->intval = swab16(vu16) * 1000;
break;

B0FC (charge_full) is read with no swap and stays reliable the whole time, matches what others in this thread found re: CAPACITY being trustworthy while charge_now/energy_now aren't. On my M1 Air (bq20z451), current SMC firmware hands back B0RM in the opposite byte order from what this fixed swap assumes, so the swap actually makes it worse. Same root cause as the bq40z651 flip described upthread, just the other direction: it was already wrong, now it's wrong the other way.

Instead of hardcoding a swap either way, I added a small helper that reads B0RM raw, reads B0FC for comparison, and picks whichever byte order is physically plausible relative to charge_full (5% tolerance for gauge slop at top-off). Falls back to the old swab16() behavior if neither orientation looks sane or the B0FC read fails, so worst case it's no worse than today.
Patch: (attached / see below)

Tested: live module reloads plus two full reboots on my bq20z451 M1 Air. Had to fix an initramfs staleness issue first: my Fedora Asahi image bundles its own macsmc-power.ko in the initrd, so depmod alone doesn't cut it, you need dracut --force too. Stable across charge/discharge transitions and about 8 hours of normal use. charge_now/charge_full tracks CAPACITY closely (mine's consistently a couple points off, which is just normal coulomb-count vs relative-SoC drift, not a bug).

macsmc-power-fix-nocomments.patch

Haven't tested on a bq40z651 machine (M1 Pro/Max). If anyone here has one and wants to try the patch, that'd confirm it fixes both variants.

[dotevie]

will test on m1 pro and report back