Received-SPF: pass (google.com: domain of linux-kernel+bounces-110639-linux.lists.archive=gmail.com@vger.kernel.org designates 2604:1380:45e3:2400::1 as permitted sender) client-ip=2604:1380:45e3:2400::1;
Date: Thu, 21 Mar 2024 20:26:07 +0000
From: Daniel Golle <daniel@makrotopia.org>
To: Bart Van Assche <bvanassche@acm.org>
Cc: Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Ulf Hansson <ulf.hansson@linaro.org>, Jens Axboe <axboe@kernel.dk>,
	Dave Chinner <dchinner@redhat.com>, Jan Kara <jack@suse.cz>,
	Thomas =?iso-8859-1?Q?Wei=DFschuh?= <linux@weissschuh.net>,
	Damien Le Moal <dlemoal@kernel.org>,
	Li Lingfeng <lilingfeng3@huawei.com>,
	Christian Brauner <brauner@kernel.org>,
	Christian Heusel <christian@heusel.eu>,
	Min Li <min15.li@samsung.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Avri Altman <avri.altman@wdc.com>, Hannes Reinecke <hare@suse.de>,
	Christian Loehle <CLoehle@hyperstone.com>,
	Bean Huo <beanhuo@micron.com>, Yeqi Fu <asuk4.q@gmail.com>,
	Victor Shih <victor.shih@genesyslogic.com.tw>,
	Christophe JAILLET <christophe.jaillet@wanadoo.fr>,
	Dominique Martinet <dominique.martinet@atmark-techno.com>,
	"Ricardo B. Marliere" <ricardo@marliere.net>,
	devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-mmc@vger.kernel.org, linux-block@vger.kernel.org
Subject: Re: [PATCH 1/8] dt-bindings: block: add basic bindings for block
 devices
Message-ID: <ZfyX36JH0NdqS1AW@makrotopia.org>
References: <cover.1711048433.git.daniel@makrotopia.org>
 <28dcc69ecf9d55e95991d8f2a8e19f71bbd32af0.1711048433.git.daniel@makrotopia.org>
 <38efd4e4-0421-4318-8b2d-ca2603d482f5@acm.org>
Precedence: bulk
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <38efd4e4-0421-4318-8b2d-ca2603d482f5@acm.org>

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