Re: [RFC PATCH 4/4] dt-bindings: mmc: Document support for partition table in mmc-card

[Rob Herring]

On Mon, Sep 23, 2024 at 12:59:33PM +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.

What if the partition table is written? What does one use? One of them 
or both and merge them?

> eMMC provide a generic disk for user data and if supported also provide
> one or 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@xxxxxxxxx>
> ---
>  .../devicetree/bindings/mmc/mmc-card.yaml     | 75 +++++++++++++++++++
>  1 file changed, 75 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/mmc/mmc-card.yaml b/Documentation/devicetree/bindings/mmc/mmc-card.yaml
> index fd347126449a..fab9fa5c170a 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,48 @@ properties:
>        Use this to indicate that the mmc-card has a broken hpi
>        implementation, and that hpi should not be used.
>  
> +  "#address-cells": true
> +
> +  "#size-cells": true
> +
> +patternProperties:
> +  "^partitions(-boot[01])?$":
> +    type: object

You don't define this is fixed partitions with a fixed-partitions 
compatible. Why not reuse that? Then this all goes away with a 
reference to it.

> +
> +    properties:
> +      "#address-cells": true
> +
> +      "#size-cells": true
> +
> +    patternProperties:
> +      "@[0-9a-f]+$":
> +        type: object
> +
> +        properties:
> +          reg:
> +            description: partition's offset and size within the flash (in sector
> +              block, 512byte)

Units are sectors? Use bytes instead because everything else does in DT. 

> +            maxItems: 1
> +
> +
> +          label:
> +            description: The label / name for this partition.
> +
> +          read-only:
> +            description: This parameter, if present, is a hint that this partition
> +              should only be mounted read-only. This is usually used for flash
> +              partitions containing early-boot firmware images or data which should
> +              not be clobbered.
> +            type: boolean
> +
> +        required:
> +          - reg
> +          - label
> +
> +        additionalProperties: false
> +
> +    additionalProperties: false

Put the indented cases of additionalProperties/unevaluatedProperties 
before 'properties'. Easier to see what they apply to that way.

Rob