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 v2 1/3] nvmem: core: introduce cells parser
To:     Vadym Kochan <vadym.kochan@plvision.eu>
Cc:     Rob Herring <robh+dt@kernel.org>, linux-kernel@vger.kernel.org,
        devicetree@vger.kernel.org, Robert Marko <robert.marko@sartura.hr>
References: <20210608190327.22071-1-vadym.kochan@plvision.eu>
 <20210608190327.22071-2-vadym.kochan@plvision.eu>
 <43023500-dd6a-5180-057e-cecc1f1b6500@linaro.org>
 <20210616123356.GA9951@plvision.eu>
 <fea907ed-06ce-5c82-667d-d11f3e902616@linaro.org>
 <vrcxh2zgsnl841.fsf@plvision.eu>
 <7e6d75ed-cebc-597f-7062-34261d184968@linaro.org>
 <vrcxh2pmt3bl4h.fsf@plvision.eu>
From:   Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Message-ID: <0e471789-fe29-b747-5153-75c9b4616c7f@linaro.org>
Date:   Mon, 20 Sep 2021 11:36:08 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.11.0
MIME-Version: 1.0
In-Reply-To: <vrcxh2pmt3bl4h.fsf@plvision.eu>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Precedence: bulk


On 20/09/2021 11:24, Vadym Kochan wrote:
>>>
>>> Probably this might be fixed by lookup nvmem device too ?
>> Honestly, this approach is a total hack to get it working.
>>
>> This is what Am thinking which should look like:
>>
>> ## DT ##
>> eeprom_at24: at24@56 {
>> 	compatible = "atmel,24c32";
>> 	/* Some way to identify that this is a TLV data */
>> 	nvmem-cell-parser-name = "onie-tlv-cells";
>> 	reg = <0x56>;
>>
>> 	mac_address: mac-address {
>> 		/* THIS REG is updated once TLV is parsed */
>> 		reg = <0 0x6>
>> 	};
> I assume these cell nodes should be marked with some property that they
> should be evaluated later, so the cell will be not read
> in case it was not parsed because it may
> exist in nvmem device optionally.
No, we should hit that use case to start with.

nvmem cells are parsed in the core during register path.
Parser should parse the cells before this to keep it simple.

> 
> Or, treat cells with length "0" in a special way and allow to update
> cell info later.you can update irrespective of the length, as long as this is done 
before register.


> 
>> };
>>
>> some_dev_node {
>> 	compatible = "xxx";
>> 	nvmem-cells = <&mac_address>;
>> 	nvmem-cell-names = "mac-address";
>> };
>>
>> == CODE ==
>> ret = of_get_mac_address(dev->of_node, base_mac);
>> ==========
>>
>>
>> If you notice the mac_address node reg is 0.
>> This node "reg" property should be updated ( using of_update_property())
>> by nvmem-provider driver while tlv parsing and by matching the node name
>> with tlv name.
>>
> I assume parser driver can just invoke add_cell_table (with may be
> by adding 'bool update' field to the cell_info struct) and core.c will just
> update existing cells parsed from OF.
> 

Lets keep the core code clean for now, I would expect the provider 
driver along with parser function to do update the nodes.

--srini

>> That way rest of the code will work as usual.
>>
>> If this work for you then we can ask Rob if he foresee any issues in
>> this approach. I already see similar usage in reserved-memory case.