linux-kernel - Re: [PATCH v2 1/5] drivers: of: add initialization code for reserved memory

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: <20140217164708.B332BC403B4@trevor.secretlab.ca>
Date:	Mon, 17 Feb 2014 16:47:08 +0000
From:	Grant Likely <grant.likely@...aro.org>
To:	Tomasz Figa <tomasz.figa@...il.com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Cc:	Tomasz Figa <t.figa@...sung.com>,
	Marek Szyprowski <m.szyprowski@...sung.com>,
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
	linaro-mm-sig@...ts.linaro.org, devicetree@...r.kernel.org,
	linux-doc@...r.kernel.org,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Arnd Bergmann <arnd@...db.de>,
	Michal Nazarewicz <mina86@...a86.com>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Laura Abbott <lauraa@...eaurora.org>,
	Rob Herring <robh+dt@...il.com>,
	Olof Johansson <olof@...om.net>,
	Pawel Moll <pawel.moll@....com>,
	Mark Rutland <mark.rutland@....com>,
	Stephen Warren <swarren@...dotorg.org>,
	Ian Campbell <ian.campbell@...rix.com>,
	Kumar Gala <galak@...eaurora.org>,
	Nishanth Peethambaran <nishanth.p@...il.com>,
	Marc <marc.ceeeee@...il.com>,
	Josh Cartwright <joshc@...eaurora.org>
Subject: Re: [PATCH v2 1/5] drivers: of: add initialization code for reserved memory

On Tue, 11 Feb 2014 21:04:21 +0100, Tomasz Figa <tomasz.figa@...il.com> wrote:
> 
> 
> On 11.02.2014 21:02, Benjamin Herrenschmidt wrote:
> > On Tue, 2014-02-11 at 19:01 +0000, Grant Likely wrote:
> >
> >>> except that the former IMHO better suits the definition of memory
> >>> region, which I see as a single contiguous range of memory and can be
> >>> simplified to have a single reg entry per region.
> >>
> >> My point is rather if multiple reg tuples are found in a reserved memory
> >> node, the kernel must respect them and reserve the memory. I'm not
> >> arguing about whether or not that makes for a good binding.
> >
> > agreed.
> 
> My point is why, if the binding defines that just a single tuple should 
> be provided.

It's irrelevant because it gets processed at a different level. It's
important that the core early setup code can quickly parse all the
reserved regions without having any idea what the end-user binding is.
Multiple reg tuples is just fine in this regard.

Whether or not multiple tuples makes sense is defined for each
particular use case by the driver actually using it without impacting
core initialization code one iota.

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/