netdev - Re: [PATCH v1 07/14] nvmem: core: add per-cell post processing

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: <ddae21bf-a51b-7266-60ba-8a10c293888a@linaro.org>
Date:   Tue, 30 Aug 2022 14:37:04 +0100
From:   Srinivas Kandagatla <srinivas.kandagatla@...aro.org>
To:     Michael Walle <michael@...le.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>
Cc:     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 07/14] nvmem: core: add per-cell post processing



On 25/08/2022 22:44, Michael Walle wrote:
> Instead of relying on the name the consumer is using for the cell, like
> it is done for the nvmem .cell_post_process configuration parameter,
> provide a per-cell post processing hook. This can then be populated by
> the NVMEM provider (or the NVMEM layout) when adding the cell.
> 
> Signed-off-by: Michael Walle <michael@...le.cc>
> ---
>   drivers/nvmem/core.c           | 16 ++++++++++++++++
>   include/linux/nvmem-consumer.h |  5 +++++
>   2 files changed, 21 insertions(+)
> 
> diff --git a/drivers/nvmem/core.c b/drivers/nvmem/core.c
> index 5357fc378700..cbfbe6264e6c 100644
> --- a/drivers/nvmem/core.c
> +++ b/drivers/nvmem/core.c
> @@ -52,6 +52,7 @@ struct nvmem_cell_entry {
>   	int			bytes;
>   	int			bit_offset;
>   	int			nbits;
> +	nvmem_cell_post_process_t post_process;


two post_processing callbacks for cells is confusing tbh, we could 
totally move to use of cell->post_process.

one idea is to point cell->post_process to nvmem->cell_post_process 
during cell creation time which should clean this up a bit.

Other option is to move to using layouts for every thing.

prefixing post_process with read should also make it explicit that this 
callback is very specific to reads only.


>   	struct device_node	*np;
>   	struct nvmem_device	*nvmem;
>   	struct list_head	node;
> @@ -468,6 +469,7 @@ static int nvmem_cell_info_to_nvmem_cell_entry_nodup(struct nvmem_device *nvmem,
>   	cell->offset = info->offset;
>   	cell->bytes = info->bytes;
>   	cell->name = info->name;
> +	cell->post_process = info->post_process;
>   
>   	cell->bit_offset = info->bit_offset;
>   	cell->nbits = info->nbits;
> @@ -1500,6 +1502,13 @@ static int __nvmem_cell_read(struct nvmem_device *nvmem,
>   	if (cell->bit_offset || cell->nbits)
>   		nvmem_shift_read_buffer_in_place(cell, buf);
>   
> +	if (cell->post_process) {
> +		rc = cell->post_process(nvmem->priv, id, index,
> +					cell->offset, buf, cell->bytes);
> +		if (rc)
> +			return rc;
> +	}
> +
>   	if (nvmem->cell_post_process) {
>   		rc = nvmem->cell_post_process(nvmem->priv, id, index,
>   					      cell->offset, buf, cell->bytes);
> @@ -1608,6 +1617,13 @@ static int __nvmem_cell_entry_write(struct nvmem_cell_entry *cell, void *buf, si
>   	    (cell->bit_offset == 0 && len != cell->bytes))
>   		return -EINVAL;
>   
> +	/*
> +	 * Any cells which have a post_process hook are read-only because we
> +	 * cannot reverse the operation and it might affect other cells, too.
> +	 */
> +	if (cell->post_process)
> +		return -EINVAL;

Post process was always implicitly for reads only, this check should 
also tie the loose ends of cell_post_processing callback.


--srini
> +
>   	if (cell->bit_offset || cell->nbits) {
>   		buf = nvmem_cell_prepare_write_buffer(cell, buf, len);
>   		if (IS_ERR(buf))
> diff --git a/include/linux/nvmem-consumer.h b/include/linux/nvmem-consumer.h
> index 980f9c9ac0bc..761b8ef78adc 100644
> --- a/include/linux/nvmem-consumer.h
> +++ b/include/linux/nvmem-consumer.h
> @@ -19,6 +19,10 @@ struct device_node;
>   struct nvmem_cell;
>   struct nvmem_device;
>   
> +/* duplicated from nvmem-provider.h */
> +typedef int (*nvmem_cell_post_process_t)(void *priv, const char *id, int index,
> +					 unsigned int offset, void *buf, size_t bytes);
> +
>   struct nvmem_cell_info {
>   	const char		*name;
>   	unsigned int		offset;
> @@ -26,6 +30,7 @@ struct nvmem_cell_info {
>   	unsigned int		bit_offset;
>   	unsigned int		nbits;
>   	struct device_node	*np;
> +	nvmem_cell_post_process_t post_process;
>   };
>   
>   /**