| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Tue, 2 Feb 2010 08:22:40 +0100
From: Corentin Chary <corentin.chary@...il.com>
To: Len Brown <lenb@...nel.org>
Cc: andrej.gelenberg@....edu, Daniel Mack <daniel@...aq.de>,
linux-acpi@...r.kernel.org, acpi4asus-user@...ts.sourceforge.net,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [Acpi4asus-user] ACPI device for ASUS EEEPC 1101HA not added
On Tue, Feb 2, 2010 at 7:02 AM, Len Brown <lenb@...nel.org> wrote:
> On Mon, 1 Feb 2010, andrej.gelenberg@....edu wrote:
>
>> Hi,
>>
>> you need to whitelist your eee pc for OSI(Linux) in drivers/acpi/blacklist.c
>> like this:
>>
>> + /*
>> + * On newer Eeepc, the interface used by eeepc-laptop (ASUS010)
>> + * is disabled without _OSI(Linux)
>> + */
>> + {
>> + .callback = dmi_enable_osi_linux,
>> + .ident = "Asus Eeepc-1101HA",
>> + .matches = {
>> + DMI_MATCH(DMI_SYS_VENDOR, "ASUSTeK Computer INC."),
>> + DMI_MATCH(DMI_PRODUCT_NAME, "1101HA"),
>> + },
>> + },
>
> Not necessarily the right fix. We have gone to a lot of trouble
> to discourage BIOS vendors from depending on the ill-defined OSI(Linux),
> so I hesitate to invoke it -- even for a workaround.
>
> The problem at hand is that ASUS010 is not enabled for an OS
> that claims compatibility with Win7 (MSOS() == MSW7) below.
>
> Scope (\_SB)
> {
> Name (ATKP, Zero)
> Device (ATKD)
> {
> Name (_HID, "ASUS010")
> Name (_UID, 0x01010100)
> Method (_STA, 0, NotSerialized)
> {
> If (LEqual (MSOS (), MSW7))
> {
> Return (Zero)
> }
> Else
> {
> Return (0x0F)
> }
>
> Return (Zero)
> Return (0x0F)
> }
>
> (heh, see any indication of lack of quality in this code?:-)
>
> MSOS() does this:
>
> Scope (\)
> {
> Name (OSLX, 0x10)
> Name (OSMS, 0x20)
> Name (MS98, 0x21)
> Name (MSME, 0x22)
> Name (MS2K, 0x23)
> Name (MSXP, 0x24)
> Name (MSVT, 0x25)
> Name (MSW7, 0x26)
> Name (OSFG, Ones)
> Method (MSOS, 0, NotSerialized)
> {
> If (LNotEqual (OSFG, Ones))
> {
> Return (OSFG)
> }
>
> Store (Zero, OSFG)
> If (CondRefOf (_OSI, Local0))
> {
> If (_OSI ("Windows 2001"))
> {
> Store (MSXP, OSFG)
> }
>
> If (_OSI ("Windows 2001 SP1"))
> {
> Store (MSXP, OSFG)
> }
>
> If (_OSI ("Windows 2001 SP2"))
> {
> Store (MSXP, OSFG)
> }
>
> If (_OSI ("Windows 2006"))
> {
> Store (MSVT, OSFG)
> }
>
> If (_OSI ("Windows 2009"))
> {
> Store (MSW7, OSFG)
> }
>
> If (_OSI ("Linux"))
> {
> Store (OSLX, OSFG)
> }
>
> Return (OSFG)
> }
> Else
>
>
> So I expect if you apply no patch, but boot with 'acpi_osi="!Windows 2009"'
> then that would also work properly, as OSFG above will be set
> to "MSVT" instead of "OSLX".
>
> Looking through the DSDT, there are no references to OSLX or MSVT,
> or MSXP, for that matter. However, there is an additional reference
> to MSV7 in the temperature reading part of thermal zone TZ00,
> that looks like some sort of OS-specific initialization, perhaps
> a workaround. So also check that /proc/acpi/thermal_zone/*/temperature
> still work before and after.
>
> thanks,
> -Len Brown, Intel Open Source Technology Center
>
This kind of things is present on all newer eeepc.
I tried to contact asus about that, without real success and it is
likely that the xandros distribribution
shipped with some eeepc include an acpi blacklisiting patch.
The thing is that on win7 ASUS010 is disabled, but an equivalent wmi
interface is enable, and it could
be possible to write a driver for it. Now, someone need to write it,
or send me a free 1005HA so I can do it :).
If nothing is done for 2.6.34, we may need to envisage some blacklisting :/.
Thanks
--
Corentin Chary
http://xf.iksaif.net
Powered by blists - more mailing lists