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: <20130824001345.GD14810@roeck-us.net>
Date:	Fri, 23 Aug 2013 17:13:45 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Darren Hart <dvhart@...ux.intel.com>
Cc:	Matthew Garrett <mjg59@...f.ucam.org>,
	"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>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: ACPI vs Device Tree - moving forward

On Fri, Aug 23, 2013 at 04:45:48PM -0700, Darren Hart wrote:
> 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?
> 
Did the group conclude that the idea of FDT augmenting ACPI is not feasible ? 

If not, the key question for me is how to implement it, and how to handle
all its little problems.

If yes, the key question for me is how to handle all the drivers which
assume fdt-style properties, and how to express all that information in ACPI
in a way which does not require a substantial driver rewrite (and, as you point
out, how that data would be described in ACPI consistently across multiple
vendors).

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