https://bugzilla.kernel.org/show_bug.cgi?id=204807 --- Comment #46 from Zhang Rui (rui.zhang@xxxxxxxxx) --- (In reply to Artem S. Tashkinov from comment #43) > A small correction of my previous comment: > > linux/drivers/platform/x86/asus-nb-wmi.c > > /* > * Asus Notebooks WMI hotkey driver > * > * Copyright(C) 2010 Corentin Chary <corentin.chary@xxxxxxxxx> > */ > > This is not related to lm-sensors in any shape or form. asus_nb_wmi_init -> asus_wmi_register_driver -> asus_wmi_probe -> asus_wmi_add -> asus_wmi_hwmon_init Although the warning messages are printed by ACPI code, but this is a conflict between the native nct6775 driver and the Asus wmi driver, because Asus wmi driver accesses the same piece of resources and provide similar functionalities. And I'm familiar with neither of them. > I'm really sad how > this situation is getting handled: the bug has been known for over 1.5 > years, affects literally hundreds of thousands devices and you're saying > that this kernel option might have unintended consequences yet _everyone_ in > this thread has enabled it with _zero_ side affects and Windows seemingly > has it enabled by default, as no such messages are getting logged in Windows > Event Log either when using HWiNFO64 or vendor specific monitoring software. In Linux, at least for now, I don't see a way to enable native nct6775 driver by default, and, this is true for all the native drivers that have resource conflict with the firmware. IMO, the rootcause is that Linux does not support override driver A (native driver in this case) when driver B (driver that talks to firmware) is loaded, so we have to disable driver A even if there is only 0.01% possibility that driver B will be loaded when we know there might be a conflict. what we can do is to write driver B to make this statement true "ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver" and ignore this message. (In reply to Artem S. Tashkinov from comment #44) > (In reply to Artem S. Tashkinov from comment #42) > > "Your motherboard might not be 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". > > This message will at least allow various Linux distros to enable the option > by default because many are not aware of the bug. Hmmm, what about following conditions 1. "acpi_enforce_resources=" is a global switch, there might be platforms with more than one conflict, or with another conflict rather than nct6775. we can not validate all of them. 2. we may have new drivers that talk with firmware later, and we can not use "acpi_enforce_resources=lax" then. But thanks for raising this up, I think this also rings a bell that the current message is kind of misleading. It is true that ACPI covers a series of devices as described in the ACPI spec. But at the same time, ACPI is an interface. Many drivers, including vendor specific drivers, talks with firmware through the ACPI Interface. They depends on ACPI, but they're actually not covered by the ACPI specification, nor by kernel drivers/acpi code. "ACPI: If an ACPI driver is available for this device, you should use it instead of the native driver" makes people feel like it is an ACPI problem, but in many cases, it is not, I can only triage them. -- You may reply to this email to add a comment. You are receiving this mail because: You are watching the assignee of the bug.
