linux-kernel - Re: [PATCH 1/8] dt-bindings: block: add basic bindings for block devices

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]

Date: Thu, 21 Mar 2024 20:26:07 +0000
From: Daniel Golle <daniel@...rotopia.org>
To: Bart Van Assche <bvanassche@....org>
Cc: Rob Herring <robh@...nel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
	Conor Dooley <conor+dt@...nel.org>,
	Ulf Hansson <ulf.hansson@...aro.org>, Jens Axboe <axboe@...nel.dk>,
	Dave Chinner <dchinner@...hat.com>, Jan Kara <jack@...e.cz>,
	Thomas Weißschuh <linux@...ssschuh.net>,
	Damien Le Moal <dlemoal@...nel.org>,
	Li Lingfeng <lilingfeng3@...wei.com>,
	Christian Brauner <brauner@...nel.org>,
	Christian Heusel <christian@...sel.eu>,
	Min Li <min15.li@...sung.com>,
	Adrian Hunter <adrian.hunter@...el.com>,
	Avri Altman <avri.altman@....com>, Hannes Reinecke <hare@...e.de>,
	Christian Loehle <CLoehle@...erstone.com>,
	Bean Huo <beanhuo@...ron.com>, Yeqi Fu <asuk4.q@...il.com>,
	Victor Shih <victor.shih@...esyslogic.com.tw>,
	Christophe JAILLET <christophe.jaillet@...adoo.fr>,
	Dominique Martinet <dominique.martinet@...ark-techno.com>,
	"Ricardo B. Marliere" <ricardo@...liere.net>,
	devicetree@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-mmc@...r.kernel.org, linux-block@...r.kernel.org
Subject: Re: [PATCH 1/8] dt-bindings: block: add basic bindings for block
 devices

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@...rotopia.org>
> > +
> > +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.