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 10:07:26PM +0100, Lukasz Stelmach wrote:
> 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 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.

Must be nice being able to patch this sort of thing in devicetree.

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

This particular bug seems extremely rare in general, which means I'm further
inclined towards treating it as a one-off. As Günter said, we can always add
more later.

Can you provide the output of `dmidecode -s baseboard-product-name` for now?