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 B680FECAAD1 for ; Wed, 31 Aug 2022 08:26:22 +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: Content-Transfer-Encoding:List-Subscribe:List-Help:List-Post:List-Archive: List-Unsubscribe:List-Id:Message-ID:References:In-Reply-To:Subject:Cc:To:From :Date:MIME-Version:Reply-To:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Owner; bh=3Xmuy9mCg3SsuZeIGhETuWqyg4dcbsOv6e9WEu11Uzk=; b=Qdo5QWccuC0tEb1IzCeuZtHsoo 8j0qqBKG/qpBcf5pNGAwje5I5DCAUfYMxBixBJDt3hcy70LgRakD9YzR+WfUZFJVjCQJwPOqB6BfB /IItQCXgqmJ/cYnWtHcBCg3CgkEFYQuEL012z3dcipzFu7LYBcbQMHqcSTmiP3VGEa73FyWbNUlA6 WKKD6c/sDAB/4EFTEbu1gCGwmWre2+IJFDCDApWJxrkLq12HBZBfZ9NHMyubG61hI+Glj1FGjfBXL 4NSQ1+ctXw/+qZFu9I+1tqn3to6bVj/9DMbPqlf6Lrn7Vgyc1RZt0IacQfWYRphW3LRNjfovX91JL 15unBqCw==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTJ20-004vG2-9k; Wed, 31 Aug 2022 08:25:05 +0000 Received: from 0001.3ffe.de ([159.69.201.130] helo=mail.3ffe.de) by bombadil.infradead.org with esmtps (Exim 4.94.2 #2 (Red Hat Linux)) id 1oTIuN-004ryO-6D; Wed, 31 Aug 2022 08:17:13 +0000 Received: from 3ffe.de (0001.3ffe.de [IPv6:2a01:4f8:c0c:9d57::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.3ffe.de (Postfix) with ESMTPSA id 4D172126D; Wed, 31 Aug 2022 10:17:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=walle.cc; s=mail2022082101; t=1661933824; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=e3iSpyQN09evFGUwpbcqnJSarhmjMiSyteJCLVWGduA=; b=QAQljtSCAZAC3wYiQG4rjFZPhdZ2aNOc0QjDAFzywpAhteTA6SXzvE0y8WPLsONYQyCcOR 9GRj8C9xSA1HQY1YH7W4ZF82mtAk/aiNFyRup8l/T/+bZTDPejrSYLoedouuOFu88lvQxn BRR4Stwm8QeCOLpbDmNyH3/vSK7PjZOSBMYvaPyw1+PH5ESRWtmOKwDc8BW/Ji5FbAwq3Q BJQdUZ6Y3llTQfNGKuFdg+DC3rMrQ0NvCMZHGOWeJVAOwGSHlggWCYv5hBn2p8DIG0Yfdo KmizTcWjRPUAv2rqUClWVGn3CxaCXkhyJiwPPR+Sgxs5TVm9Z7FtL92zaAyGmw== MIME-Version: 1.0 Date: Wed, 31 Aug 2022 10:17:04 +0200 From: Michael Walle To: Krzysztof Kozlowski Cc: Miquel Raynal , Richard Weinberger , Vignesh Raghavendra , Rob Herring , Krzysztof Kozlowski , Srinivas Kandagatla , Shawn Guo , Li Yang , =?UTF-8?Q?Rafa=C5=82_Mi=C5=82ecki?= , "David S . Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Frank Rowand , linux-mtd@lists.infradead.org, devicetree@vger.kernel.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, netdev@vger.kernel.org, Ahmad Fatoum Subject: Re: [PATCH v1 09/14] dt-bindings: nvmem: add YAML schema for the sl28 vpd layout In-Reply-To: References: <20220825214423.903672-1-michael@walle.cc> <20220825214423.903672-10-michael@walle.cc> User-Agent: Roundcube Webmail/1.4.13 Message-ID: X-Sender: michael@walle.cc X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20220831_011711_443908_F0B25A1C X-CRM114-Status: GOOD ( 28.41 ) 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-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org Am 2022-08-31 09:45, schrieb Krzysztof Kozlowski: > On 26/08/2022 00:44, Michael Walle wrote: >> Add a schema for the NVMEM layout on Kontron's sl28 boards. >> >> Signed-off-by: Michael Walle >> --- >> .../nvmem/layouts/kontron,sl28-vpd.yaml | 52 >> +++++++++++++++++++ >> 1 file changed, 52 insertions(+) >> create mode 100644 >> Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml >> >> diff --git >> a/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml >> b/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml >> new file mode 100644 >> index 000000000000..e4bc2d9182db >> --- /dev/null >> +++ >> b/Documentation/devicetree/bindings/nvmem/layouts/kontron,sl28-vpd.yaml >> @@ -0,0 +1,52 @@ >> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) >> +%YAML 1.2 >> +--- >> +$id: >> http://devicetree.org/schemas/nvmem/layouts/kontron,sl28-vpd.yaml# >> +$schema: http://devicetree.org/meta-schemas/core.yaml# >> + >> +title: NVMEM layout of the Kontron SMARC-sAL28 vital product data >> + >> +maintainers: >> + - Michael Walle >> + >> +description: >> + The vital product data (VPD) of the sl28 boards contains a serial >> + number and a base MAC address. The actual MAC addresses for the >> + on-board ethernet devices are derived from this base MAC address by >> + adding an offset. >> + >> +properties: >> + compatible: >> + items: >> + - const: kontron,sl28-vpd >> + - const: user-otp >> + >> + serial-number: >> + type: object > > You should define the contents of this object. I would expect this to > be > uint32 or string. I think you also need description, as this is not > really standard field. First thing, this binding isn't like the usual ones, so it might be totally wrong. What I'd like to achieve here is the following: We have the nvmem-consumer dt binding where you can reference a nvmem cell in a consumer node. Example: nvmem-cells = <&base_mac_address 5>; nvmem-cell-names = "mac-address"; On the other end of the link we have the nvmem-provider. The dt bindings works well if that one has individual cell nodes, like it is described in the nvmem.yaml binding. I.e. you can give the cell a label and make a reference to it in the consumer just like in the example above. Now comes the catch: what if there is no actual description of the cell in the device tree, but is is generated during runtime. How can I get a label to it. Therefore, in this case, there is just an empty node and the driver will associate it with the cell created during runtime (see patch 10). It is not expected, that is has any properties. >> + >> + base-mac-address: > > Fields should be rather described here, not in top-level description. > >> + type: object > > On this level: > additionalProperties: false > >> + >> + properties: >> + "#nvmem-cell-cells": >> + const: 1 >> + > > I also wonder why you do not have unit addresses. What if you want to > have two base MAC addresses? That would describe an offset within the nvmem device. But the offset might not be constant, depending on the content. My understanding so far was that in that case, you use the "-N" suffix. base-mac-address-1 base-mac-address-2 (or maybe completely different names). >> +required: >> + - compatible > > Other fields are I guess required? At least serial-number should be > always? Yes I could add them to the required list, but they are only "required" if you need to reference them within the device tree, in which case there have to be there anyway. IOW, the driver doesn't care if there is a node. If there is none, it doesn't set the "struct device_node*" in the nvmem cell. >> + >> +additionalProperties: false >> + >> +examples: >> + - | >> + otp-1 { > > Messed up indentation (use 4 spaces). Generic node name "otp". > >> + compatible = "kontron,sl28-vpd", "user-otp"; >> + >> + serial_number: serial-number { > > What's the point of the empty node? See above. -michael >> + }; >> + >> + base_mac_address: base-mac-address { >> + #nvmem-cell-cells = <1>; >> + }; >> + }; >> + >> +... _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel