On Sat, 20 Dec 2025, Armin Wolf wrote:

> The Windows WMI-ACPI driver likely uses wmilib [1] to interact with
> the WMI service in userspace. Said library uses plain byte buffers
> for exchanging data, so the WMI-ACPI driver has to convert between
> those byte buffers and ACPI objects returned by the ACPI firmware.
> 
> The format of the byte buffer is publicly documented [2], and after
> some reverse eingineering of the WMI-ACPI driver using a set of custom
> ACPI tables, the following conversion rules have been discovered:
> 
> - ACPI integers are always converted into a uint32
> - ACPI strings are converted into special WMI strings
> - ACPI buffers are copied as-is
> - ACPI packages are unpacked
> 
> Extend the ACPI-WMI driver to also perform this kind of marshalling
> for WMI data blocks, methods and events. During so gives us a number
> of benefits:
> 
> - WMI drivers are not restricted to a fixed set of supported ACPI data
>   types anymore, see dell-wmi-aio (integer vs buffer) and
>   hp-wmi-sensors (string vs buffer)
> 
> - correct marshalling of WMI strings when data blocks are marked
>   as requiring ACPI strings instead of ACPI buffers
> 
> - development of WMI drivers without having to understand ACPI
> 
> This eventually should result in better compatibility with some
> ACPI firmware implementations and in simpler WMI drivers. There are
> however some differences between the original Windows driver and
> the ACPI-WMI driver when it comes to ACPI object conversions:
> 
> - the Windows driver copies internal _ACPI_METHOD_ARGUMENT_V1 data
>   structures into the output buffer when encountering nested ACPI
>   packages. This is very likely an error inside the driver itself, so
>   we do not support nested ACPI packages.
> 
> - when converting WMI strings (UTF-16LE) into ACPI strings (ASCII),
>   the Windows driver replaces non-ascii characters (ä -> a, & -> ?)
>   instead of returning an error. This behavior is not documented
>   anywhere and might lead to severe errors in some cases (like
>   setting BIOS passwords over WMI), so we simply return an error.
> 
> As the current bus-based WMI API is based on ACPI buffers, a new
> API is necessary. The legacy GUID-based WMI API is not extended to
> support marshalling, as WMI drivers using said API are expected to
> move to the bus-based WMI API in the future.
> 
> [1] https://learn.microsoft.com/de-de/windows-hardware/drivers/ddi/wmilib/
> [2] https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/
>     driver-defined-wmi-data-items
> 
> Signed-off-by: Armin Wolf <W_Armin@gmx.de>



> diff --git a/drivers/platform/wmi/internal.h b/drivers/platform/wmi/internal.h
> new file mode 100644
> index 000000000000..707d1a4711e0
> --- /dev/null
> +++ b/drivers/platform/wmi/internal.h
> @@ -0,0 +1,14 @@
> +/* SPDX-License-Identifier: GPL-2.0-or-later */
> +/*
> + * Internal interfaces used by the WMI core.
> + *
> + * Copyright (C) 2025 Armin Wolf <W_Armin@gmx.de>
> + */
> +
> +#ifndef _WMI_INTERNAL_H_
> +#define _WMI_INTERNAL_H_
> +
> +int wmi_unmarshal_acpi_object(const union acpi_object *obj, struct wmi_buffer *buffer);
> +int wmi_marshal_string(const struct wmi_buffer *buffer, struct acpi_buffer *out);

These currently depends on the includes in the C file including this as 
you do not introduce these types beforehand.

-- 
 i.