On Thu, Mar 21, 2024 at 12:39:33PM -0700, Bart Van Assche wrote: > On 3/21/24 12:32, Daniel Golle wrote: > > +$id: http://devicetree.org/schemas/block/partition.yaml# > > +$schema: http://devicetree.org/meta-schemas/core.yaml# > > + > > +title: Partition on a block device > > + > > +description: | > > + This binding describes a partition on a block device. > > + Partitions may be matched by a combination of partition number, name, > > + and UUID. > > + > > +maintainers: > > + - Daniel Golle <daniel@xxxxxxxxxxxxxx> > > + > > +properties: > > + $nodename: > > + pattern: '^block-partition-.+$' > > + > > + partnum: > > + $ref: /schemas/types.yaml#/definitions/uint32 > > + description: > > + Matches partition by number if present. > > + > > + partname: > > + $ref: /schemas/types.yaml#/definitions/string > > + description: > > + Matches partition by PARTNAME if present. > > + > > + partuuid: > > + $ref: /schemas/types.yaml#/definitions/string > > + description: > > + Matches partition by PARTUUID if present. > > + > > + nvmem-layout: > > + $ref: /schemas/nvmem/layouts/nvmem-layout.yaml# > > + description: > > + This container may reference an NVMEM layout parser. > > Does the above imply that only systems with a single block device are > supported? Absolutely not. Of course also such devices often have multiple block devices, typically eMMC, NVMe and SD card are supported, some also come with SATA ports. The block device(s) relevant as NVMEM providers has/have to be referenced and the 'partitions' node is a child node of a specific block device, of course. > > Supporting partition numbers seems unfortunate to me. Partition numbers > will change if the partition scheme changes. I fully argee with that, and using partnum as an identifier is not very smart. However, this is what some vendors are doing (in custom downstream drivers or scripts running in early userland) and hence the kernel implementation should allow to identify the relevant location in exactly the same way to be sure we are always compatible.
