linux.git/include/linux/nvmem-provider.h, branch v6.7-rc2

Revert "nvmem: add new config option"

2023-10-27T11:17:54+00:00

This reverts commit 517f14d9cf3533d5ab4fded195ab6f80a92e378f.

Config option "no_of_node" is no longer needed since adding a more
explicit and targeted option "add_legacy_fixed_of_cells".

That "no_of_node" config option was needed *earlier* to help mtd's case.

DT nodes of MTD partitions (that are also NVMEM devices) may contain
subnodes. Those SHOULD NOT be treated as NVMEM fixed cells.

To prevent NVMEM core code from parsing subnodes a "no_of_node" option
was added (and set to true in mtd) to make for_each_child_of_node() in
NVMEM a no-op. That was a bit hacky because it was messing with
"of_node" pointer to achieve some side-effect.

With the introduction of "add_legacy_fixed_of_cells" config option
things got more explicit. MTD subsystem simply tells NVMEM when to look
for fixed cells and there is no need to hack "of_node" pointer anymore.

Signed-off-by: Rafał Miłecki 
Reviewed-by: Miquel Raynal 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20231023102759.31529-1-zajec5@gmail.com
Signed-off-by: Greg Kroah-Hartman

nvmem: add explicit config option to read old syntax fixed OF cells

2023-10-21T17:19:06+00:00

Binding for fixed NVMEM cells defined directly as NVMEM device subnodes
has been deprecated. It has been replaced by the "fixed-layout" NVMEM
layout binding.

New syntax is meant to be clearer and should help avoiding imprecise
bindings.

NVMEM subsystem already supports the new binding. It should be a good
idea to limit support for old syntax to existing drivers that actually
support & use it (we can't break backward compatibility!). That way we
additionally encourage new bindings & drivers to ignore deprecated
binding.

It wasn't clear (to me) if rtc and w1 code actually uses old syntax
fixed cells. I enabled them to don't risk any breakage.

Signed-off-by: Rafał Miłecki 
[for meson-{efuse,mx-efuse}.c]
Acked-by: Martin Blumenstingl 
[for mtk-efuse.c, nvmem/core.c, nvmem-provider.h]
Reviewed-by: AngeloGioacchino Del Regno 
[MT8192, MT8195 Chromebooks]
Tested-by: AngeloGioacchino Del Regno 
[for microchip-otpc.c]
Reviewed-by: Claudiu Beznea 
[SAMA7G5-EK]
Tested-by: Claudiu Beznea 
Acked-by: Jernej Skrabec 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20231020105545.216052-3-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman

nvmem: Add macro to register nvmem layout drivers

2023-04-05T17:41:13+00:00

Provide a module_nvmem_layout_driver() macro at the end of the
nvmem-provider.h header to reduce the boilerplate when registering nvmem
layout drivers.

Suggested-by: Srinivas Kandagatla 
Signed-off-by: Miquel Raynal 
Acked-by: Rafał Miłecki 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20230404172148.82422-37-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman

nvmem: core: support specifying both: cell raw data & post read lengths

2023-04-05T17:41:13+00:00

Callback .read_post_process() is designed to modify raw cell content
before providing it to the consumer. So far we were dealing with
modifications that didn't affect cell size (length). In some cases
however cell content needs to be reformatted and resized.

It's required e.g. to provide properly formatted MAC address in case
it's stored in a non-binary format (e.g. using ASCII).

There were few discussions how to optimally handle that. Following
possible solutions were considered:
1. Allow .read_post_process() to realloc (resize) content buffer
2. Allow .read_post_process() to adjust (decrease) just buffer length
3. Register NVMEM cells using post-read sizes

The preferred solution was the last one. The problem is that simply
adjusting "bytes" in NVMEM providers would result in core code NOT
passing whole raw data to .read_post_process() callbacks. It means
callback functions couldn't do their job without somehow manually
reading original cell content on their own.

This patch deals with that by registering NVMEM cells with both lengths:
raw content one and post read one. It allows:
1. Core code to read whole raw cell content
2. Callbacks to return content they want

Signed-off-by: Rafał Miłecki 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20230404172148.82422-35-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman

nvmem: core: provide own priv pointer in post process callback

2023-04-05T17:41:11+00:00

It doesn't make any more sense to have a opaque pointer set up by the
nvmem device. Usually, the layout isn't associated with a particular
nvmem device. Instead, let the caller who set the post process callback
provide the priv pointer.

Signed-off-by: Michael Walle 
Signed-off-by: Miquel Raynal 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20230404172148.82422-21-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman

nvmem: cell: drop global cell_post_process

2023-04-05T17:41:11+00:00

There are no users anymore for the global cell_post_process callback
anymore. New users should use proper nvmem layouts.

Signed-off-by: Michael Walle 
Signed-off-by: Miquel Raynal 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20230404172148.82422-20-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman

nvmem: core: allow to modify a cell before adding it

2023-04-05T17:41:11+00:00

Provide a way to modify a cell before it will get added. This is useful
to attach a custom post processing hook via a layout.

Signed-off-by: Michael Walle 
Signed-off-by: Miquel Raynal 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20230404172148.82422-18-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman

nvmem: core: add per-cell post processing

2023-04-05T17:41:11+00:00

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 
Signed-off-by: Miquel Raynal 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20230404172148.82422-17-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman

nvmem: core: introduce NVMEM layouts

2023-04-05T17:41:11+00:00

NVMEM layouts are used to generate NVMEM cells during runtime. Think of
an EEPROM with a well-defined conent. For now, the content can be
described by a device tree or a board file. But this only works if the
offsets and lengths are static and don't change. One could also argue
that putting the layout of the EEPROM in the device tree is the wrong
place. Instead, the device tree should just have a specific compatible
string.

Right now there are two use cases:
 (1) The NVMEM cell needs special processing. E.g. if it only specifies
     a base MAC address offset and you need to add an offset, or it
     needs to parse a MAC from ASCII format or some proprietary format.
     (Post processing of cells is added in a later commit).
 (2) u-boot environment parsing. The cells don't have a particular
     offset but it needs parsing the content to determine the offsets
     and length.

Co-developed-by: Miquel Raynal 
Signed-off-by: Miquel Raynal 
Signed-off-by: Michael Walle 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20230404172148.82422-14-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman

nvmem: core: add nvmem_add_one_cell()

2023-02-06T18:06:59+00:00

Add a new function to add exactly one cell. This will be used by the
nvmem layout drivers to add custom cells. In contrast to the
nvmem_add_cells(), this has the advantage that we don't have to assemble
a list of cells on runtime.

Signed-off-by: Michael Walle 
Signed-off-by: Srinivas Kandagatla 
Link: https://lore.kernel.org/r/20230206134356.839737-16-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman