On 11/22/22 15:28, Frank Crawford wrote:
On Tue, 2022-11-22 at 10:46 -0800, Guenter Roeck wrote:
On Mon, Nov 21, 2022 at 01:57:18PM +1100, Frank Crawford wrote:
On some Gigabyte boards sensors are marked as ACPI regions but not
really handled by ACPI calls, as they return no data.
Most commonly this is seen on boards with multiple ITE chips.
In this case we just ignore the failure and continue on.
This is effectively the same as the use of either
acpi_enforce_resources=lax (kernel)
or
ignore_resource_conflict=1 (it87)
but set programatically.
Signed-off-by: Frank Crawford <frank@xxxxxxxxxxxxxxxxxx>
---
Sorry, I can not accept this patch. Ignoring resource conflicts
may have unintentional side effects and _has_ to be explicitly
requested by the user.
I do have two comments on that decision, firstly, for the bulk of the
boards listed I've dumped the ACPI tables and data and the conflicting
address ranges do nothing with ACPI. It looks like Gigabyte planned to
implement WMI access, but stopped after developing some code for single
chipset boards, and just nulled out anything to do with boards with two
chips. However, getting any information from Gigabyte about this is
impossible, as you know.
Secondly, unfortunately most users have no idea what the ACPI error
means, and just follow random comments on the Internet, which currently
is to set "acpi_enforce_resources=lax" which is even more dangerous.
At least the recent addition of "ignore_resource_conflict=1" restricts
the issue to a known area, and this would take it one step further in
That is exactly why I had added to flag in the out-of-tree driver.
that we are just automating it for known "safe" boards.
However, if you are not willing to accept it, I'll just drop it there.
Sorry, I'd rather live with 100 users mad with me for not permitting
the patch than permitting it and having to deal with one user who
ended up with broken hardware or random reboots. This _has_ to be a
conscious decision made by users.
Also, ignoring ACPI resource conflicts always was and always will be risky.
There is no such thing as a "known safe board". Who knows what Gigabyte
is going to do in the next version of their BIOS.
Guenter
