Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
Subject: Re: [PATCH 1/6] dt-bindings: nvmem: add cell-type to nvmem cells
To:     Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
        Joakim Zhang <qiangqing.zhang@nxp.com>, robh+dt@kernel.org,
        shawnguo@kernel.org,
        =?UTF-8?Q?Jan_L=c3=bcbbe?= <jlu@pengutronix.de>
Cc:     devicetree@vger.kernel.org, linux-imx@nxp.com,
        kernel@pengutronix.de, linux-kernel@vger.kernel.org
References: <20210908100257.17833-1-qiangqing.zhang@nxp.com>
 <20210908100257.17833-2-qiangqing.zhang@nxp.com>
 <6d91d833-08cc-7ce2-4fe5-3d843a8b31ae@pengutronix.de>
 <181c4037-3c34-0f71-6bb7-a9c11b173064@linaro.org>
 <dbd1c20c-e3be-6c92-52a8-2ad76d0092d0@pengutronix.de>
 <8fc0a5e2-18c0-fa81-3eed-a6d596361633@linaro.org>
 <d580dd06-8bc8-91c9-262b-f6f276b033c2@pengutronix.de>
 <53fd9335-baca-fb52-42f1-2af3b08b5f1f@linaro.org>
From:   Ahmad Fatoum <a.fatoum@pengutronix.de>
Message-ID: <89b4a2d6-1966-7fcb-d476-f69e88293ea0@pengutronix.de>
Date:   Wed, 22 Sep 2021 15:08:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.13.0
MIME-Version: 1.0
In-Reply-To: <53fd9335-baca-fb52-42f1-2af3b08b5f1f@linaro.org>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Precedence: bulk

Hi,

On 22.09.21 15:03, Srinivas Kandagatla wrote:
> 
> 
> On 22/09/2021 13:58, Ahmad Fatoum wrote:
>> Hi Srini,
>>
>> On 22.09.21 14:49, Srinivas Kandagatla wrote:
>>>
>>>
>>> On 22/09/2021 13:31, Ahmad Fatoum wrote:
>>>>>>
>>>>>> On 08.09.21 12:02, Joakim Zhang wrote:
>>>>>>> From: Srinivas Kandagatla<srinivas.kandagatla@linaro.org>
>>>>>>>
>>>>>>> Some of the nvmem providers encode data for certain type of nvmem cell,
>>>>>>> example mac-address is stored in ascii or with delimiter or in reverse order.
>>>>>>>
>>>>>>> This is much specific to vendor, so having a cell-type would allow nvmem
>>>>>>> provider drivers to post-process this before using it.
>>>>>> I don't agree with this assessment. Users of the OCOTP so far
>>>>>> used this specific encoding. Bootloaders decode the OCOTP this way, but this
>>>>>> encoding isn't really an inherent attribute of the OCOTP. A new NXP SoC
>>>>>> with a different OTP IP will likely use the same format. Users may even
>>>>>> use the same format on an EEPROM to populate a second off-SoC interface, .. etc.
>>>>>>
>>>>> That is okay.
>>>> How would you go about using this same format on an EEPROM?
>>>
>>> Am guessing that by the time there are more users for such formats, those post-processing functions should be converted into some library functions.
>>
>> User A wants to reverse bytes in MAC address. User B stores it in ASCII.
>> Both use the exact same EEPROM. How could this ever work when the
>> encoding decision is left to the EEPROM driver?
> 
> User A and B should mention about this encoding information in there NVMEM provider bindings.
> 
> Based on that specific post-processing should be selected.

So instead of just compatible = "atmel,at24c16"; there will be

  compatible = "user-A,my-eeprom", "atmel,at24c16";

and 

  compatible = "user-B,my-eeprom", "atmel,at24c16";

and they each need to patch the at24 driver to call one of the
common library functions?

> 
> --srini
>>
> 
>>>
>>> --srini
>>>
>>>>
>>>>>> I'd thus prefer to not make this specific to the OCOTP as all:
>>>>>>
>>>>>>      * #define NVMEM_CELL_ENCODING_MAC_ADDRESS_IMX    /* ... */
>>>
>>
>>
> 


-- 
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 |