[PATCH v10 1/2] dt-bindings: mtd: fixed-partitions: Add alignment properties

[Simon Glass]

Hi Miquel,

On Mon, 8 Apr 2024 at 07:11, Miquel Raynal <miquel.raynal at bootlin.com> wrote:
>
> Hi Simon,
>
> sjg at chromium.org wrote on Tue, 26 Mar 2024 14:06:44 -0600:
>
> > Add three properties for controlling alignment of partitions, aka
> > 'entries' in fixed-partition.
> >
> > For now there is no explicit mention of hierarchy, so a 'section' is
> > just the 'fixed-partitions' node.
> >
> > These new properties are inputs to the Binman packaging process, but are
> > also needed if the firmware is repacked, to ensure that alignment
> > constraints are not violated. Therefore they are provided as part of
> > the schema.
> >
> > Signed-off-by: Simon Glass <sjg at chromium.org>
> > Reviewed-by: Rob Herring <robh at kernel.org>
> > ---
> >
> > Changes in v10:
> > - Update the minimum to 2
> >
> > Changes in v9:
> > - Move binding example to next batch to avoid build error
> >
> > Changes in v7:
> > - Drop patch 'Add binman compatible'
> > - Put the alignment properties into the fixed-partition binding
> >
> > Changes in v6:
> > - Correct schema-validation errors missed due to older dt-schema
> >   (enum fix and reg addition)
> >
> > Changes in v5:
> > - Add value ranges
> > - Consistently mention alignment must be power-of-2
> > - Mention that alignment refers to bytes
> >
> > Changes in v2:
> > - Fix 'a' typo in commit message
> >
> >  .../bindings/mtd/partitions/partition.yaml    | 51 +++++++++++++++++++
> >  1 file changed, 51 insertions(+)
> >
> > diff --git a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
> > index 1ebe9e2347ea..656ca3db1762 100644
> > --- a/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
> > +++ b/Documentation/devicetree/bindings/mtd/partitions/partition.yaml
> > @@ -57,6 +57,57 @@ properties:
> >        user space from
> >      type: boolean
> >
> > +  align:
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    minimum: 2
> > +    maximum: 0x80000000
> > +    multipleOf: 2
> > +    description:
> > +      This sets the alignment of the entry in bytes.
> > +
> > +      The entry offset is adjusted so that the entry starts on an aligned
> > +      boundary within the containing section or image. For example ‘align =
> > +      <16>’ means that the entry will start on a 16-byte boundary. This may
> > +      mean that padding is added before the entry. The padding is part of
> > +      the containing section but is not included in the entry, meaning that
> > +      an empty space may be created before the entry starts. Alignment
> > +      must be a power of 2. If ‘align’ is not provided, no alignment is
> > +      performed.
> > +
> > +  align-size:
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    minimum: 2
> > +    maximum: 0x80000000
> > +    multipleOf: 2
> > +    description:
> > +      This sets the alignment of the entry size in bytes. It must be a power
> > +      of 2.
> > +
> > +      For example, to ensure that the size of an entry is a multiple of 64
> > +      bytes, set this to 64. While this does not affect the contents of the
> > +      entry within binman itself (the padding is performed only when its
> > +      parent section is assembled), the end result is that the entry ends
> > +      with the padding bytes, so may grow. If ‘align-size’ is not provided,
> > +      no alignment is performed.
>
> I don't think we should mention binman here. Can we have a software
> agnostic description? This should be understandable from anyone playing
> with mtd partitions I guess.

OK

>
> > +
> > +  align-end:
> > +    $ref: /schemas/types.yaml#/definitions/uint32
> > +    minimum: 2
> > +    maximum: 0x80000000
> > +    multipleOf: 2
>
> seems not to perfectly match the constraint, but I don't know if there
> is a powerOf keyword? (same above)

I believe this was discussed earlier. No there is no such option!

>
> > +    description:
> > +      This sets the alignment (in bytes) of the end of an entry with respect
> > +      to the containing section. It must be a power of 2.
> > +
> > +      Some entries require that they end on an alignment boundary,
> > +      regardless of where they start. This does not move the start of the
> > +      entry, so the contents of the entry will still start at the beginning.
> > +      But there may be padding at the end. While this does not affect the
> > +      contents of the entry within binman itself (the padding is performed
>
> content?                                same comment about binman?

OK

>
> > +      only when its parent section is assembled), the end result is that the
> > +      entry ends with the padding bytes, so may grow. If ‘align-end’ is not
> > +      provided, no alignment is performed.
> > +
> >  if:
> >    not:
> >      required: [ reg ]
Regards,
SImon