[PATCH] ACPI: OSI: Enable _OSI("Windows 2022") on HP OmniBook X Flip 16-ar0xxx

[PATCH] ACPI: OSI: Enable _OSI("Windows 2022") on HP OmniBook X Flip 16-ar0xxx

[David Del Sol]

[-- Attachment #1.1: Type: text/plain, Size: 1307 bytes --]

Hi all,

This fixes slow battery charging on the 2025 HP OmniBook X Flip (AMD Ryzen
AI 5 340, DMI board 8DA8): with a 65 W charger plugged in, the battery
charges at only ~0.2 W on Linux instead of the ~30 W Windows gets.

The EC firmware only enables normal charging when the OS claims
_OSI("Windows 2022"), and the DSDT/SSDT only check up to that string.
Linux's default claimed OSI strings stop short of it, so the fast-charging
branch never runs. Adding acpi_osi=! acpi_osi="Windows 2022" to the kernel
cmdline restores 31-33 W - verified across multiple charge cycles on
kernels 7.1.6 and 6.18.42-LTS.

I checked with HP first: they declined in writing (warranty case
#5163282638, supervisor email 2026-08-10), saying the firmware is
"specifically manufactured and optimized for the Windows operating system"
and not supported for other OSes. A kernel-side quirk is therefore the
only fix path.

The patch claims _OSI("Windows 2022") via acpi_osi_setup() with a DMI
match scoped to board 8DA8 (same mechanism as dmi_enable_osi_linux), so
no other platform is affected. Full evidence - DSDT/SSDT strings, EC RAM
dumps, measurement logs - is on the bugzilla report below; happy to add
sibling boards as owners confirm.

Thanks for looking,
David

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221866

[-- Attachment #1.2: Type: text/html, Size: 1522 bytes --]

[-- Attachment #2: 0001-ACPI-OSI-Enable-_OSI-Windows-2022-on-HP-OmniBook-X-Flip.patch --]
[-- Type: text/x-patch, Size: 1805 bytes --]

ACPI: OSI: Enable _OSI("Windows 2022") on HP OmniBook X Flip 16-ar0xxx

The HP OmniBook X Flip (2025, AMD Ryzen AI 5 340, board 8DA8) throttles
battery charging to ~0.2 W on Linux because the EC firmware only enables
normal charging (30 W, matching Windows) when the OS claims
_OSI("Windows 2022"). The DSDT/SSDT contain firmware OSI checks only up
to "Windows 2022", and Linux's default claimed OSI strings stop before
that, so the EC's fast-charging branch never activates.

Claiming the string is verified to restore 31-33 W charging on kernels
7.1.6 and 6.18.42-LTS across multiple charge cycles. HP has declined in
writing (warranty case #5163282638) to provide a BIOS/EC update, so a
kernel-side quirk is the only fix path. Scope the quirk to this board
only (DMI 103C_5335M8 HP OmniBook X, board 8DA8); sibling boards can be
added as they are confirmed.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=221866
Signed-off-by: David Del Sol <daviddelsol1998@gmail.com>

diff --git a/drivers/acpi/osi.c b/drivers/acpi/osi.c
index ffdf504..8e2b3d4 100644
--- a/drivers/acpi/osi.c
+++ b/drivers/acpi/osi.c
@@ -464,6 +464,21 @@ static const struct dmi_system_id acpi_osi_dmi_table[] __initconst = {
 		},
 	},
 
+	/*
+	 * The HP OmniBook X Flip (AMD) throttles battery charging to ~0.2 W
+	 * unless _OSI("Windows 2022") is claimed: the EC firmware only
+	 * enables normal charging on that firmware path. Verified to restore
+	 * 31-33 W charging (Windows parity).
+	 */
+	{
+	.callback = dmi_enable_osi_win22,
+	.ident = "HP OmniBook X Flip 16-ar0xxx",
+	.matches = {
+		     DMI_MATCH(DMI_SYS_VENDOR, "HP"),
+		     DMI_MATCH(DMI_BOARD_NAME, "8DA8"),
+		},
+	},
+
 	/*
 	 * BIOS invocation of _OSI(Linux) is almost always a BIOS bug.
 	 * Linux ignores it, except for the machines enumerated below.

Re: [PATCH] ACPI: OSI: Enable _OSI("Windows 2022") on HP OmniBook X Flip 16-ar0xxx

[Mario Limonciello]

On 8/11/26 12:48, David Del Sol wrote:
> Hi all,
> 
> This fixes slow battery charging on the 2025 HP OmniBook X Flip (AMD Ryzen
> AI 5 340, DMI board 8DA8): with a 65 W charger plugged in, the battery
> charges at only ~0.2 W on Linux instead of the ~30 W Windows gets.
> 
> The EC firmware only enables normal charging when the OS claims
> _OSI("Windows 2022"), and the DSDT/SSDT only check up to that string.
> Linux's default claimed OSI strings stop short of it, so the fast-charging
> branch never runs. Adding acpi_osi=! acpi_osi="Windows 2022" to the kernel
> cmdline restores 31-33 W - verified across multiple charge cycles on
> kernels 7.1.6 and 6.18.42-LTS.
> 
> I checked with HP first: they declined in writing (warranty case
> #5163282638, supervisor email 2026-08-10), saying the firmware is
> "specifically manufactured and optimized for the Windows operating system"
> and not supported for other OSes. A kernel-side quirk is therefore the
> only fix path.
> 
> The patch claims _OSI("Windows 2022") via acpi_osi_setup() with a DMI
> match scoped to board 8DA8 (same mechanism as dmi_enable_osi_linux), so
> no other platform is affected. Full evidence - DSDT/SSDT strings, EC RAM
> dumps, measurement logs - is on the bugzilla report below; happy to add
> sibling boards as owners confirm.
> 
> Thanks for looking,
> David
> 
> Link: https://bugzilla.kernel.org/show_bug.cgi?id=221866 <https:// 
> bugzilla.kernel.org/show_bug.cgi?id=221866>

Are you sure about your proposed root cause?  It has been enabled a very 
long time.

https://git.kernel.org/torvalds/c/dd067afe3f8cb

Re: [PATCH] ACPI: OSI: Enable _OSI("Windows 2022") on HP OmniBook X Flip 16-ar0xxx

[Mario Limonciello]

On 8/11/26 13:45, David Del Sol wrote:
> Thanks for looking into this Mario,
> I'm not 100% sure of the root cause, and after dumping the
> ACPI tables I know my original explanation was wrong: there's no
> `_OSI("Windows 2022")` check anywhere in the DSDT or SSDTs.

It seemed like you were referencing a non-existent callback in your 
patch too.  I don't know how that could have possibly compiled.

> 
> What I do know: the combo `acpi_osi=! acpi_osi="Windows 2022"` reliably
> takes charging from ~0.2 W to 31-33 W. I'm isolating which half of the
> command line actually does the work now (testing each half alone), and
> I'll report back what I find, then update the bugzilla report with the
> corrected story.

It's more likely that the 'acpi_osi=!' did something IMO.

What strings are in your BIOS?  Have you looked at an acpidump yet?

> 
> David
> 
> On Tue, Aug 11, 2026 at 12:52 PM Mario Limonciello 
> <mario.limonciello@amd.com <mailto:mario.limonciello@amd.com>> wrote:
> 
> 
> 
>     On 8/11/26 12:48, David Del Sol wrote:
>      > Hi all,
>      >
>      > This fixes slow battery charging on the 2025 HP OmniBook X Flip
>     (AMD Ryzen
>      > AI 5 340, DMI board 8DA8): with a 65 W charger plugged in, the
>     battery
>      > charges at only ~0.2 W on Linux instead of the ~30 W Windows gets.
>      >
>      > The EC firmware only enables normal charging when the OS claims
>      > _OSI("Windows 2022"), and the DSDT/SSDT only check up to that string.
>      > Linux's default claimed OSI strings stop short of it, so the
>     fast-charging
>      > branch never runs. Adding acpi_osi=! acpi_osi="Windows 2022" to
>     the kernel
>      > cmdline restores 31-33 W - verified across multiple charge cycles on
>      > kernels 7.1.6 and 6.18.42-LTS.
>      >
>      > I checked with HP first: they declined in writing (warranty case
>      > #5163282638, supervisor email 2026-08-10), saying the firmware is
>      > "specifically manufactured and optimized for the Windows
>     operating system"
>      > and not supported for other OSes. A kernel-side quirk is
>     therefore the
>      > only fix path.
>      >
>      > The patch claims _OSI("Windows 2022") via acpi_osi_setup() with a DMI
>      > match scoped to board 8DA8 (same mechanism as
>     dmi_enable_osi_linux), so
>      > no other platform is affected. Full evidence - DSDT/SSDT strings,
>     EC RAM
>      > dumps, measurement logs - is on the bugzilla report below; happy
>     to add
>      > sibling boards as owners confirm.
>      >
>      > Thanks for looking,
>      > David
>      >
>      > Link: https://bugzilla.kernel.org/show_bug.cgi?id=221866
>     <https://bugzilla.kernel.org/show_bug.cgi?id=221866> <https://
>      > bugzilla.kernel.org/show_bug.cgi?id=221866 <http://
>     bugzilla.kernel.org/show_bug.cgi?id=221866>>
> 
>     Are you sure about your proposed root cause?  It has been enabled a
>     very
>     long time.
> 
>     https://git.kernel.org/torvalds/c/dd067afe3f8cb <https://
>     git.kernel.org/torvalds/c/dd067afe3f8cb>
>