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: <66f344d9.050a0220.3a46fd.0723@mx.google.com>
Date: Wed, 25 Sep 2024 01:01:42 +0200
From: Christian Marangi <ansuelsmth@...il.com>
To: Rob Herring <robh@...nel.org>
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 Tue, Sep 24, 2024 at 05:53:43PM -0500, Rob Herring wrote:
> 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?
>

Hi Rob,
thanks a lot for the review!

The block code parse partition table with some kind of priority system.

Example if cmdline is found, then anything else is ignored. (simple
logic, first parser that match an expected structure win)

We apply the same logic. So with partition table defined in OF, then
anything written will be ignored.

> > 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.
> 

My problem is that the fixed-partition schema in MTD have some
additional property that can't be supported.

Ideally I should define a generic schema that can be shared and then
expand it in MTD. Any hint on the directory structure tho?

Where should I put this generic schema?

> > +
> > +    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. 
> 

Ok will try to convert value to bytes internally.

> > +            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.
> 

ack.

-- 
	Ansuel