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
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.
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.
Armin Wolf
I am no expert regarding x86 platforms and I don't know how often
bugs
like this happen and if making it more generic makes sens. Maybe.
That really depends on the system vendor, less on the CPU architecture.
Of course it's not architecture but rather vendor landscape. My point
is that most embedded platforms I work with can be fixed at this level
by patching device-tree, which is much easier (at least for me) than
patching BIOS/UEFI. And I've seen a number of broken BIOS-es over years
which vendors didn't care to fix. At the end of the day my *impression*
is that x86 platform users more often have to live with quirks like this
that require fixes at higher levels. But this is just my impression.
My solution would be to add a module option, let's name it `quirks` and
make it a bit field for future use, that enables the workaound. Plus an
additional error message when probe fails to suggest user to add the
option to kernel command line or whatever file that contains module
options. A nice touch would be to detect if the workaround is still
required.
Please no module option. Use DMI data or similar.
DMI data is fine when can you identify broken systems upfront. In this
case we don't know which systems are or will be affected by this bug.
For example, eariler this year I fixed a different quirk in the same
machine[1] but luckily there was a way I could apply the fix without
waiting for the patch to be merged and pulled downstream. In my case
I could use ALSA features to make my machine work before I got a patched
kernel.
Maybe both?
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea24b9953bcd3889f77a66e7f1d7e86e995dd9c3
[2] https://bugzilla.kernel.org/show_bug.cgi?id=217008
