On 10/27/23 08:07, Lukasz Stelmach wrote:
Hi,
I've got HP EliteDesk 800 G6 Tower PC running Linux 6.1 from Debian 12.
I managed to build the hp-wmi-sensors out of tree. When I loaded it I
got EINVAL.
hp-wmi-sensors: probe of 8F1F6435-9F42-42C8-BADC-0E9424F20C9A failed with error -22
I managed to track it down. And it happens in check_wobj() called from
check_platform_events_wobj() because in the for loop when prop==0 the
type is ACPI_TYPE_BUFFER instead of ACPI_TYPE_STRING. When I bypass this
particular check like this
if (prop == 0 && type == ACPI_TYPE_BUFFER)
continue;
everything else works like charm and I can read senosrs via sysfs. I'd
like to perpare a proper patch, but I've got no idea how to do properly
work this quirk around. What are your suggestions?
Kind regards,
I really don't know if that is a bug in the driver or a bug in the WMI
description on that system. Given that, I have no idea how to handle this.
I also don't know the impact of ACPI_TYPE_BUFFER vs. ACPI_TYPE_STRING;
from the code in the kernel it seems that those values have a distinctly
different meaning. Is the returned value, when extracted, a string ?
Is it ok to accept ACPI_TYPE_BUFFER instead of ACPI_TYPE_STRING for
property names ? I simply don't know.
Are the type checks really needed ? What do other drivers do when interpreting
WMI data ? Could extract_acpi_value() be more flexible and also accept
ACPI_TYPE_BUFFER, or would that potentially create other problems ?
Lots of questions that at least for my part can not answer.
Guenter
