From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id A19FFC25B78 for ; Sat, 25 May 2024 16:55:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender:Content-Type: List-Subscribe:List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id: In-Reply-To:MIME-Version:References:Message-ID:Subject:Cc:To:From:Date: Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date :Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=44I1SpTziYejjFFygHNBkKn4XJNQoExiMnukbn4Usio=; b=KprPLd/TgFQS0/gUndwM0UCFvH dWxrasdnlcHSkogkmevx1Kn9F4GPhgEjvPi9/5AiQRuAkydmzCk2a7vVPQHQwOHbYLsVjn0cFwlWf 51pSm1DxkFpfIyBJG9jfQd/jiMOKAYJu8gJEGP6JcHyCm0Mnsk2ccAq49diZ5qzf6LjXz8214xUvQ k3JfO5W9wS1daU0VziEEtWhydRS8/lWE/f8OwE/R3Dr0uwEaYkDFWMm9RPwe+ihJ9uiOtRJREWM5/ E+Dhag6NDkjB3ksKu5x/EMuHIwy2FkULOc6KgItd2SG9EI1+OXpV5R4kJsqhHpV7iNm6KhzKdR+na jEyaWFaQ==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.97.1 #2 (Red Hat Linux)) id 1sAufq-0000000BMkn-1yxm; Sat, 25 May 2024 16:55:14 +0000 Received: from sin.source.kernel.org ([145.40.73.55]) by bombadil.infradead.org with esmtps (Exim 4.97.1 #2 (Red Hat Linux)) id 1sAufl-0000000BMiM-02dM for linux-arm-kernel@lists.infradead.org; Sat, 25 May 2024 16:55:11 +0000 Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by sin.source.kernel.org (Postfix) with ESMTP id 7223DCE095D; Sat, 25 May 2024 16:55:00 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9F498C2BD11; Sat, 25 May 2024 16:54:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1716656098; bh=wUwELUVHwo64lFmXvZH7t4xIWMjuXkr29anwgbNaTZU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=bjBZDHEa45+aaKX0ijGl4V/D2dRJi4L4MGgWT68equA4QCczUQ3xhfY94/rTnqYd1 LoSoZBL9XCTF4zIyMAZGpWJoKl11Mq5B1vppogCvJC2zp6NYvfgSGeVymLRRAb1zbp 0jtlQLdgjxZFRGocJXXzP08jOQk8ErdFk6O3ZXeHFvwAJckSlW2hFOcipsqRL0XAIS BMHfMk/5vOyvF7UB35AkTKUwsU+QYy31vfrObjbm1E51A4E057wL8U2AD7g5KCRva3 YKCLlpQAmyM20FQ13VpHcGDyxZ4Um5i4Rs9ItPkO8Ei79+4BdnP4aAK9zTPSYWPRp0 PzSVDuTAvJBhg== Date: Sat, 25 May 2024 17:54:52 +0100 From: Conor Dooley To: Elliot Berman Cc: Rob Herring , Frank Rowand , Krzysztof Kozlowski , Conor Dooley , Bjorn Andersson , Konrad Dybcio , Amrit Anand , Peter Griffin , Caleb Connolly , Andy Gross , Doug Anderson , Simon Glass , Chen-Yu Tsai , Julius Werner , "Humphreys, Jonathan" , Sumit Garg , Michal Simek , boot-architecture@lists.linaro.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-arm-msm@vger.kernel.org Subject: Re: [PATCH RFC v3 2/9] dt-bindings: board: Introduce board-id Message-ID: <20240525-aids-jersey-a56ce764b430@spud> References: <20240522162545887-0700.eberman@hu-eberman-lv.qualcomm.com> <20240522-board-ids-v4-2-a173277987f5@quicinc.com> MIME-Version: 1.0 In-Reply-To: <20240522-board-ids-v4-2-a173277987f5@quicinc.com> X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20240525_095509_420321_6988E623 X-CRM114-Status: GOOD ( 31.78 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0378788223723675796==" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org --===============0378788223723675796== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4gDwNw3YpYlpY0Pi" Content-Disposition: inline --4gDwNw3YpYlpY0Pi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 22, 2024 at 04:54:23PM -0700, Elliot Berman wrote: > Device manufcturers frequently ship multiple boards or SKUs under a > single softwre package. These software packages ship multiple devicetree > blobs and require some mechanims to pick the correct DTB for the boards > that use the software package. This patch introduces a common language > for adding board identifiers to devicetrees. >=20 > Signed-off-by: Elliot Berman > --- > .../devicetree/bindings/board/board-id.yaml | 71 ++++++++++++++++= ++++++ > 1 file changed, 71 insertions(+) >=20 > diff --git a/Documentation/devicetree/bindings/board/board-id.yaml b/Docu= mentation/devicetree/bindings/board/board-id.yaml > new file mode 100644 > index 000000000000..894c1e310cbd > --- /dev/null > +++ b/Documentation/devicetree/bindings/board/board-id.yaml > @@ -0,0 +1,71 @@ > +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) > +%YAML 1.2 > +--- > +$id: http://devicetree.org/schemas/board/board-id.yaml# > +$schema: http://devicetree.org/meta-schemas/core.yaml# > + > +title: Board identifiers > +description: | > + This node contains a list of identifier values for the board(s) suppor= ted by > + this devicetree. Identifier values are either N-tuples of integers or a > + string. The number of items for an N-tuple identifer is determined by = the > + property name. String identifiers must be suffixed with "-string". > + > + Every identifier in the devicetree must have a matching value from the= board > + to be considered a valid devicetree for the board. In other words: if > + multiple identifiers are present in the board-id and one identifier do= esn't > + match against the board, then the devicetree is not applicable. Note t= his is > + not the case where the the board can provide more identifiers than the > + devicetree describes: those additional identifers can be ignored. > + > + Identifiers in the devicetree can describe multiple possible valid val= ues, > + such as revision 1 and revision 2. > + > +maintainers: > + - Elliot Berman > + > +properties: > + $nodename: > + const: '/' > + board-id: Does this need to be properties: $nodename: const: board-id ? That's the pattern I see for all top level nodes. > + type: object > + patternProperties: > + "^.*(? + $ref: /schemas/types.yaml#/definitions/uint32-matrix > + description: | > + List of values that match boards this devicetree applies to. > + A bootloader checks whether any of the values in this list > + match against the board's value. > + > + The number of items per tuple is determined by the property na= me, > + see the vendor-specific board-id bindings. > + "^.*-string$": > + $ref: /schemas/types.yaml#/definitions/string-array Your description above doesn't match a string-array, just a single string. That said I'm far from sold on the "thou shalt have -string" edict. If every vendor is expected to go and define their own set of properties (and provide their own callback in your libfdt PoC) there's little to no reason to inflict property naming on them, AFAICT all that is gained is a being able to share if (string) { return fdt_stringlist_contains(prop->data, fdt32_to_cpu(prop->len), data); } else { // exact data comparison. data_len is the size of each entry if (fdt32_to_cpu(prop->len) % data_len || data_len % 4) return -FDT_ERR_BADVALUE; for (int i =3D 0; i < fdt32_to_cpu(prop->len); i +=3D data_len) { if (!memcmp(&prop->data[i], data, data_len)) return 1; } return 0; } in the libfdt PoC? I'd be expecting that a common mechanism would use the same "callback" for boards shipped by both Qualcomm and $other_vendor. Every vendor having different properties and only sharing the board-id node name seems a wee bit like paying lip-service to a common mechanism to me. What am I missing? Thanks, Conor. > + description: | > + List of strings that match boards this devicetree applies to. > + A bootloader checks whether any of the strings in this list > + match against the board's string representation. > + > + String-based matching requires properties to be suffixed with > + -string so that a bootloader can match values without otherwise > + knowing the meaning of the identifier. > + > +examples: > + - | > + / { > + #address-cells =3D <1>; > + #size-cells =3D <1>; > + compatible =3D "example"; > + board-id { > + // this works with any boards where: > + // some-hw-id =3D 1, other-hw-id =3D 1, some-id-string =3D "cat" > + // some-hw-id =3D 1, other-hw-id =3D 1, some-id-string =3D "kitt= en" > + // some-hw-id =3D 1, other-hw-id =3D 2, some-id-string =3D "cat" > + // some-hw-id =3D 1, other-hw-id =3D 2, some-id-string =3D "kitt= en" > + some-hw-id =3D <1>; // some-hw-id must be "1" > + other-hw-id =3D <1>, <2>; // other-hw-id must be "1" or "2" > + some-id-string =3D "cat", "kitten"; // some-id-string must be "c= at" or "kitten" > + }; > + }; > + > +additionalProperties: true >=20 > --=20 > 2.34.1 --4gDwNw3YpYlpY0Pi Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEABYIAB0WIQRh246EGq/8RLhDjO14tDGHoIJi0gUCZlIX3AAKCRB4tDGHoIJi 0kYZAP9vG6zxYpMPz/B6sGJxZSWXoyFVPjKnC4ljUKRiUsijtgD+OgNsZE0wzF3X Sx2KhMGx8AukOYyInzSmbhFYGcDALgM= =2OA5 -----END PGP SIGNATURE----- --4gDwNw3YpYlpY0Pi-- --===============0378788223723675796== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel --===============0378788223723675796==--