Thread (49 messages) 49 messages, 7 authors, 2022-09-02

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

From: Srinivas Kandagatla <hidden>
Date: 2022-08-30 13:37:20
Also in: linux-arm-kernel, linux-devicetree, lkml


On 25/08/2022 22:44, Michael Walle wrote:
quoted hunk ↗ jump to hunk
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 <redacted>
---
  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.

quoted hunk ↗ jump to hunk
  	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
quoted hunk ↗ jump to hunk
+
  	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;
  };
  
  /**
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help