| Message ID | 20191209093441.50694-2-maxime@cerno.tech (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [1/4] dt-bindings: sram: Allow for the childs nodes to be called sections | expand |
On Mon, 9 Dec 2019 10:34:39 +0100, Maxime Ripard wrote: > 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@cerno.tech> > --- > .../devicetree/bindings/sram/sram.yaml | 19 ++++++++++--------- > 1 file changed, 10 insertions(+), 9 deletions(-) > Applied, thanks. Rob
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:
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@cerno.tech> --- .../devicetree/bindings/sram/sram.yaml | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-)