Document support for defining a partition table in the mmc-card node.

This is needed if the eMMC doesn't have a partition table written and
the bootloader of the device load data by using absolute offset of the
block device. This is common on embedded device that have eMMC installed
to save space and have non removable block devices.

If an OF partition table is detected, any partition table written in the
eMMC will be ignored and won't be parsed.

eMMC provide a generic disk for user data and if supported (JEDEC 4.4+)
also provide two additional disk ("boot0" and "boot1") for special usage
of boot operation where normally is stored the bootloader or boot info.

Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
---
 .../devicetree/bindings/mmc/mmc-card.yaml     | 57 +++++++++++++++++++
 1 file changed, 57 insertions(+)

diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
index fd347126449a..58b6593a0f60 100644
--- a/Documentation/devicetree/bindings/mmc/mmc-card.yaml
+++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
@@ -13,6 +13,10 @@ description: |
   This documents describes the devicetree bindings for a mmc-host controller
   child node describing a mmc-card / an eMMC.
 
+  It's possible to define a fixed partition table for an eMMC for the user
+  partition and one of the 2 boot partition (boot0/boot1) if supported by the
+  eMMC.
+
 properties:
   compatible:
     const: mmc-card
@@ -26,6 +30,30 @@ properties:
       Use this to indicate that the mmc-card has a broken hpi
       implementation, and that hpi should not be used.
 
+  "#address-cells":
+    const: 0
+
+  "#size-cells":
+    const: 0
+
+patternProperties:
+  "^partitions(-boot[01])?$":
+    $ref: /schemas/block/partitions/partitions.yaml
+
+    patternProperties:
+      "^partition@[0-9a-f]+$":
+        $ref: /schemas/block/partitions/partition.yaml
+
+        properties:
+          reg:
+            multipleOf: 512
+
+        required:
+          - reg
+          - label
+
+        unevaluatedProperties: false
+
 required:
   - compatible
   - reg
@@ -42,6 +70,35 @@ examples:
             compatible = "mmc-card";
             reg = <0>;
             broken-hpi;
+
+            #address-cells = <0>;
+            #size-cells = <0>;
+
+            partitions {
+                #address-cells = <1>;
+                #size-cells = <1>;
+
+                partition@0 {
+                    label = "kernel"; /* Kernel */
+                    reg = <0x0 0x2000000>; /* 32 MB */
+                };
+
+                partition@2000000 {
+                    label = "rootfs";
+                    reg = <0x2000000 0x40000000>; /* 1GB */
+                };
+            };
+
+            partitions-boot0 {
+                #address-cells = <1>;
+                #size-cells = <1>;
+
+                partition@0 {
+                    label = "bl";
+                    reg = <0x0 0x2000000>; /* 32MB */
+                    read-only;
+                };
+            };
         };
     };
 
-- 
2.45.2

On Wed, Sep 25, 2024 at 11:45:25PM +0200, Christian Marangi wrote:
> Document support for defining a partition table in the mmc-card node.
> 
> This is needed if the eMMC doesn't have a partition table written and
> the bootloader of the device load data by using absolute offset of the
> block device. This is common on embedded device that have eMMC installed
> to save space and have non removable block devices.
> 
> If an OF partition table is detected, any partition table written in the
> eMMC will be ignored and won't be parsed.
> 
> eMMC provide a generic disk for user data and if supported (JEDEC 4.4+)
> also provide two additional disk ("boot0" and "boot1") for special usage
> of boot operation where normally is stored the bootloader or boot info.
> 
> Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> ---
>  .../devicetree/bindings/mmc/mmc-card.yaml     | 57 +++++++++++++++++++
>  1 file changed, 57 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
> index fd347126449a..58b6593a0f60 100644
> --- a/Documentation/devicetree/bindings/mmc/mmc-card.yaml
> +++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
> @@ -13,6 +13,10 @@ description: |
>    This documents describes the devicetree bindings for a mmc-host controller
>    child node describing a mmc-card / an eMMC.
>  
> +  It's possible to define a fixed partition table for an eMMC for the user
> +  partition and one of the 2 boot partition (boot0/boot1) if supported by the
> +  eMMC.
> +
>  properties:
>    compatible:
>      const: mmc-card
> @@ -26,6 +30,30 @@ properties:
>        Use this to indicate that the mmc-card has a broken hpi
>        implementation, and that hpi should not be used.
>  
> +  "#address-cells":
> +    const: 0
> +
> +  "#size-cells":
> +    const: 0

Don't need these properties.

> +
> +patternProperties:
> +  "^partitions(-boot[01])?$":
> +    $ref: /schemas/block/partitions/partitions.yaml
> +
> +    patternProperties:
> +      "^partition@[0-9a-f]+$":
> +        $ref: /schemas/block/partitions/partition.yaml
> +
> +        properties:
> +          reg:
> +            multipleOf: 512

I was going to suggest this, but I think it won't actually work because 
it could be 2 cells for address and/or size.

Rob

On Thu, Sep 26, 2024 at 09:15:41AM -0500, Rob Herring wrote:
> On Wed, Sep 25, 2024 at 11:45:25PM +0200, Christian Marangi wrote:
> > Document support for defining a partition table in the mmc-card node.
> > 
> > This is needed if the eMMC doesn't have a partition table written and
> > the bootloader of the device load data by using absolute offset of the
> > block device. This is common on embedded device that have eMMC installed
> > to save space and have non removable block devices.
> > 
> > If an OF partition table is detected, any partition table written in the
> > eMMC will be ignored and won't be parsed.
> > 
> > eMMC provide a generic disk for user data and if supported (JEDEC 4.4+)
> > also provide two additional disk ("boot0" and "boot1") for special usage
> > of boot operation where normally is stored the bootloader or boot info.
> > 
> > Signed-off-by: Christian Marangi <ansuelsmth@gmail.com>
> > ---
> >  .../devicetree/bindings/mmc/mmc-card.yaml     | 57 +++++++++++++++++++
> >  1 file changed, 57 insertions(+)
> > 
> > diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
> > index fd347126449a..58b6593a0f60 100644
> > --- a/Documentation/devicetree/bindings/mmc/mmc-card.yaml
> > +++ b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
> > @@ -13,6 +13,10 @@ description: |
> >    This documents describes the devicetree bindings for a mmc-host controller
> >    child node describing a mmc-card / an eMMC.
> >  
> > +  It's possible to define a fixed partition table for an eMMC for the user
> > +  partition and one of the 2 boot partition (boot0/boot1) if supported by the
> > +  eMMC.
> > +
> >  properties:
> >    compatible:
> >      const: mmc-card
> > @@ -26,6 +30,30 @@ properties:
> >        Use this to indicate that the mmc-card has a broken hpi
> >        implementation, and that hpi should not be used.
> >  
> > +  "#address-cells":
> > +    const: 0
> > +
> > +  "#size-cells":
> > +    const: 0
> 
> Don't need these properties.
> 
> > +
> > +patternProperties:
> > +  "^partitions(-boot[01])?$":
> > +    $ref: /schemas/block/partitions/partitions.yaml
> > +
> > +    patternProperties:
> > +      "^partition@[0-9a-f]+$":
> > +        $ref: /schemas/block/partitions/partition.yaml
> > +
> > +        properties:
> > +          reg:
> > +            multipleOf: 512
> 
> I was going to suggest this, but I think it won't actually work because 
> it could be 2 cells for address and/or size.
>

While checking I was surprised for this multipleOf and was very happy to
have something like this but I also had some fear it didn't work due to
the 2 cell thing... Very sad. I will add a description to it.

The driver will validate the values anyway, at least on that part we are
on the safe side.

-- 
	Ansuel