Enable access to memory resources not only via I/O address using reg,
but also through a portion of main memory using memory-region. To
achieve this, new compatible strings have been introduced: mtd-mem and
mtd-memro.

Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>
---
 .../devicetree/bindings/mtd/mtd-physmap.yaml       | 69 ++++++++++++++++------
 1 file changed, 52 insertions(+), 17 deletions(-)

diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml
index a9ec3ca002c7d..98d45982d8eb9 100644
--- a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml
+++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml
@@ -13,10 +13,6 @@ description: |
   Flash chips (Memory Technology Devices) are often used for solid state
   file systems on embedded devices.
 
-allOf:
-  - $ref: mtd.yaml#
-  - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml#
-
 properties:
   compatible:
     oneOf:
@@ -61,6 +57,8 @@ properties:
           - jedec-flash
           - mtd-ram
           - mtd-rom
+          - mtd-mem
+          - mtd-memro
 
   reg:
     description: |
@@ -141,19 +139,37 @@ required:
   - compatible
   - reg
 
-if:
-  properties:
-    compatible:
-      contains:
-        const: cortina,gemini-flash
-then:
-  properties:
-    syscon:
-      $ref: /schemas/types.yaml#/definitions/phandle
-      description:
-        Phandle to the syscon controller
-  required:
-    - syscon
+allOf:
+  - if:
+      properties:
+        compatible:
+          contains:
+            const: cortina,gemini-flash
+    then:
+      properties:
+        syscon:
+          $ref: /schemas/types.yaml#/definitions/phandle
+          description:
+            Phandle to the syscon controller
+          required:
+            - syscon
+  - if:
+      properties:
+        compatible:
+          contains:
+            enum:
+              - mtd-mem
+              - mtd-memro
+    then:
+      $ref: /schemas/reserved-memory/reserved-memory.yaml
+      required:
+        - no-map
+      properties:
+        addr-gpios: false
+    else:
+      allOf:
+        - $ref: /schemas/mtd/mtd.yaml
+        - $ref: /schemas/memory-controllers/mc-peripheral-props.yaml#
 
 unevaluatedProperties: false
 
@@ -233,4 +249,23 @@ examples:
             reg = <0 0x04000000>;
         };
     };
+
+  - |
+    /* An example using mtd-mem/mtd-memro */
+    reserved-memory {
+        #address-cells = <2>;
+        #size-cells = <2>;
+
+        bm_logs_reserved: bm_logs_reserved@10000800 {
+            compatible = "mtd-mem";
+            reg = <0x1 0x0000800 0x0 0x0010000>;
+            no-map;
+        };
+
+        sys_logs_reserved: sys_logs_reserved@100120000  {
+            compatible = "mtd-memro";
+            reg = <0x1 0x00120000 0x0 0x0010000>;
+            no-map;
+        };
+    };
 ...

-- 
2.51.0

Hi Gregory,

thanks for your patch!

On Wed, Jan 7, 2026 at 2:05 PM Gregory CLEMENT
<gregory.clement@bootlin.com> wrote:

> Enable access to memory resources not only via I/O address using reg,
> but also through a portion of main memory using memory-region. To
> achieve this, new compatible strings have been introduced: mtd-mem and
> mtd-memro.
>
> Signed-off-by: Gregory CLEMENT <gregory.clement@bootlin.com>

I have two issues with this patch:

1. It needs a description: telling us when to use this and why, and
what makes it necessary to use these new bindings instead of existing
bindings, like the following:

2. To me this looks suspiciously similar to reserved RAM, "reserved-memory".
Documentation/devicetree/bindings/reserved-memory/phram.yaml
Documentation/devicetree/bindings/nvmem/rmem.yaml
Documentation/devicetree/bindings/reserved-memory/ramoops.yaml

Also see the dtschema reserved-memory:
https://github.com/devicetree-org/dt-schema/blob/main/dtschema/schemas/reserved-memory/reserved-memory.yaml

Why is this using "mtd,*" compatibles? What makes is a
"memory technology device", which is admittedly a loose term but
usually means some kind of persistent memory such as flash. This does
not look persistent at all.

To me it seems more related to specific Linux-lingo around the MTD
subsystem and just happens to be handled inside that subsystem in
Linux. Which means it has nothing to do inside a (OS-neutral) DT binding.

So I'm a bit concerned, but maybe I misunderstood something!

Yours,
Linus Walleij