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;
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>
 <0e471789-fe29-b747-5153-75c9b4616c7f@linaro.org>
 <vrcxh2o88nbias.fsf@plvision.eu>
 <1da03714-8f23-1004-e89a-891e4599e04a@linaro.org>
 <vrcxh2mto7bfcb.fsf@plvision.eu>
 <1e146349-9fef-972b-9084-577f02d5168b@linaro.org>
 <vrcxh2lf3rbcjc.fsf@plvision.eu>
 <169d3f36-4297-32a3-3d23-824989625b26@linaro.org>
 <77b11bf7-3003-483f-b91e-bd93576eaae1@www.fastmail.com>
 <vrcxh2y27ia23n.fsf@plvision.eu>
 <56fb5c64-4142-03ef-2ea8-fc586fd239e1@linaro.org>
User-agent: mu4e 0.9.18; emacs 28.0.50
From:   Vadym Kochan <vadym.kochan@plvision.eu>
To:     Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Cc:     Vadym Kochan <vadym.kochan@plvision.eu>,
        John Thomson <john@johnthomson.fastmail.com.au>,
        Rob Herring <robh+dt@kernel.org>, linux-kernel@vger.kernel.org,
        devicetree@vger.kernel.org, Robert Marko <robert.marko@sartura.hr>
Subject: Re: [PATCH v2 1/3] nvmem: core: introduce cells parser
In-reply-to: <56fb5c64-4142-03ef-2ea8-fc586fd239e1@linaro.org>
Date:   Tue, 28 Sep 2021 16:31:13 +0300
Message-ID: <vrcxh2tui4akta.fsf@plvision.eu>
Content-Type: text/plain
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?Q7I+f7RYhnhCSeliqIThxlPWI8ixq1Obzwkb0NUlqJLhvimBUbCY+MCi2P9w?=
 =?us-ascii?Q?92SsK2lOyP1Tin9NcxoXblP2QH+0B99KtRtDI0Zq3Ek9cqOueJuHgBPhE34+?=
 =?us-ascii?Q?LJW0g5fxMs8PZeuScmGz+ch5sCfS3G5+CRjrs5SGerXd/h41vANR3ECmyP2p?=
 =?us-ascii?Q?vBt+Wr3g3lBuyrrvWebrjRBhqWRasbAp+ljGA0fNxpub9Ni6njv7r5YSuSU2?=
 =?us-ascii?Q?I6c0DxwHacfnAdD9GtDFR7ccGrddRtSNc0DB5e2SmtAdv1znnA4Y9AFbKKO9?=
 =?us-ascii?Q?07A5lvLnjQpZHbB4ebF+v5HjSBvDMsRhdeYfdWTo/GwyrbpXoKp2LaXUsBx2?=
 =?us-ascii?Q?bx6Qdi+0Zr347x30E8VzDfelmS4zVTEp6qbNKujrfDRvmdDP7pXBT9zEb8G6?=
 =?us-ascii?Q?1/RHKYQw0/NW/ogAWQUUlrYNThbLepbtBDRn7Xw1nyPeNSMyLZgN7ekxTjFm?=
 =?us-ascii?Q?bc0sG28Ert4czQdX/QygIRMcs8t2Pk142rZG3KgLYFMJ5yuVbEVjFZaZo31P?=
 =?us-ascii?Q?Qho4DebJh4T5mrybUQZNIlbqF1lEs4FGtICZtg9ZYepW2Ns762wPjVoMu/Ha?=
 =?us-ascii?Q?bDnNVYxTlhAZcOoqZ368/aBgWzzUmRGe2mkOSGWPkLZ25c88WdTr7ZvZct8T?=
 =?us-ascii?Q?T3Av7dqJiRs2fGPoyr5pNCiUQCf7c0bEPOnCEkO6ijX0zrI0uvEHebHjOyZn?=
 =?us-ascii?Q?Xo6NsSYFwMxGW2GKqBuqcT0GiewWk7ES2GCuVCuvNg9HOVx6921u0atcEJPm?=
 =?us-ascii?Q?sen87rq4g6myeQ600iEKZirf+IawvgSxBT46q1QSfT+gl/MN9jAqNepDnUyc?=
 =?us-ascii?Q?tSUFFb76FTPLI1n7vN/wQjOzAIbu5oU/lRykD/oyhxA9P9/sgC8D0y8Q7G2X?=
 =?us-ascii?Q?c4QA9BxHtfZBM5YsTBOZUu+Nw2vPCnMj39sRknn8m1QmuEWgexvOzZDdwTUc?=
 =?us-ascii?Q?P1dOrRWftNnOY1AR04OlMeqN9ViWjR9BFjJPTHdlQvTmq3dyzx7YDemjLcvb?=
 =?us-ascii?Q?3v/Hn9W4weFnGbcUyeIpp5MAgYHa+IVhjsLdkP9tN/nNvIDCz/z3iZAVpds9?=
 =?us-ascii?Q?qpmjJjmwdA/WqEpSnBJRSwzDH2ZsShhhjjVbzU6RJHhUCLKLHz1C/Ac20v2b?=
 =?us-ascii?Q?7dKXmakrWkRM45nKW2FAfL+IdQXrTUI0pLSr/vjz6qMJCFvZ4uP7nZMo9i+n?=
 =?us-ascii?Q?U8VMN8azF3unv+YI7aeGB739YNT0pAszGAiD4UB61iCag/qU6FXFprRTzFzz?=
 =?us-ascii?Q?iDg5IhtXlzp8EvSgn8SPVIcsC1PgpS+rwq4zZU5QSq/mCweqod9n0PzS8wvN?=
 =?us-ascii?Q?QOXmhHs1H2C/vQHEwnM9kPwb?=
X-OriginatorOrg: plvision.eu
X-MS-Exchange-CrossTenant-Network-Message-Id: 8aecf4df-5b84-4dd2-6324-08d982843f76
X-MS-Exchange-CrossTenant-AuthSource: AS8P190MB1063.EURP190.PROD.OUTLOOK.COM
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 28 Sep 2021 13:31:16.4420
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 03707b74-30f3-46b6-a0e0-ff0a7438c9c4
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: ovewR/8KqlxQlBeWBITGZIppZe5YAdfSdRphcCsO9Xm0yde142ZnOc6j+3aF1iibMAqKAuz3oYFd7S17B+f5OKK1x1c5C5TG+Rbx5pg6RQ4=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8P190MB1319
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org


Srinivas Kandagatla <srinivas.kandagatla@linaro.org> writes:

> On 27/09/2021 08:50, Vadym Kochan wrote:
>>>>> Currently I can test only on at24 devices. From the:
>>>>>
>>>>> https://opencomputeproject.github.io/onie/design-spec/hw_requirements.html
>>>>>
>>>>> "
>>>>> Each ONIE system must include non-volatile storage which contains vital
>>>>> product data assigned by the manufacturer. The non-volatile storage
>>>>> could take the form of an EEPROM, a NOR-flash sector, a NAND-flash
>>>>> sector or any other non-volatile storage medium.
>>>>> "
>>>>>
>>>>> I am not aware about other nvmem devices which are used for existing
>>>>> ONIE supported boards.
>>>>>
>>>>>> As long as you represent this parsing function as some library function,
>>>>>> I do not see any issue.
>>>>>> If any exported symbol is available for this then any nvmem provider
>>>>>> could use it.
>>>>>>
>>>>>> --srini
>>>>>>
>>> Hi Srinivas,
>>>
>>> Can I note here that I would like to parse
>>> TLV data from an SPI-NOR device to NVMEM cells.
>>> The same general use case (getting mac-address from OEM data).
>>>
>>> Was planning to base my work on this series, as well as
>>> https://lore.kernel.org/all/20210908100257.17833-1-qiangqing.zhang@nxp.com/
>>> (thanks for pointing that out Srinivas)
>>>
>>> Cheers,
>> What about at least to have just one call in core.c to make it a bit
>> de-coupled, like:
>
> Why do you want to decouple this? the provider driver should be very 
> well aware of the format the data layout.
>

In my understanding nvmem device should not aware about the data layout
(in case it does not rely on device's specific characteristics). Same
cells layout (TLV, etc) might exist on other nvmem devices.

> Its fine to an extent to adding parse_cells() callback in nvmem_config.
>

OK, in that case it will require small change in the core.

>> 
>> core.c
>> 
>> struct nvmem_device *nvmem_register(const struct nvmem_config *config)
>> {
>> ...
>>           rval = nvmem_add_cells_from_table(nvmem);
>>           if (rval)
>>                   goto err_remove_cells;
>> 
>> +        rval = nvmem_parse_cells(nvmem, of);
>> +        if (rval) {
>> +        /* err handling */
>> +        }
>> +
>>           rval = nvmem_add_cells_from_of(nvmem);
>>           if (rval)
>>                   goto err_remove_cells;
>> 
>>           blocking_notifier_call_chain(&nvmem_notifier, NVMEM_ADD, nvmem);
>> 
>>           return nvmem;
>> 
>> ...
>> 
>> }
>> 
>
>> somewhere in nvmem-parser.c:
>
> However this is totally over kill.
>
>> 
>> /* retreive parser name from of_node and call appropriate function to parse
>>     non-fixed cells and update via of_update */
>
> This is completely provider drivers job, nothing nvmem core should worry 
> about.
>
> If you have concern of having code duplicated then we could make some of 
> the common functions as library functions, But it still is within the 
> scope of provider drivers.
>

Do I understand correctly that this parser function should be exported
from at24.c (in case of ONIE) and not from a separate C module ? Or
it just means that if there will be more users of this parsing function
then it might be moved to separate C module ?

> --srini
>

BTW, what if such change will be declined by particular nvmem driver
maintainer ?

>> int nvmem_parse_cells(struct nvmem_device *nvmem, struct device_node *of_node)
>> {
>>      ...
>> }
>> 
>> ?
>
>
>> 
>> Regards,