linux-kernel - Re: [PATCH] libata_acpi: A different strategy for using ACPI information

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 04 Jul 2007 12:49:19 +0900
From:	Tejun Heo <htejun@...il.com>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	linux-ide@...r.kernel.org, linux-kernel@...r.kernel.org,
	jeff@...zik.org
Subject: Re: [PATCH] libata_acpi: A different strategy for using ACPI information

Alan Cox wrote:
> Lots of BIOSen simply return the BIOS set modes via the ACPI methods and
> pass back the values you give it across suspend/resume. Thus instead of
> trying to do clever stuff with this data we instead use it as a way to
> take a sneak peak at cable type information when viable. This should help
> us catch more of the laptops that do weird stuff, the VIA SATA bridges
> and the totally horked Nvidia cable handling.
> 
> For now its only used by the VIA and AMD/NV driver until we get a better
> idea of whether this is a sensible idea or not.
> 
> Opinions ?

If you don't do _STM first, it basically boils down to reading BIOS
setting during boot.  Over suspend/resume cycle, the values are
preserved by libata-acpi.  At this point, I think honoring the BIOS
setting is the right thing to do.  It just took us too long and I'm not
too sure about using ACPI for this.  It's generic so it's certainly
better in some aspect.  It's just a bit obfuscating, IMHO.

-- 
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/