Hi All, 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. 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
