On 11/08/17 08:38, Rob Herring wrote:

On Mon, Aug 07, 2017 at 01:46:39PM +1200, Chris Packham wrote:

quoted

Some SoC implementations that use this controller have a reduced pin
count so the meaning of "full" and "half" with change.

s/with/width/ ?

Yes will include in v2.

quoted

Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
---
  .../bindings/memory-controllers/mvebu-sdram-controller.txt          | 6 ++++++
  1 file changed, 6 insertions(+)

diff --git a/Documentation/devicetree/bindings/memory-controllers/mvebu-sdram-controller.txt b/Documentation/devicetree/bindings/memory-controllers/mvebu-sdram-controller.txt
index 89657d1d4cd4..3041868321c8 100644
--- a/Documentation/devicetree/bindings/memory-controllers/mvebu-sdram-controller.txt
+++ b/Documentation/devicetree/bindings/memory-controllers/mvebu-sdram-controller.txt

@@ -13,6 +13,12 @@ Required properties:
   - reg: a resource specifier for the register space, which should
     include all SDRAM controller registers as per the datasheet.
  
+Optional properties:
+ - marvell,reduced-width: some SoCs that use this SDRAM controller have
+   a reduced pin count. On such systems "full" width is 32-bits and
+   "half" width is 16-bits. Set this property to indicate that the SoC
+   used is such a system.

Maybe you should just state what the width is.

Specifying a number like 64/32/16 is done in for some other properties I 
dismissed that because what this is about how we interpret a 
pin-strapping option. I guess "max-width = <64>;" and "max-width = 
<32>"; would achieve the same.

Or your compatible string should just be specific enough to know the
width.

I decided against a new compatible sting that because the IP block 
really is the Armada-XP one and the existing compatible string is used 
in other places (using multiple compatible strings would solve that).

I'm not too fussed which of the 3 options are used. Is there any 
particular preference?
---
To unsubscribe from this list: send the line "unsubscribe linux-edac" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html