linux-kernel - Re: [Linaro-acpi] [PATCH v5 18/18] Documentation: ACPI for ARM64

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: <3341506.a2BFqPNg3k@wuerfel>
Date:	Fri, 09 Jan 2015 11:55:51 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	linux-arm-kernel@...ts.infradead.org
Cc:	Catalin Marinas <catalin.marinas@....com>,
	Rob Herring <robh@...nel.org>,
	Daniel Lezcano <daniel.lezcano@...aro.org>,
	Robert Richter <rric@...nel.org>,
	Jason Cooper <jason@...edaemon.net>,
	"linaro-acpi@...ts.linaro.org" <linaro-acpi@...ts.linaro.org>,
	Marc Zyngier <Marc.Zyngier@....com>,
	"jcm@...hat.com" <jcm@...hat.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	Liviu Dudau <Liviu.Dudau@....com>,
	Robert Moore <robert.moore@...el.com>,
	Will Deacon <Will.Deacon@....com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>,
	Mark Brown <broonie@...nel.org>,
	"Rafael J. Wysocki" <rjw@...ysocki.net>,
	Lv Zheng <lv.zheng@...el.com>,
	Bjorn Helgaas <bhelgaas@...gle.com>,
	Olof Johansson <olof@...om.net>
Subject: Re: [Linaro-acpi] [PATCH v5 18/18] Documentation: ACPI for ARM64

On Friday 09 January 2015 10:33:07 Catalin Marinas wrote:
> On Wed, Jan 07, 2015 at 07:48:48PM +0000, Arnd Bergmann wrote:

> > In other cases that's actually a good thing. One such example is the
> > "Principles of ARM Memory Maps" document that tells hardware implementers
> > to do a rather complex mapping "To support 36-bit x86 PAE compatible operating
> > systems, such as Linux." but makes life much harder in the process than
> > any of the random mappings we have seen in the wild.
> 
> Unfortunately, with any significant amount of RAM (say 16GB), this
> document becomes pretty useless. It basically forces you to have a very
> sparse physical address map from 0 to over 40-bit. I wouldn't apply the
> ARM memory maps doc to server systems.

Are you sure? I was under the impression that this document was targetted
specifically at servers.

> >   It's also not just the CPU core, other components also get easily
> >   replaced, like a GICv3 that is not a strict superset of GICv2.
> 
> That's not a problem for Linux, we can describe them in DT or ACPI and
> have drivers. GICv3 has an optional GICv2 compatible mode, though
> vendors may decide not to implement it.

I'm aware that we can deal with it after we have the drivers. My point
was that we are unable to deal with this problem in general if we want
to run existing kernels on new hardware that contains e.g. a GICv4/5/6
that requires a new driver which has to first be written and then
backported into distro kernels.

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