dt-bindings: amlogic: add unstable statement

Due to the lack of documentation on this SoC family, discovery of new
features, and correcting of previous misunderstandings is expected, so
it's unrealistic to expect any form of stable bindings for this SoC
family.  Make that clear inthe binding documentation.

Signed-off-by: Kevin Hilman <khilman@baylibre.com>
---
 Documentation/devicetree/bindings/arm/amlogic.txt | 12 ++++++++++++
 1 file changed, 12 insertions(+)

On Wed, 2017-06-28 at 07:53 -0700, Kevin Hilman wrote:
> Due to the lack of documentation on this SoC family, discovery of new
> features, and correcting of previous misunderstandings is expected, so
> it's unrealistic to expect any form of stable bindings for this SoC
> family.  Make that clear inthe binding documentation.
> 

Acked-by: Jerome Brunet <jbrunet@baylibre.com>

> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
>  Documentation/devicetree/bindings/arm/amlogic.txt | 12 ++++++++++++
>  1 file changed, 12 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/arm/amlogic.txt
> b/Documentation/devicetree/bindings/arm/amlogic.txt
> index bfd5b558477d..9be902b4656d 100644
> --- a/Documentation/devicetree/bindings/arm/amlogic.txt
> +++ b/Documentation/devicetree/bindings/arm/amlogic.txt
> @@ -1,6 +1,18 @@
>  Amlogic MesonX device tree bindings
>  -------------------------------------------
>  
> +Work in progress statement:
> +
> +Device tree files and bindings applying to Amlogic SoCs and boards are
> +considered "unstable". Any Amlogic device tree binding may change at
> +any time. Be sure to use a device tree binary and a kernel image
> +generated from the same source tree.
> +
> +Please refer to Documentation/devicetree/bindings/ABI.txt for a definition of
> a
> +stable binding/ABI.
> +
> +---------------------------------------------------------------
> +
>  Boards with the Amlogic Meson6 SoC shall have the following properties:
>    Required root node property:
>      compatible: "amlogic,meson6"

--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, Jun 28, 2017 at 07:53:43AM -0700, Kevin Hilman wrote:
> Due to the lack of documentation on this SoC family, discovery of new
> features, and correcting of previous misunderstandings is expected, so
> it's unrealistic to expect any form of stable bindings for this SoC
> family.  Make that clear inthe binding documentation.

s/inthe/in the/

> 
> Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> ---
>  Documentation/devicetree/bindings/arm/amlogic.txt | 12 ++++++++++++
>  1 file changed, 12 insertions(+)

I've yet to see anyone remove an unstable tag and I'd rather see these 
for individual bindings than for the platform as a whole. In the end, 
it's a platform maintainers decision whether to accept compatibility 
breakage regardless of some text that probably no one reads.

In any case,

Acked-by: Rob Herring <robh@kernel.org>
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

On Wed, Jul 05, 2017 at 09:20:15AM -0500, Rob Herring wrote:
> On Wed, Jun 28, 2017 at 07:53:43AM -0700, Kevin Hilman wrote:
> > Due to the lack of documentation on this SoC family, discovery of new
> > features, and correcting of previous misunderstandings is expected, so
> > it's unrealistic to expect any form of stable bindings for this SoC
> > family.  Make that clear inthe binding documentation.
> 
> s/inthe/in the/
> 
> > 
> > Signed-off-by: Kevin Hilman <khilman@baylibre.com>
> > ---
> >  Documentation/devicetree/bindings/arm/amlogic.txt | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> 
> I've yet to see anyone remove an unstable tag and I'd rather see these 
> for individual bindings than for the platform as a whole. In the end, 
> it's a platform maintainers decision whether to accept compatibility 
> breakage regardless of some text that probably no one reads.

So what is the policy exactly to decide whether this statement can be
merged or not?

We have all the issues mentionned above, no backing from the vendor,
and yet, we were forced last year to bow down to one single "user"
without a clear usage into supporting a stable ABI that we never
really anticipated. How does that work exactly?

Maxime