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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20240924225343.GA413172-robh@kernel.org>
Date: Tue, 24 Sep 2024 17:53:43 -0500
From: Rob Herring <robh@...nel.org>
To: Christian Marangi <ansuelsmth@...il.com>
Cc: Jens Axboe <axboe@...nel.dk>, Jonathan Corbet <corbet@....net>,
	Ulf Hansson <ulf.hansson@...aro.org>,
	Krzysztof Kozlowski <krzk+dt@...nel.org>,
	Conor Dooley <conor+dt@...nel.org>,
	INAGAKI Hiroshi <musashino.open@...il.com>,
	Daniel Golle <daniel@...rotopia.org>,
	Christian Brauner <brauner@...nel.org>,
	Al Viro <viro@...iv.linux.org.uk>, Ming Lei <ming.lei@...hat.com>,
	Li Lingfeng <lilingfeng3@...wei.com>,
	Christian Heusel <christian@...sel.eu>, linux-block@...r.kernel.org,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mmc@...r.kernel.org, devicetree@...r.kernel.org,
	Miquel Raynal <miquel.raynal@...tlin.com>,
	Lorenzo Bianconi <lorenzo@...nel.org>
Subject: Re: [RFC PATCH 4/4] dt-bindings: mmc: Document support for partition
 table in mmc-card

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@...il.com>
> ---
>  .../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