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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1377301548.5259.91.camel@dvhart-mobl4.amr.corp.intel.com>
Date:	Fri, 23 Aug 2013 16:45:48 -0700
From:	Darren Hart <dvhart@...ux.intel.com>
To:	Matthew Garrett <mjg59@...f.ucam.org>
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 Sat, 2013-08-24 at 00:38 +0100, Matthew Garrett wrote:
> 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.
> 

OK. Thanks for elaborating.

It seems to me that in order to fully support this, we are back to the
problem of how do we provide arbitrary configuration data via ACPI (the
DSM being the only current means, but there is no standard there). Is
that still the hard problem we are looking to solve as a group?

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel


--
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/