It depends on the kernel being built with ACPI_REV_OVERRIDE_POSSIBLE=y and acpi_rev_override=1 being set on the kernel command line On Wed, Nov 20, 2019 at 1:15 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > On Wed, Nov 20, 2019 at 1:10 PM Karol Herbst <kherbst@xxxxxxxxxx> wrote: > > > > On Wed, Nov 20, 2019 at 1:06 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > > > > > On Wed, Nov 20, 2019 at 12:51 PM Karol Herbst <kherbst@xxxxxxxxxx> wrote: > > > > > > > > On Wed, Nov 20, 2019 at 12:48 PM Rafael J. Wysocki <rafael@xxxxxxxxxx> wrote: > > > > > > > > > > On Wed, Nov 20, 2019 at 12:22 PM Mika Westerberg > > > > > <mika.westerberg@xxxxxxxxx> wrote: > > > > > > > > > > > > On Wed, Nov 20, 2019 at 11:52:22AM +0100, Rafael J. Wysocki wrote: > > > > > > > On Wed, Nov 20, 2019 at 11:18 AM Mika Westerberg > > > > > > > <mika.westerberg@xxxxxxxxx> wrote: > > > > > > > > > > > > > > [cut] > > > > > > > > > > > > > > > > > Oh, so does it look like we are trying to work around AML that tried > > > > > > > to work around some problematic behavior in Linux at one point? > > > > > > > > > > > > Yes, it looks like so if I read the ASL right. > > > > > > > > > > OK, so that would call for a DMI-based quirk as the real cause for the > > > > > issue seems to be the AML in question, which means a firmware problem. > > > > > > > > > > > > > And I disagree as this is a linux specific workaround and windows goes > > > > that path and succeeds. This firmware based workaround was added, > > > > because it broke on Linux. > > > > > > Apparently so at the time it was added, but would it still break after > > > the kernel changes made since then? > > > > > > Moreover, has it not become harmful now? IOW, wouldn't it work after > > > removing the "Linux workaround" from the AML? > > > > > > The only way to verify that I can see would be to run the system with > > > custom ACPI tables without the "Linux workaround" in the AML in > > > question. > > > > > > > the workaround is not enabled by default, because it has to be > > explicitly enabled by the user. > > I'm not sure what you are talking about. > > I'm taking specifically about the ((OSYS == 0x07DF) && (_REV == 0x05)) > check mentioned by Mika which doesn't seem to depend on user input in > any way. >
