Hi, On 11/18/20 2:01 PM, Justin Forbes wrote: > On Wed, Nov 18, 2020 at 3:40 AM Peter Robinson <pbrobinson@xxxxxxxxx> wrote: >> >>> I believe $subject has been discussed before but I would like to see us >>> reconsider this. >>> >>> I know that the general rule of thumb is that DSDTs should not be overriden >>> and instead the kernel should be made to "just work" with existing DSDTs >>> even if they are buggy. And as someone who does a lot of ACPI related >>> bug-fixing in the upstream kernel, I completely agree. >>> >>> IIRC this was the main argument against enabling CONFIG_ACPI_TABLE_UPGRADE, >>> but even with it enabled actually using this is far from easy, so I'm >>> NOT worried that this will cause uses to do DSDT overrides to paper over >>> bugs which we really should fix otherwise. >>> >>> But sometimes being able to override the DSDT is still useful: >>> >>> 1. When I'm helping users to get various hardware issues fixed sometimes >>> it is useful to given them a DSDT override changing e.g. the bus-speed >>> for an I2C bus, or changing the type of an IRQ from level to edge, etc. >>> >>> 2. Unfortunately there is a small number of DSDT bugs which the kernel >>> simply cannot be fixed to handle. I know at least 2 examples of this: >>> >>> Example a. The Onda v975w ACPI battery code has a bug where the >>> full capacity always reports 0. This is a very straight forward error >>> in the DSDT, not a case of using some wiggle room in the ACPI spec >>> (expecting certain behavior which only Windows shows). This is >>> simply a DSDT bug. The code might just a well say "return 0" >>> >>> Example b. The Acer Switch sw5-012 is completely missing the ACPI >>> Device (PWM0) section declaring the PWM controller which is used >>> for controlling the backlight of the LCD. This leads to non working >>> brightness control and also to much to high energy drain while >>> suspended. >>> >>> For both these cases having CONFIG_ACPI_TABLE_UPGRADE=y would be >>> very helpful. The only downside would be that this is not compatible >>> with secureboot. So if not done upstream already then we must tie >>> this to the kernel-lockdown stuff and disallow it when lockdown mode >>> is active. I can try to write a patch for this if necessary. >> >> I think disabling this for secure boot/lockdown makes sense because >> there's likely security implications to this. I seem to remember this >> was one of the reasons for previously not enabling it. > > This is correct, it was actually enabled until June of this year, and > turned off with the 5.7.7 kernel updates due to being an attack vector > for a CVE. Shortly after, a patch was pushed upstream to disable > loading ACPI tables if secure boot was enabled, so I should be able to > turn this back on. I will do so for the 5.9.9 updates. Sounds good, thank you. Regards, Hans _______________________________________________ kernel mailing list -- kernel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to kernel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kernel@xxxxxxxxxxxxxxxxxxxxxxx
