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