dt-bindings: amlogic: add unstable statement
Subsystems (2)
Kevin Hilman
maintainerPATCH 1/1 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.
--- Documentation/devicetree/bindings/arm/amlogic.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Documentation/devicetree/bindings/arm/amlogic.txt +12 -0
@@ -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"
Signature · 1 line
2.9.3
Jerome Brunet
reviewerPATCH 1/1 dt-bindings: amlogic: add unstable statement
Quoted 5 lines · Kevin Hilman
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.
Quoted 30 lines
Signed-off-by Kevin Hilman <[email protected]>---
?Documentation/devicetree/bindings/arm/amlogic.txt | 12 ++++++++++++ ?1 file changed, 12 insertions(+)Documentation/devicetree/bindings/arm/amlogic.txt +0
-0@@ -1,6 +1,18 @@?Amlogic MesonX device tree bindings
?-------------------------------------------
?Documentation/devicetree/bindings/arm/amlogic.txt +8
-0+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 ofa
Documentation/devicetree/bindings/arm/amlogic.txt +4
-0+stable binding/ABI. + +--------------------------------------------------------------- +?Boards with the Amlogic Meson6 SoC shall have the following properties:
???Required root node property:
?????compatible: "amlogic,meson6"
Rob Herring
maintainerPATCH 1/1 dt-bindings: amlogic: add unstable statement
In reply to Kevin HilmanQuoted 4 lines · Kevin Hilman
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/
Quoted 5 lines
Signed-off-by Kevin Hilman <[email protected]>--- 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,
PATCH 1/1 dt-bindings: amlogic: add unstable statement
Quoted 14 lines · Rob Herring
Quoted 4 lines · Kevin Hilman
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/
Quoted 5 lines
Signed-off-by Kevin Hilman <[email protected]>--- Documentation/devicetree/bindings/arm/amlogic.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Quoted 4 lines
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
Signature · 10 lines
Maxime Ripard, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-amlogic/attachments/20170705/3a5d9b5e/attachment.sig>
Rob Herring
maintainerQuoted 15 lines · Maxime Ripard
Quoted 14 lines · Rob Herring
Quoted 4 lines · Kevin Hilman
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/
Quoted 5 lines
Signed-off-by Kevin Hilman <[email protected]>--- Documentation/devicetree/bindings/arm/amlogic.txt | 12 ++++++++++++ 1 file changed, 12 insertions(+)
Quoted 7 lines
Quoted 4 lines
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?
I acked it, didn't I?
Quoted 4 lines
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?