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: <CACRpkdb-qwDrKUp4+5OzPQ_tJPGB4B69GmO__i-KwjFTETSYqw@mail.gmail.com>
Date:	Mon, 26 Aug 2013 11:32:44 +0200
From:	Linus Walleij <linus.walleij@...aro.org>
To:	Guenter Roeck <linux@...ck-us.net>
Cc:	Darren Hart <dvhart@...ux.intel.com>,
	Matthew Garrett <mjg59@...f.ucam.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	"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 Sat, Aug 24, 2013 at 2:13 AM, Guenter Roeck <linux@...ck-us.net> wrote:

> Did the group conclude that the idea of FDT augmenting ACPI is not feasible ?

I don't think anyone really knows. For example: how to specify a few
config options through a FDT augmented ACPI system is trivial. Passing
system-wide resources such as clocks, regulators, pin control handles,
GPIOs, interrupts and DMA channels is a criss-cross operation and
nobody knows if that will work because nobody tried to hash out
the details of.

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

It seems like we are in the "teenagers talking about sex" situation,
everybody is talking about it but nobody is really doing it.
Which makes it all pretty theoretical.

> 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).

For GPIO we have this:

drivers/gpio/gpiolib-of.c
drivers/gpio/gpiolib-acpi.c

So one thing is clear: for this resource we're going to have two
implementations.

Yours,
Linus Walleij
--
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/