Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <e1458f39-a2fe-36bf-af8d-ef2162f7c514@gmail.com>
Date:   Fri, 25 Feb 2022 10:07:20 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:96.0) Gecko/20100101
 Thunderbird/96.0
Subject: Re: [PATCH REBASED 2/2] dt-bindings: nvmem: cells: add MAC address
 cell
To:     Michael Walle <michael@walle.cc>, Rob Herring <robh@kernel.org>
Cc:     Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
        linux-mtd@lists.infradead.org, devicetree@vger.kernel.org,
        linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
        netdev@vger.kernel.org, Miquel Raynal <miquel.raynal@bootlin.com>,
        Richard Weinberger <richard@nod.at>,
        Vignesh Raghavendra <vigneshr@ti.com>,
        Shawn Guo <shawnguo@kernel.org>, Li Yang <leoyang.li@nxp.com>,
        Frank Rowand <frowand.list@gmail.com>,
        "David S . Miller" <davem@davemloft.net>,
        Jakub Kicinski <kuba@kernel.org>,
        Ansuel Smith <ansuelsmth@gmail.com>,
        Andrew Lunn <andrew@lunn.ch>,
        Florian Fainelli <f.fainelli@gmail.com>,
        Hauke Mehrtens <hauke@hauke-m.de>,
        =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= <rafal@milecki.pl>
References: <20220125180114.12286-1-zajec5@gmail.com>
 <20220126070745.32305-1-zajec5@gmail.com>
 <20220126070745.32305-2-zajec5@gmail.com>
 <YflX6kxWTD6qMnhJ@robh.at.kernel.org>
 <0b7b8f7ea6569f79524aea1a3d783665@walle.cc>
From:   =?UTF-8?B?UmFmYcWCIE1pxYJlY2tp?= <zajec5@gmail.com>
In-Reply-To: <0b7b8f7ea6569f79524aea1a3d783665@walle.cc>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 1.02.2022 18:01, Michael Walle wrote:
> Am 2022-02-01 16:55, schrieb Rob Herring:
>> On Wed, Jan 26, 2022 at 08:07:45AM +0100, Rafał Miłecki wrote:
>>> From: Rafał Miłecki <rafal@milecki.pl>
>>>
>>> This adds support for describing details of NVMEM cell containing MAC
>>> address. Those are often device specific and could be nicely stored in
>>> DT.
>>>
>>> Initial documentation includes support for describing:
>>> 1. Cell data format (e.g. Broadcom's NVRAM uses ASCII to store MAC)
>>> 2. Reversed bytes flash (required for i.MX6/i.MX7 OCOTP support)
>>> 3. Source for multiple addresses (very common in home routers)
>>>
>>> Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
>>> ---
>>>  .../bindings/nvmem/cells/mac-address.yaml     | 94 +++++++++++++++++++
>>>  1 file changed, 94 insertions(+)
>>>  create mode 100644 Documentation/devicetree/bindings/nvmem/cells/mac-address.yaml
>>>
>>> diff --git a/Documentation/devicetree/bindings/nvmem/cells/mac-address.yaml b/Documentation/devicetree/bindings/nvmem/cells/mac-address.yaml
>>> new file mode 100644
>>> index 000000000000..f8d19e87cdf0
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/nvmem/cells/mac-address.yaml
>>> @@ -0,0 +1,94 @@
>>> +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
>>> +%YAML 1.2
>>> +---
>>> +$id: http://devicetree.org/schemas/nvmem/cells/mac-address.yaml#
>>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>>> +
>>> +title: NVMEM cell containing a MAC address
>>> +
>>> +maintainers:
>>> +  - Rafał Miłecki <rafal@milecki.pl>
>>> +
>>> +properties:
>>> +  compatible:
>>> +    const: mac-address
>>> +
>>> +  format:
>>> +    description: |
>>> +      Some NVMEM cells contain MAC in a non-binary format.
>>> +
>>> +      ASCII should be specified if MAC is string formatted like:
>>> +      - "01:23:45:67:89:AB" (30 31 3a 32 33 3a 34 35 3a 36 37 3a 38 39 3a 41 42)
>>> +      - "01-23-45-67-89-AB"
>>> +      - "0123456789AB"
>>> +    enum:
>>> +      - ascii
>>> +
>>> +  reversed-bytes:
>>> +    type: boolean
>>> +    description: |
>>> +      MAC is stored in reversed bytes order. Example:
>>> +      Stored value: AB 89 67 45 23 01
>>> +      Actual MAC: 01 23 45 67 89 AB
>>> +
>>> +  base-address:
>>> +    type: boolean
>>> +    description: |
>>> +      Marks NVMEM cell as provider of multiple addresses that are relative to
>>> +      the one actually stored physically. Respective addresses can be requested
>>> +      by specifying cell index of NVMEM cell.
>>
>> While a base address is common, aren't there different ways the base is
>> modified.
>>
>> The problem with these properties is every new variation results in a
>> new property and the end result is something not well designed. A unique
>> compatible string, "#nvmem-cell-cells" and code to interpret the data is
>> more flexible.
> 
> I actually like having a unique compatible for anything but the basic
> operations. For example, the sl28 vpd area also has a checksum, which
> could be handled if there is an own compatible. I don't think this is
> possible with this proposal. Also there is a version field, what if
> we change the layout of that thing? Am I supposed to change the
> device tree? The more I think about Rob's proposal to have a compatible
> the more I like it.

Having more detailed binding for cells doesn't stop you from using NVMEM
device specific binding.

You could have e.g.

partition@f00000 {
      compatible = "foo,foo-cells", "nvmem-cells";
      (...)

      mac@100 {
          compatible = "mac-address";
          reg = <0x100 0x6>;
      };

      OR

      mac@100 {
          compatible = "mac-address";
          reg = <0x100 0x11>;
          format = "ascii";
      };
};

Then you can have "foo,foo-cells" driver handling checksum.

I'm not saying we have to use this solution, just saying it's possible.