Windows/Linux mismatch in _OSI return value for supported OS

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

 



Hi,

Asus are pushing BIOS updates that include the following code:

    If (~_OSI ("Windows 2012"))
    {
        SRXO (0x0203000D, One)
    }

This is supposed to be a bugfix for Windows 7 and previous, SRXO
should run there. But if that SRXO call runs on Windows 8 or newer, or
Linux, the laptop's touchpad stops responding.

However, on Linux, even though we do claim support for Windows 2012,
that SRXO code is running and breaking the touchpad. Why? They are
using bitwise not. _OSI on Linux returns a 32-bit value 0xffffffff to
mean "supported" (as stated in the ACPI spec). But ACPI integers are
64 bits.

So, ~_OSI(Windows 2012) = ~0x00000000FFFFFFFF = 0xFFFFFFFF00000000.
Non-zero, so this will always evaluate to TRUE.

This is a pretty strong suggestion that Windows is disobeying the ACPI
spec here and is returning 0xffffffffffffffff (64 ones) from _OSI.
(can someone double check?)

Should Linux be modified to follow Windows behaviour too? Any hints on
how to do that? acpi_ut_osi_implementation return type is acpi_status,
32 bit, so it's not even immediately obvious how to make this change.

Thanks,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [Linux IBM ACPI]     [Linux Power Management]     [Linux Kernel]     [Linux Laptop]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]     [Linux Resources]

  Powered by Linux