On 18 Nov 2020 09:13, Don Zickus wrote: > +Al, Prarit - FYI Yup, been following along ... > On Wed, Nov 18, 2020 at 10:27:55AM +0100, Hans de Goede wrote: > > 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 Yeah, I agree with Hans. It is really useful to be able to override the DSDT to experiment with solutions, much less fix faulty tables. And as long as this is tied to kernel-lockdown, it sounds like a good idea to me. -- ciao, al ----------------------------------- Al Stone Software Engineer Red Hat, Inc. ahs3@xxxxxxxxxx ----------------------------------- _______________________________________________ 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
