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: <24185074.ohppXxCEri@vostro.rjw.lan>
Date:	Tue, 20 Aug 2013 23:13:44 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Matthew Garrett <mjg59@...f.ucam.org>
Cc:	Darren Hart <dvhart@...ux.intel.com>, linux-kernel@...r.kernel.org,
	linux-acpi@...r.kernel.org, linux@...ck-us.net, hpa@...or.com,
	linus.walleij@...aro.org
Subject: Re: ACPI vs Device Tree - moving forward

On Tuesday, August 20, 2013 09:57:13 PM Matthew Garrett wrote:
> On Tue, Aug 20, 2013 at 01:51:03PM -0700, Darren Hart wrote:
> 
> > It seems to me that the only way to end up in a situation where the data
> > is reused by other OSes, is to go through a standards body. What about
> > attempting to standardize the _DSM method? I suppose the challenge then
> > is how do we standardize arbitrary data (which, of course, is an
> > oxymoron)...
> 
> Right. We could certainly spec the DT bindings that currently exist, but 
> the obvious pushback is that large chunks of it *are* already in ACPI - 
> a _PS0 method (which is ACPI for "Power up the device") that toggles a 
> GPIO pin, and then provides a different GPIO pin in the DT data, which 
> would we believe?
> 
> > The interesting thing about this to me is that many of these devices are
> > added after-the-fact (as add-on boards, for example). With the
> > MinnowBoard we are looking to provide this configuration data in an
> > EEPROM. Would it make sense for the device manufacturer (rather than the
> > base-board manufacturer) to define the key-value pairs for their
> > hardware?
> 
> Yes, hardware information that's on add-in boards should probably be 
> provided by the add-in board if it carries a ROM. This is trivial on 
> UEFI systems - you just need a UEFI driver for the board that can 
> construct an appropriate SSDT. It's more of a problem for non-UEFI ACPI 
> systems.
> 
> > Sadly, I will not be in New Orleans and am unlikely to receive a Kernel
> > Summit invite, but I am planning be in Edinburgh and would like the
> > opportunity to participate in this discussion.
> 
> I'm not planning on being at kernel summit this year, so I think we'll 
> try to arrange something around that time but outside the event.

Well, I'm attending the KS, however, so I'd prefer them not to conflict
with each other if possible.

Thanks,
Rafael

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