Even though the generic mmio-sram binding has a list of the sections
compatible allowed, most device trees have more specific compatibles
attached to those generic ones.
This creates warnings at the moment, and we don't really want to cripple
the generic binding with all the vendor specific combinations that would
prove to be hard to maintain.
Let's allow additional compatibles for the sections, and then we can have
the vendor-specific bindings to reduce the scope of what's allowed exactly.
Signed-off-by: Maxime Ripard <maxime@xxxxxxxxxx>
---
.../devicetree/bindings/sram/sram.yaml | 19 ++++++++++---------
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml
index 83e3bc64d6fc..9ffef983510b 100644
--- a/Documentation/devicetree/bindings/sram/sram.yaml
+++ b/Documentation/devicetree/bindings/sram/sram.yaml
@@ -64,15 +64,16 @@ patternProperties:
description:
Should contain a vendor specific string in the form
<vendor>,[<device>-]<usage>
- enum:
- - allwinner,sun9i-a80-smp-sram
- - amlogic,meson8-smp-sram
- - amlogic,meson8b-smp-sram
- - renesas,smp-sram
- - rockchip,rk3066-smp-sram
- - samsung,exynos4210-sysram
- - samsung,exynos4210-sysram-ns
- - socionext,milbeaut-smp-sram
+ contains:
+ enum:
+ - allwinner,sun9i-a80-smp-sram
+ - amlogic,meson8-smp-sram
+ - amlogic,meson8b-smp-sram
+ - renesas,smp-sram
+ - rockchip,rk3066-smp-sram
+ - samsung,exynos4210-sysram
+ - samsung,exynos4210-sysram-ns
+ - socionext,milbeaut-smp-sram
reg:
description:
--
2.23.0
