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