[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140203045402.GA4167@cbox>
Date: Sun, 2 Feb 2014 20:54:02 -0800
From: Christoffer Dall <christoffer.dall@...aro.org>
To: Ian Campbell <ian.campbell@...rix.com>
Cc: linux-kernel@...r.kernel.org, Mark Rutland <mark.rutland@....com>,
devicetree@...r.kernel.org, Pawel Moll <pawel.moll@....com>,
Stefano Stabellini <stefano.stabellini@...citrix.com>,
Marc Zyngier <marc.zyngier@....com>,
Will Deacon <will.deacon@....com>,
Rob Herring <robh+dt@...nel.org>,
Arnd Bergmann <arnd@...db.de>,
Kumar Gala <galak@...eaurora.org>,
Olof Johansson <olof@...om.net>,
linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] arm: document "mach-virt" platform.
On Thu, Jan 30, 2014 at 04:11:02PM +0000, Ian Campbell wrote:
> mach-virt has existed for a while but it is not written down what it actually
> consists of. Although it seems a bit unusual to document a binding for an
> entire platform since mach-virt is entirely virtual it is helpful to have
> something to refer to in the absence of a single concrete implementation.
>
> I've done my best to capture the requirements based on the git log and my
> memory/understanding.
[...]
>
> +
> +The platform may also provide hypervisor specific functionality
> +(e.g. PV I/O), if it does so then this functionality must be
> +discoverable (directly or indirectly) via device tree.
While this is obviously true, I'm not sure I see the value of this text.
Isn't it more essential to just say that *any* functionality provided to
the platform must be discoverable via device tree?
-Christoffer
--
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/
Powered by blists - more mailing lists