[Bug 204807] Hardware monitoring sensor nct6798d doesn't work unless acpi_enforce_resources=lax is enabled

bugzilla-daemon
2021-03-20T15:29:05Z

Artem S. Tashkinov (aros@gmx.com) changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|INVALID |---

--- Comment #42 from Artem S. Tashkinov (aros@gmx.com) ---
(In reply to Matthew Garrett from comment #37)
> 97845ED0-4E6D-11DE-8A39-0800200C9A66. That has an ID of 0x4243, or BC - ie,
> it's not the GUID we're looking for. The next GUID, however,
> (466747a0-70ec-11de-8a39-0800200c9a66) has an identifier of 0x4344, or BD.
> So this is the GUID we're looking for. Unfortunately asus-wmi doesn't handle
> this GUID, so new code will need to be written.
>
> I'm going to close this bug again because it's turned into a generic bug
> covering different motherboard vendors, and there's no one size fits all
> solution. For your case the correct way to handle it is for someone to write
> a driver that uses the 466747a0-70ec-11de-8a39-0800200c9a66 interface to
> expose the sensor data. I'm afraid I don't have relevant hardware so can't
> do this myself, but please do open another bug for that.
>
> tl;dr - the kernel message you're seeing is correct. Avoiding it requires a
> new driver to be written. If you *personally* feel safe in ignoring the
> risks, you can pass the acpi_enforce_resources=lax option, but that can't be
> the default because it's unsafe in the general case, and so it isn't the
> solution to the wider problem.

That's the problem: we have _multiple_ motherboards with _multiple_ different
chipsets from _different_ vendors

1) all having the same glitch
2) all requiring the same workaround
3) working just fine under Windows with no hacks

> My understanding is that asus_wmi/asus_nb_wmi do the same thing as nct6775
> and expose them to hwmon class as well.

And at the same time you're talking about asus_wmi which covers only _certain_
ASUS motherboards, and no one in this discussion has shown it to work or
provide the same set of sensors.

And this driver has nothing to do with sensors,
linux/drivers/platform/x86/asus-wmi.c:

* Asus PC WMI hotkey driver

This is not a driver which even tangentially deals with HW sensors found in
motherboards affected by this bug.

I don't know why you're trying to sweep this bug under the rug but I really
dislike it. The Linux kernel development has always followed common sense
principles and it contains a _huge_ number of workarounds just to enable HW
which doesn't work according to specs.

At the very least you could printk() this:

"Your motherboard might not exposing ACPI resources correctly, so you might not
get access to your HW sensors. You could add "acpi_enforce_resources=lax" to
kernel boot parameters to enable monitoring at your own risk. Please refer to
https://bugzilla.kernel.org/show_bug.cgi?id=204807 for more information".

And this still paints Linux in a very bad light as users hardly care about if
ACPI is implemented according to the specifications or not: however what they
really care is whether their hardware works or being supported under Linux
regardless out of the box. Most Linux users don't even know `dmesg` exists, so
they have no way of knowing how to fix the issue.

Lastly, this bug is not fixed.