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: <20140515141801.1E28BC4095B@trevor.secretlab.ca>
Date:	Thu, 15 May 2014 15:18:01 +0100
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Pantelis Antoniou <pantelis.antoniou@...sulko.com>
Cc:	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, 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.

Hi Pantelis,

Thanks for writing this up. A few responses below...

On Thu, 15 May 2014 00:12:17 -0700, Pantelis Antoniou <pantelis.antoniou@...sulko.com> wrote:
> On May 14, 2014, at 3:08 AM, Grant Likely wrote:
> > On Fri,  4 Apr 2014 15:43:55 +0300, Pantelis Antoniou <pantelis.antoniou@...sulko.com> wrote:
> > The notification infrastructure bothers me. It duplicates the
> > notification that the core DT code already performs. I do understand
> > that the current notifications don't do what you need them to because
> > you need it all deferred until the complete set of batch changes are
> > applied. However, instead of creating a new infrastructure, the existing
> > notifier should be reworked to be batch-change aware.
> > 
> 
> If I understood correctly, you're asking of rolling in this per-bus notifier
> mechanism in the standard DT notifier infrastructure already in place.
> I can't be absolutely sure about the details right now, but seems possible.
> 
> I don't know if the kernel notifier framework will be unmodified, but I hope so.

It should be. It will need to be the dt code that buffers up the
notification events to be played out after the batch of changes has been
applied. That shouldn't have any impact on core notifier framework.

[...]
> > Is it the base DT that needs the __symbols__ node, or the overlay tree?
> > I had thought it was the overlay tree that contained the __symbols__
> > node. Regardless, this is the first mention in this file of __symbols__.
> > It would be good to discuss briefly how it works.
> > 
> 
> The __symbols__ usage is explained in the resolve patch.
> Since target-path has been added the base DT no longer needs a __symbols__ node.

Can the target-phandle method be removed entirely then?

> >> diff --git a/drivers/of/Kconfig b/drivers/of/Kconfig
> >> index 4d39c88..cfb7ff8 100644
> >> --- a/drivers/of/Kconfig
> >> +++ b/drivers/of/Kconfig
> >> @@ -86,4 +86,14 @@ config OF_RESOLVE
> >> 	  Enable OF dynamic resolution support. This allows you to
> >> 	  load Device Tree object fragments are run time.
> >> 
> >> +config OF_OVERLAY
> >> +	bool "OF overlay support"
> >> +	depends on OF
> >> +	select OF_DYNAMIC
> >> +	select OF_DEVICE
> >> +	select OF_RESOLVE
> >> +	help
> >> +	  OpenFirmware overlay support. Allows you to modify on runtime the
> >> +	  live tree using overlays.
> > 
> > Should not be a user-visable option. Drivers using it should select it
> > or otherwise cause it to be enabled.
> 
> Hmm. I don't know; if I let it up to drivers, platform devices will select it, in turn
> making it always selected for 99.9% of the platforms out there.
> 
> Some people might not want to incur the code size penalty.

The only code ever selecting this function would be code that actually
calls the overlay functions.

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/