From: Olof Johansson <olof@lixom.net>
To: Nicolas Ferre <nicolas.ferre@atmel.com>
Cc: linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, Arnd Bergmann <arnd@arndb.de>,
khilman@kernel.org,
Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>,
Boris BREZILLON <boris.brezillon@free-electrons.com>,
Alexandre Belloni <alexandre.belloni@free-electrons.com>,
Patrice Vilchez <patrice.vilchez@atmel.com>,
Ludovic Desroches <ludovic.desroches@atmel.com>,
Cyrille Pitchen <cyrille.pitchen@atmel.com>,
ARM Maintainers <arm@kernel.org>
Subject: Re: [PATCH] ARM: at91/Documentation: add a README for Atmel SoCs
Date: Mon, 12 Jan 2015 18:03:25 -0800 [thread overview]
Message-ID: <20150113020325.GB28758@quad.lixom.net> (raw)
In-Reply-To: <1420809631-26923-1-git-send-email-nicolas.ferre@atmel.com>
On Fri, Jan 09, 2015 at 02:20:31PM +0100, Nicolas Ferre wrote:
> Add a README file to describe Atmel SoCs (aka AT91) support in Mainline Linux:
> - SoC list + datasheet web links
> - Basic but useful information
> - Device Tree conventions and Work In Progress statement.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> Cc: ARM Maintainers <arm@kernel.org>
Acked-by: Olof Johansson <olof@lixom.net>
With the understanding that:
> +Device Tree for AT91 SoCs and boards
> +------------------------------------
> +All AT91 SoCs are converted to Device Tree. Since Linux 3.19, these products
> +must use this method to boot the Linux kernel.
> +
> +Work In Progress statement:
> +Device Tree files and Device Tree bindings that apply to AT91 SoCs and boards are
> +considered as "Unstable". To be completely clear, any at91 binding can change at
> +any time. So, be sure to use a Device Tree Binary and a Kernel Image generated from
> +the same source tree.
> +Please refer to the Documentation/devicetree/bindings/ABI.txt file for a
> +definition of a "Stable" binding/ABI.
> +This statement will be removed by AT91 MAINTAINERS when appropriated.
While this statement is here, at the end of the day if you break a user
you're responsible for fixing them. I.e. if a tree falls in the forest
and nobody notices, then so be it.
But you can't break existing users and point to this and get away with
it. However, hopefully based on this doc users will go with practices
that means that you can revise bindings if you have to.
-Olof
next prev parent reply other threads:[~2015-01-13 2:03 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-09 13:20 Nicolas Ferre
2015-01-13 2:03 ` Olof Johansson [this message]
2015-01-13 11:26 ` Nicolas Ferre
2015-01-13 11:26 ` Nicolas Ferre
2015-01-13 11:36 ` Alexandre Belloni
2015-01-13 13:40 ` Nicolas Ferre
2015-01-15 14:27 ` Nicolas Ferre
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20150113020325.GB28758@quad.lixom.net \
--to=olof@lixom.net \
--cc=alexandre.belloni@free-electrons.com \
--cc=arm@kernel.org \
--cc=arnd@arndb.de \
--cc=boris.brezillon@free-electrons.com \
--cc=cyrille.pitchen@atmel.com \
--cc=khilman@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=ludovic.desroches@atmel.com \
--cc=nicolas.ferre@atmel.com \
--cc=patrice.vilchez@atmel.com \
--cc=plagnioj@jcrosoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®