From: nicolas.ferre@atmel.com (Nicolas Ferre)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] ARM: at91/Documentation: add a README for Atmel SoCs
Date: Tue, 13 Jan 2015 12:26:49 +0100 [thread overview]
Message-ID: <54B500F9.4000507@atmel.com> (raw)
In-Reply-To: <20150113020325.GB28758@quad.lixom.net>
Le 13/01/2015 03:03, Olof Johansson a ?crit :
> 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.
Yes, that was the intention.
Thanks, bye,
--
Nicolas Ferre
WARNING: multiple messages have this Message-ID (diff)
From: Nicolas Ferre <nicolas.ferre@atmel.com>
To: Olof Johansson <olof@lixom.net>
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: Tue, 13 Jan 2015 12:26:49 +0100 [thread overview]
Message-ID: <54B500F9.4000507@atmel.com> (raw)
In-Reply-To: <20150113020325.GB28758@quad.lixom.net>
Le 13/01/2015 03:03, Olof Johansson a écrit :
> 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.
Yes, that was the intention.
Thanks, bye,
--
Nicolas Ferre
next prev parent reply other threads:[~2015-01-13 11:26 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-09 13:20 [PATCH] ARM: at91/Documentation: add a README for Atmel SoCs Nicolas Ferre
2015-01-09 13:20 ` Nicolas Ferre
2015-01-13 2:03 ` Olof Johansson
2015-01-13 2:03 ` Olof Johansson
2015-01-13 11:26 ` Nicolas Ferre [this message]
2015-01-13 11:26 ` Nicolas Ferre
2015-01-13 11:26 ` Nicolas Ferre
2015-01-13 11:26 ` Nicolas Ferre
2015-01-13 11:36 ` Alexandre Belloni
2015-01-13 11:36 ` Alexandre Belloni
2015-01-13 13:40 ` Nicolas Ferre
2015-01-13 13:40 ` Nicolas Ferre
2015-01-15 14:27 ` 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=54B500F9.4000507@atmel.com \
--to=nicolas.ferre@atmel.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.