Re: Enabling CONFIG_ACPI_TABLE_UPGRADE in Fedora kernels

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



+Al, Prarit - FYI

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




[Index of Archives]     [Fedora General Discussion]     [Older Fedora Users Archive]     [Fedora Advisory Board]     [Fedora Security]     [Fedora Devel Java]     [Fedora Legacy]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Mentors]     [Fedora Package Announce]     [Fedora Package Review]     [Fedora Music]     [Fedora Packaging]     [Centos]     [Fedora SELinux]     [Coolkey]     [Yum Users]     [Tux]     [Yosemite News]     [KDE Users]     [Fedora Art]     [Fedora Docs]     [USB]     [Asterisk PBX]

  Powered by Linux