linux-kernel - Re: [PATCH v1 06/14] nvmem: core: introduce NVMEM layouts

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: <c2e3a05339d54123de539fd124e874bb@walle.cc>
Date:   Tue, 30 Aug 2022 17:02:02 +0200
From:   Michael Walle <michael@...le.cc>
To:     Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
Cc:     Miquel Raynal <miquel.raynal@...tlin.com>,
        Richard Weinberger <richard@....at>,
        Vignesh Raghavendra <vigneshr@...com>,
        Rob Herring <robh+dt@...nel.org>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
        Shawn Guo <shawnguo@...nel.org>, Li Yang <leoyang.li@....com>,
        Rafał Miłecki <rafal@...ecki.pl>,
        "David S . Miller" <davem@...emloft.net>,
        Eric Dumazet <edumazet@...gle.com>,
        Jakub Kicinski <kuba@...nel.org>,
        Paolo Abeni <pabeni@...hat.com>,
        Frank Rowand <frowand.list@...il.com>,
        linux-mtd@...ts.infradead.org, devicetree@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        netdev@...r.kernel.org, Ahmad Fatoum <a.fatoum@...gutronix.de>
Subject: Re: [PATCH v1 06/14] nvmem: core: introduce NVMEM layouts

Am 2022-08-30 16:43, schrieb Srinivas Kandagatla:

>>>> diff --git a/drivers/nvmem/layouts/Makefile 
>>>> b/drivers/nvmem/layouts/Makefile
>>>> new file mode 100644
>>>> index 000000000000..6fdb3c60a4fa
>>>> --- /dev/null
>>>> +++ b/drivers/nvmem/layouts/Makefile
>>>> @@ -0,0 +1,4 @@
>>>> +# SPDX-License-Identifier: GPL-2.0
>>>> +#
>>>> +# Makefile for nvmem layouts.
>>>> +#
>>>> diff --git a/include/linux/nvmem-provider.h 
>>>> b/include/linux/nvmem-provider.h
>>>> index e710404959e7..323685841e9f 100644
>>>> --- a/include/linux/nvmem-provider.h
>>>> +++ b/include/linux/nvmem-provider.h
>>>> @@ -127,6 +127,28 @@ struct nvmem_cell_table {
>>>>       struct list_head    node;
>>>>   };
>>>>   +/**
>>>> + * struct nvmem_layout - NVMEM layout definitions
>>>> + *
>>>> + * @name:        Layout name.
>>>> + * @of_match_table:    Open firmware match table.
>>>> + * @add_cells:        Will be called if a nvmem device is found 
>>>> which
>>>> + *            has this layout. The function will add layout
>>>> + *            specific cells with nvmem_add_one_cell().
>>>> + * @node:        List node.
>>>> + *
>>>> + * A nvmem device can hold a well defined structure which can just 
>>>> be
>>>> + * evaluated during runtime. For example a TLV list, or a list of 
>>>> "name=val"
>>>> + * pairs. A nvmem layout can parse the nvmem device and add 
>>>> appropriate
>>>> + * cells.
>>>> + */
>>>> +struct nvmem_layout {
>>>> +    const char *name;
>>>> +    const struct of_device_id *of_match_table;
>>> 
>>> looking at this, I think its doable to convert the existing
>>> cell_post_process callback to layouts by adding a layout specific
>>> callback here.
>> 
>> can you elaborate on that?
> 
> If we relax add_cells + add nvmem_unregister_layout() and update
> struct nvmem_layout to include post_process callback like
> 
> struct nvmem_layout {
> 	const char *name;
> 	const struct of_device_id *of_match_table;
> 	int (*add_cells)(struct nvmem_device *nvmem, struct nvmem_layout 
> *layout);
> 	struct list_head node;
> 	/* default callback for every cell */
> 	nvmem_cell_post_process_t post_process;
> };
> 
> then we can move imx-ocotp to this layout style without add_cell
> callback, and finally get rid of cell_process_callback from both
> nvmem_config and nvmem_device.
> 
> If layout specific post_process callback is available and cell does
> not have a callback set then we can can be either updated cell
> post_process callback with this one or invoke layout specific callback
> directly.
> 
> does that make sense?

Yes I get what you mean. BUT I'm not so sure; it mixes different
things together. Layouts will add cells, analogue to
nvmem_add_cells_from_of() or nvmem_add_cells_from_table(). With
the hook above, the layout mechanism is abused to add post
processing to cells added by other means.

What is then the difference to the driver having that "global"
post process hook?

The correct place to add the per-cell hook in this case would be
nvmem_add_cells_from_of().

-michael