linux-kernel - Re: [PATCH v4 2/8] OF: Introduce DT overlay support.

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: <20140527121140.1BCE9C40A5A@trevor.secretlab.ca>
Date:	Tue, 27 May 2014 13:11:40 +0100
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Geert Uytterhoeven <geert@...ux-m68k.org>
Cc:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>,
	Rob Herring <robherring2@...il.com>,
	Stephen Warren <swarren@...dotorg.org>,
	Matt Porter <matt.porter@...aro.org>,
	Koen Kooi <koen@...inion.thruhere.net>,
	Alison Chaiken <Alison_Chaiken@...tor.com>,
	Dinh Nguyen <dinh.linux@...il.com>,
	Jan Lubbe <jluebbe@...net.de>,
	Alexander Sverdlin <alexander.sverdlin@....com>,
	Michael Stickel <ms@...able.de>,
	Guenter Roeck <linux@...ck-us.net>,
	Dirk Behme <dirk.behme@...il.com>,
	Alan Tull <delicious.quinoa@...il.com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Michael Bohan <mbohan@...eaurora.org>,
	Ionut Nicu <ioan.nicu.ext@....com>,
	Michal Simek <monstr@...str.eu>,
	Matt Ranostay <mranostay@...il.com>,
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Pete Popov <pete.popov@...sulko.com>,
	Dan Malek <dan.malek@...sulko.com>,
	Georgi Vlaev <georgi.vlaev@...sulko.com>
Subject: Re: [PATCH v4 2/8] OF: Introduce DT overlay support.

On Mon, 26 May 2014 23:44:41 +0200, Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
> Hi Grant,
> 
> On Mon, May 26, 2014 at 11:33 PM, Grant Likely
> <grant.likely@...retlab.ca> wrote:
> > After thinking about it more, I think it is very likely that removing
> > all the overlays is the correct thing to do in the kexec use-case. When
> > kexec-ing, it makes sense that we'd want the exact same behaviour from
> > the kexec'ed kernel. That means we want the device drivers to do the
> > same thing including loading whatever overlays they depend on.
> 
> Are the device drivers loading the overlays?
> That sounds a bit backwards to me.

In a lot of cases, yes. For example, the beaglebone capebus driver would
be responsible for identifying and requesting or loading the correct
overlay to describe the hardware.

Having userspace provide an arbitrary overlay is only one of the use
cases.

g.

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