linux-kernel - Re: [PATCH v2 1/3] nvmem: core: introduce cells parser

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <vrcxh2mto7bfcb.fsf@plvision.eu>
Date:   Mon, 20 Sep 2021 15:29:08 +0300
From:   Vadym Kochan <vadym.kochan@...ision.eu>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:     Vadym Kochan <vadym.kochan@...ision.eu>,
        Rob Herring <robh+dt@...nel.org>, linux-kernel@...r.kernel.org,
        devicetree@...r.kernel.org, Robert Marko <robert.marko@...tura.hr>
Subject: Re: [PATCH v2 1/3] nvmem: core: introduce cells parser


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

> On 20/09/2021 12:25, Vadym Kochan wrote:
>>>> 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
>>>
>> core.c sequence:
>> 
>> 1) after cells parsed from OF:
>> 
>> 2) lookup the parser
>> 
>> 3) parser->cells_parse(ctx, table)
>> 
>> 3.a) update existing cells matched by name from table
>> 
>> 4) parser->cells_clean(ctx, table)
>> /* to free cell's_info allocated by the parser driver */
>> 
>> as alternative way, I think it would be more generic to
>> provide nvmem-provider.h API to update the existing cell info,
>> however it makes sense only when cells were parsed
>> by the cell parser, in the other situations the
>> cell should be well defined.
>> 
>> with this approach the parser driver will be just called
>> via parser->cells_parse(ctx) and will call nvmem_cell_info_update()
>> for each parsed cells.
>
> TBH, This is an over kill.
>
> In nvmem provider driver probe you can parse the tlv data and update the 
> dt nodes before nvmem register.
>
> rest of the code should just work as it is.
>
> --srini

You mean to parse TLV in the particular nvmem provider driver (for
example in at24 driver) ? If so, then it will not allow to parse
this TLV format from the other kinds of nvmem.

>
>
>>