https://bugzilla.kernel.org/show_bug.cgi?id=221866
Bug ID: 221866
Summary: HP OmniBook X Flip (board 8DA8) charges at ~0.2W on
Linux - EC gates charging on _OSI("Windows 2022")
Product: ACPI
Version: 2.5
Hardware: AMD
OS: Linux
Status: NEW
Severity: normal
Priority: P3
Component: Power-Battery
Assignee: [email protected]
Reporter: [email protected]
Regression: No
The HP OmniBook X Flip (2025, AMD Ryzen AI 5 340) charges at ~0.2 W on stock
Linux
instead of the ~30 W it achieves on Windows. Root cause identified and
verified:
the EC firmware only enables normal charging when the OS claims
_OSI("Windows 2022"), which the Linux kernel does not do by default.
HARDWARE:
Manufacturer: HP
Product: HP OmniBook X Flip Laptop 16-ar0xxx (also affects other
OmniBook X Flip / OmniBook 5/7 2025 models)
Board ID: 8DA8 (DMI 103C_5335M8 HP OmniBook X, board version 49.34)
SKU: B5UJ4UA#ABA
CPU: AMD Ryzen AI 5 340 (6C/12T, Radeon 840M)
Battery: 68 Wh, model CI04068XL
Charger: 65 W USB-C PD (20 V / 3.25 A)
TEST ENVIRONMENT:
OS: CachyOS (Arch-based, rolling); also reproduced on Ubuntu
Kernels: 7.1.6-1-cachyos and 6.18.42-1-cachyos-lts
Bootloader: Limine (workaround applies to any bootloader/kernel)
ROOT CAUSE (verified):
The DSDT/SSDT (checked via `strings` on /sys/firmware/acpi/tables/DSDT and
SSDT*) contain firmware OSI checks only up to "Windows 2022":
Windows 2009 2012 2013 2015 2016 2017 2017.2 2018 2018.2 2019 2020 2021
2022
The Linux kernel's default claimed OSI strings stop before "Windows 2022"
(per Documentation/firmware-guide/acpi/osi.rst), so the EC's fast-charging
branch -- gated on _OSI("Windows 2022") -- never activates on stock Linux.
The charging rate is therefore pinned to ~0.2 W regardless of charger.
This is the same firmware pattern previously documented for the Samsung
Galaxy Book 4 (Arch forum thread 297580) and reported by multiple HP
OmniBook X Flip owners on the HP Community (thread about the Flip only
charging fast when shut down).
MEASUREMENTS (from /sys/class/power_supply/BAT0, 65 W adapter):
stock Linux: POWER_SUPPLY_POWER_NOW ~= 200000 uW
(0.2 W)
with acpi_osi=! acpi_osi="Windows 2022": 31-33 W (matches Windows behavior)
Windows (per HP spec): ~30 W while system on, ~60 W off
Linux with workaround, live now: 27.8 W charging, battery at 79%
WORKAROUND (confirmed, verified over multiple charge cycles and two kernels):
kernel cmdline: acpi_osi=! acpi_osi="Windows 2022"
(survives kernel updates when configured persistently, e.g. in the
bootloader config)
SECONDARY ISSUE (separate, intermittent):
On rare occasions (~1 in 4 plug/unplug events) the USB-PD contract gets
stuck at 5 V / 3 A (15 W total, ~0.2 W to battery) after replugging the
charger at runtime. UCSI driver reload, suspend/resume and replug all fail
to recover; only a reboot restores 20 V negotiation. Not reproduced in 3
subsequent cycles. Linux exposes no sink-side PDO request interface
(/sys/class/usb_power_delivery exposes source/sink capabilities read-only),
so the OS cannot re-request the 15/20 V PDO the way Windows does.
REQUESTED FIXES:
1. DMI-scoped OSI quirk in drivers/acpi/osi.c (same mechanism as the
existing dmi_enable_osi_linux entries) claiming "Windows 2022" for HP
board 8DA8 (and sibling OmniBook boards 8EA2 etc.), so stock kernels
charge correctly without user cmdline hacks. DMI-scoped only -- NOT
requesting a global OSI claim change (known regression risk).
2. Sink-side PDO request support in the UCSI/typec driver so the OS can
renegotiate after a failed plug-in without a reboot.
ATTACHMENTS:
EC RAM dumps (256-byte debugfs /sys/kernel/debug/ec/ec0/io), slow vs fast
charging states, plus hex/xxd renderings. DSDT disassembly on request.
FOR DEVELOPERS:
Repro/evidence commands (as root):
for f in /sys/firmware/acpi/tables/DSDT /sys/firmware/acpi/tables/SSDT*; \
do strings "$f"; done | grep -oE "Windows 20[0-9]{2}" | sort -u
cat /sys/class/power_supply/BAT0/uevent
cat /sys/class/power_supply/ucsi-source-psy-USBC000:*/uevent
modprobe ec_sys write_support=1 && cat /sys/kernel/debug/ec/ec0/io
dmidecode -t2
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
_______________________________________________
acpi-bugzilla mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/acpi-bugzilla
