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

[Mario Limonciello <mario.limonciello@amd.com>]

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>
>