Re: [BUG] hp-wmi-sensors: probe of 8F1F6435-9F42-42C8-BADC-0E9424F20C9A failed with error -22

[James Seo <james@equiv.tech>]

On Tue, Oct 31, 2023 at 11:34:16PM +0100, Armin Wolf wrote:
> Am 31.10.23 um 22:07 schrieb Lukasz Stelmach:
> 
>> It was <2023-10-31 wto 12:28>, when Guenter Roeck wrote:
>>> On 10/31/23 12:07, Lukasz Stelmach wrote:
>>> 
>>> [ ... ]
>>> 
>>>>> For what it's worth, I personally don't see much value in doing much
>>>>> more than a machine-limited workaround for now. To me it's clear that
>>>>> this UTF-16 corner case is a BIOS bug and its consequences are minimal
>>>>> once a workaround is in place.
>>>>> 
>>>>> Thoughts?
> 
> I think this is no BIOS bug, but valid behavior since the Windows ACPI-WMI mapper
> converts the ACPI objects into a common buffer format as described here:
> 
> https://learn.microsoft.com/en-us/windows-hardware/drivers/kernel/driver-defined-wmi-data-items
> 
Hi Armin,

I did see this link when you mentioned it earlier, and I understand that it's
specifying the packed and internally aligned buffer format that WMI on Windows
expects when a Windows driver provides a WMI data block.

This to me is a different question from whether an ACPI object in the BIOS,
one which will be converted to a WMI object by Windows later, should contain
UTF-16. I didn't find a single other example in all the ACPI dumps in the Linux
Hardware Database [1] of such an ACPI object.

So the answer to the question seems like a "SHOULD NOT". And someone at HP
definitely did a bad copy-paste when it came to this BIOS. I feel comfortable
calling it a bug (the leading "4" makes it one in any case).

> I assume that the mapper converts the ACPI string into a WMI string buffer, and that
> a common ACPI buffer is just passed as-is. In this case, the error lies inside the
> linux WMI subsystem, which does not do such a conversion.
>
> I can try to find out more about this conversion and its rules, and use this to add
> support for that to the WMI subsystem. This would prevent such errors in the future
> and would bring us closer to full ACPI WMI support inside the kernel.

Yes, if the ACPI-WMI mapping driver handles already existing UTF-16 in an ACPI
buffer as we have here, it would be good for us to support that as well.
Hopefully Łukasz can find a Windows machine to help determine if it does.

Earlier, you mentioned converting an ACPI object into the packed buffer format
that Windows expects. But is there some reason I'm missing for us to also pack
things like that in the first place? I assume that this format exists for
convenience (returning multiple values) or space reasons, and such a WMI
buffer is eventually unpacked into its various components according to the MOF
anyway. At least for WMI drivers on Linux, I think it would make more sense to
transparently convert the UTF-16 string to UTF-8 and pretend that the property
was an ACPI_TYPE_STRING all along.

And now I'm thinking out loud, but if WMI doesn't allow arbitrary binary data
(and from the WMI buffer spec you linked, it doesn't), and the Windows ACPI-WMI
mapper can indeed handle UTF-16, then ACPI_TYPE_BUFFER in ACPI objects intended
to become WMI objects can only contain UTF-16.

> This will take quite some time however, so i would suggest adding a quirk handler
> first and replace this with the WMI conversion functions later.

No worries.

[1] https://github.com/linuxhw/ACPI/