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]

Date:	Thu, 22 Aug 2013 01:03:06 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
Cc:	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>,
	Darren Hart <dvhart@...ux.intel.com>,
	"H. Peter Anvin" <hpa@...or.com>
Subject: Re: ACPI vs Device Tree - moving forward

On Thu, Aug 22, 2013 at 02:02:29AM +0200, Rafael J. Wysocki wrote:

> And now the practice appears to be that vendors actually ship some ACPI
> tables with their systems, but those ACPI tables do not contain information
> needed to enumerate all devices.  On the other hand, it is known what the
> DT bindings for the missing part should be.  How can we address this?

On ARM? I know that this is true on x86, but that's because x86 vendors 
have never intended i2c hardware monitoring devices be driven by a 
general purpoes OS - they're there for the benefit of the firmware, not 
anything above that.

> Next, say we have a driver written with DT bindings in mind and there's
> an ACPI-based system with identical hardware, although wired up slightly
> differently.  Say that all of the information needed by that driver is
> there in the ACPI tables (Q: How the vendor is supposed to know what
> information the driver expects?).  Who is supposed to take care of updating
> the driver to be able to use ACPI in addition to DTs?

Ideally we have a consistent in-kernel representation of this 
information and drivers don't need to care about whether it came from DT 
or ACPI, but like I said, that's going to be tricky.

> I don't honestly think that the "ask vendors to ship their systems with correct
> ACPI tables" approach will take us anywhere.

It's worked well enough on x86. If hardware vendors don't actually test 
that their hardware is able to boot the OS it's intended to run then 
there's very little we can do about that - and the worst case outcome is 
that people just ignore the shipped ACPI and use FDT.

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