LPDDR and DDR bindings use the same properties (at least for density,
io-width and reg).
To avoid bindings duplication, factorise the properties.

The compatible description has been updated because the MR (Mode
registers) used to get manufacturer ID and revision ID are not present
in case of DDR.
Those information should be in a SPD (Serial Presence Detect) EEPROM in
case of DIMM module or are known in case of soldered memory chips as
they are in the datasheet of the memory chips.

Signed-off-by: Clément Le Goffic <clement.legoffic@foss.st.com>
---
 .../memory-controllers/ddr/jedec,lpddr2.yaml       |  2 +-
 .../memory-controllers/ddr/jedec,lpddr3.yaml       |  2 +-
 .../memory-controllers/ddr/jedec,lpddr4.yaml       |  2 +-
 .../memory-controllers/ddr/jedec,lpddr5.yaml       |  2 +-
 ...ec,lpddr-props.yaml => jedec,memory-props.yaml} | 24 +++++++++++++---------
 5 files changed, 18 insertions(+), 14 deletions(-)

diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml
index a237bc259273..f290a25675b2 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml
@@ -10,7 +10,7 @@ maintainers:
   - Krzysztof Kozlowski <krzk@kernel.org>
 
 allOf:
-  - $ref: jedec,lpddr-props.yaml#
+  - $ref: jedec,memory-props.yaml#
 
 properties:
   compatible:
diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml
index e328a1195ba6..994127dbcdca 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml
@@ -10,7 +10,7 @@ maintainers:
   - Krzysztof Kozlowski <krzk@kernel.org>
 
 allOf:
-  - $ref: jedec,lpddr-props.yaml#
+  - $ref: jedec,memory-props.yaml#
 
 properties:
   compatible:
diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr4.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr4.yaml
index a078892fecee..753376a3ad1f 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr4.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr4.yaml
@@ -10,7 +10,7 @@ maintainers:
   - Krzysztof Kozlowski <krzk@kernel.org>
 
 allOf:
-  - $ref: jedec,lpddr-props.yaml#
+  - $ref: jedec,memory-props.yaml#
 
 properties:
   compatible:
diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr5.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr5.yaml
index e441dac5f154..27e2bbdb631d 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr5.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr5.yaml
@@ -10,7 +10,7 @@ maintainers:
   - Krzysztof Kozlowski <krzk@kernel.org>
 
 allOf:
-  - $ref: jedec,lpddr-props.yaml#
+  - $ref: jedec,memory-props.yaml#
 
 properties:
   compatible:
diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,memory-props.yaml
similarity index 72%
rename from Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml
rename to Documentation/devicetree/bindings/memory-controllers/ddr/jedec,memory-props.yaml
index 30267ce70124..0bc919fd8b53 100644
--- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr-props.yaml
+++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,memory-props.yaml
@@ -1,16 +1,16 @@
 # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
 %YAML 1.2
 ---
-$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr-props.yaml#
+$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,memory-props.yaml#
 $schema: http://devicetree.org/meta-schemas/core.yaml#
 
-title: Common properties for LPDDR types
+title: Common properties for memory types
 
 description:
-  Different LPDDR types generally use the same properties and only differ in the
+  Different memory types generally use the same properties and only differ in the
   range of legal values for each. This file defines the common parts that can be
   reused for each type. Nodes using this schema should generally be nested under
-  an LPDDR channel node.
+  an memory channel node.
 
 maintainers:
   - Krzysztof Kozlowski <krzk@kernel.org>
@@ -21,14 +21,15 @@ properties:
       Compatible strings can be either explicit vendor names and part numbers
       (e.g. elpida,ECB240ABACN), or generated strings of the form
       lpddrX-YY,ZZZZ where X is the LPDDR version, YY is the manufacturer ID
-      (from MR5) and ZZZZ is the revision ID (from MR6 and MR7). Both IDs are
-      formatted in lower case hexadecimal representation with leading zeroes.
+      (from MR5 in case of LPDDR) and ZZZZ is the revision ID (from MR6 and MR7
+      in case of LPDDR). Both IDs are formatted in lower case hexadecimal
+      representation with leading zeroes.
       The latter form can be useful when LPDDR nodes are created at runtime by
       boot firmware that doesn't have access to static part number information.
 
   reg:
     description:
-      The rank number of this LPDDR rank when used as a subnode to an LPDDR
+      The rank number of this memory rank when used as a subnode to an memory
       channel.
     minimum: 0
     maximum: 3
@@ -36,7 +37,8 @@ properties:
   revision-id:
     $ref: /schemas/types.yaml#/definitions/uint32-array
     description:
-      Revision IDs read from Mode Register 6 and 7. One byte per uint32 cell (i.e. <MR6 MR7>).
+      Revision IDs read from Mode Register 6 and 7 in case of LPDDR.
+      One byte per uint32 cell (i.e. <MR6 MR7>).
     maxItems: 2
     items:
       minimum: 0
@@ -45,7 +47,8 @@ properties:
   density:
     $ref: /schemas/types.yaml#/definitions/uint32
     description:
-      Density in megabits of SDRAM chip. Decoded from Mode Register 8.
+      Density in megabits of SDRAM chip. Decoded from Mode Register 8 in case of
+      LPDDR.
     enum:
       - 64
       - 128
@@ -65,7 +68,8 @@ properties:
   io-width:
     $ref: /schemas/types.yaml#/definitions/uint32
     description:
-      IO bus width in bits of SDRAM chip. Decoded from Mode Register 8.
+      IO bus width in bits of SDRAM chip. Decoded from Mode Register 8 in case
+      of LPDDR.
     enum:
       - 8
       - 16

-- 
2.43.0

>        Compatible strings can be either explicit vendor names and part numbers
>        (e.g. elpida,ECB240ABACN), or generated strings of the form
>        lpddrX-YY,ZZZZ where X is the LPDDR version, YY is the manufacturer ID

When you say "in case of LPDDR" below, you should also change this
line to take other cases into account. Maybe the best way to write
this would be something like:

...or generated strings of a memory type dependent form. For LPDDR
types, that form is lpddrX-YY,ZZZZ where X is [...same text...]. For
DDR types, that form is ddrX-YY,ZZZZZ... where X is [...new definition
for DDR types, based on what's available in SPD...].

>    revision-id:
>      $ref: /schemas/types.yaml#/definitions/uint32-array
>      description:
> -      Revision IDs read from Mode Register 6 and 7. One byte per uint32 cell (i.e. <MR6 MR7>).
> +      Revision IDs read from Mode Register 6 and 7 in case of LPDDR.
> +      One byte per uint32 cell (i.e. <MR6 MR7>).

If this doesn't exist for DDR, then rather than "in case of LPDDR"
this should probably say something like "LPDDR only"?

>    density:
>      $ref: /schemas/types.yaml#/definitions/uint32
>      description:
> -      Density in megabits of SDRAM chip. Decoded from Mode Register 8.
> +      Density in megabits of SDRAM chip. Decoded from Mode Register 8 in case of
> +      LPDDR.

Can you list here where in SPD density and I/O width are stored for
the various DDR types?

Hi Julius,

Thanks for the review.

On 7/22/25 23:57, Julius Werner wrote:
>>         Compatible strings can be either explicit vendor names and part numbers
>>         (e.g. elpida,ECB240ABACN), or generated strings of the form
>>         lpddrX-YY,ZZZZ where X is the LPDDR version, YY is the manufacturer ID
> 
> When you say "in case of LPDDR" below, you should also change this
> line to take other cases into account. Maybe the best way to write
> this would be something like:
> 
> ...or generated strings of a memory type dependent form. For LPDDR
> types, that form is lpddrX-YY,ZZZZ where X is [...same text...]. For
> DDR types, that form is ddrX-YY,ZZZZZ... where X is [...new definition
> for DDR types, based on what's available in SPD...].

Yes I agree and if there is no SPD I'll mention the datasheet of the 
memory chip.

> 
>>     revision-id:
>>       $ref: /schemas/types.yaml#/definitions/uint32-array
>>       description:
>> -      Revision IDs read from Mode Register 6 and 7. One byte per uint32 cell (i.e. <MR6 MR7>).
>> +      Revision IDs read from Mode Register 6 and 7 in case of LPDDR.
>> +      One byte per uint32 cell (i.e. <MR6 MR7>).
> 
> If this doesn't exist for DDR, then rather than "in case of LPDDR"
> this should probably say something like "LPDDR only"?

It exists in case of DDR, but it is either in the SPD if the memory is 
DIMM like or in the datasheet for soldered memory chip.

> 
>>     density:
>>       $ref: /schemas/types.yaml#/definitions/uint32
>>       description:
>> -      Density in megabits of SDRAM chip. Decoded from Mode Register 8.
>> +      Density in megabits of SDRAM chip. Decoded from Mode Register 8 in case of
>> +      LPDDR.
> 
> Can you list here where in SPD density and I/O width are stored for
> the various DDR types?

I'll try to find the info and yes.

Best regards,
Clément