From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from metis.whiteo.stw.pengutronix.de (metis.whiteo.stw.pengutronix.de [185.203.201.7]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E802E5C907 for ; Wed, 6 Mar 2024 07:24:02 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=185.203.201.7 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709709844; cv=none; b=pJ/MhgWVx20GknslNNo94bbZujES2IhCuMMZPQTI8+QIbjfKM8R3tl+vjQNgpfXIBSW4v0bqQVgjcYLgELIRvkV1QxA16AKslF45aiVjBA4Oyfxt0zRQ2wzXe+2tM0OiVuDDj/T29X95ziXXy9DVkY0BkBuX3QKGfOnhmRNahhg= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1709709844; c=relaxed/simple; bh=+B0TJc/kRe/wrIincWxLSZ37rVccCTI1iUTwH/ns59w=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=tLSkixLCmlBCeaVvGpKO0QLYbq1owU90LYBt0spvCqMhVOXP7ZFl1LM9SLJDKzHjzXQ8ZdE2Nt7u+7Kudi6CzP3xhVQ3Brc28N5gyTjsj/5H/U2LNcjtXVFUBksWgj/CivA0WkW4m57Y7SUAtTsnOxqh/khvGZOdd+YUalY1n1E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de; spf=pass smtp.mailfrom=pengutronix.de; arc=none smtp.client-ip=185.203.201.7 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=pengutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=pengutronix.de Received: from drehscheibe.grey.stw.pengutronix.de ([2a0a:edc0:0:c01:1d::a2]) by metis.whiteo.stw.pengutronix.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rhlcM-0006zE-L4; Wed, 06 Mar 2024 08:23:10 +0100 Received: from [2a0a:edc0:2:b01:1d::c5] (helo=pty.whiteo.stw.pengutronix.de) by drehscheibe.grey.stw.pengutronix.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rhlcC-004hXC-0n; Wed, 06 Mar 2024 08:23:00 +0100 Received: from sha by pty.whiteo.stw.pengutronix.de with local (Exim 4.96) (envelope-from ) id 1rhlcB-004oTB-2t; Wed, 06 Mar 2024 08:22:59 +0100 Date: Wed, 6 Mar 2024 08:22:59 +0100 From: Sascha Hauer To: Daniel Golle Cc: Rob Herring , Krzysztof Kozlowski , Conor Dooley , Ulf Hansson , Jens Axboe , Dave Chinner , Jan Kara , Thomas =?iso-8859-15?Q?Wei=DFschuh?= , Christian Brauner , Li Lingfeng , Damien Le Moal , Min Li , Adrian Hunter , Hannes Reinecke , Christian Loehle , Avri Altman , Bean Huo , Yeqi Fu , Victor Shih , Christophe JAILLET , "Ricardo B. Marliere" , Greg Kroah-Hartman , devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mmc@vger.kernel.org, linux-block@vger.kernel.org, Diping Zhang , Jianhui Zhao , Jieying Zeng , Chad Monroe , Adam Fox , John Crispin Subject: Re: [RFC PATCH v2 1/8] dt-bindings: block: add basic bindings for block devices Message-ID: References: Precedence: bulk X-Mailing-List: linux-mmc@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Sent-From: Pengutronix Hildesheim X-URL: http://www.pengutronix.de/ X-Accept-Language: de,en X-Accept-Content-Type: text/plain X-SA-Exim-Connect-IP: 2a0a:edc0:0:c01:1d::a2 X-SA-Exim-Mail-From: sha@pengutronix.de X-SA-Exim-Scanned: No (on metis.whiteo.stw.pengutronix.de); SAEximRunCond expanded to false X-PTX-Original-Recipient: linux-mmc@vger.kernel.org Hi Daniel, On Tue, Mar 05, 2024 at 08:23:20PM +0000, Daniel Golle wrote: > diff --git a/Documentation/devicetree/bindings/block/partition.yaml b/Documentation/devicetree/bindings/block/partition.yaml > new file mode 100644 > index 0000000000000..df561dd33cbc9 > --- /dev/null > +++ b/Documentation/devicetree/bindings/block/partition.yaml > @@ -0,0 +1,51 @@ > +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause > +%YAML 1.2 > +--- > +$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 storage device. > + Partitions may be matched by a combination of partition number, name, > + and UUID. > + > +maintainers: > + - Daniel Golle > + > +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. In the mtd world we originally had the partition nodes directly under the hardware device node as well. That was changed to put a partitions subnode between the hardware device node and the partitions. >From fe2585e9c29a ("doc: dt: mtd: support partitions in a special 'partitions' subnode"): To avoid conflict with other drivers using subnodes of the mtd device create only one ofpart-specific node rather than any number of arbitrary partition subnodes. Does it make sense to do the same for block devices? Sascha -- Pengutronix e.K. | | Steuerwalder Str. 21 | http://www.pengutronix.de/ | 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |