linux-kernel - Re: ACPI vs Device Tree

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130823233805.GA1801@srcf.ucam.org>
Date:	Sat, 24 Aug 2013 00:38:05 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Darren Hart <dvhart@...ux.intel.com>
Cc:	"Rafael J. Wysocki" <rjw@...k.pl>,
	Linus Walleij <linus.walleij@...aro.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	ACPI Devel Maling List <linux-acpi@...r.kernel.org>,
	Guenter Roeck <linux@...ck-us.net>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: ACPI vs Device Tree - moving forward

On Fri, Aug 23, 2013 at 04:25:43PM -0700, Darren Hart wrote:

> It had been my hope at the start of this project to open the creation of
> SSDTs up to inventors and hackers who want to create Lures for the
> MinnowBoard in such a way that they could write these SSDTs and load
> them from a file at boot time, modify, rebuild, iterate, etc. When/if
> the Lure goes to production, the SSDT could either be stored on an
> EEPROM, or for very low volume boards, possibly just shipped as a binary
> to be loaded (with source available of course).

There's no fundamental problem with doing this, especially on UEFI 
systems. As long as you know the host ACPI code, it's trivial to merge 
an SSDT in from a UEFI option ROM.

> It appears that Matthew, at least, would prefer this latter scenario
> just used DT instead. However, that seems to leave a gap in the
> transition to incorporating the table into the board firmware should a
> derivative product be made. e.g. no good way to prototype with ACPI. It
> also seems to have all the same problems raised regarding mixing ACPI
> and DT on the same system.

I've no problem with additional hardware shipping with ACPI support - my 
position was more that if a vendor ships a system with ACPI that fails 
to describe the integrated hardware (or does so incorrectly), it's 
probably easier to replace it with DT than a fixed ACPI table. Still, if 
people *do* want to replace shipped ACPI tables, it's probably 
preferable to do that at the bootloader level than the kernel level.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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/