The nvmem devices description works like this:
* Most cases (EEPROM & co):
eeprom@x {
compatible = "<eeprom-compatible>";
...
};
* MTD case:
flash@y {
compatible = "<flash-compatible>";
...
otp {
compatible = "user-otp"; /* or "factory-otp" */
...
};
};
In the former case, the nvmem device is "eeprom@x", while in the latter
case the nvmem device is "otp".
Nvmem devices can produce nvmem cells. The current way to describe nvmem
cells is to locate them by providing their static byte and bit offset
and length. These information are stored in subnodes of the nvmem
device.
It is now a fact that such description does not fit more advanced use
cases where the location or the size of the cells may vary. There are
currently three known situations which require being described
differently: Kontron's SL28 VPD, ONIE's TLV table and U-Boot's
environment variables.
Hence, we need a way to describe the parsers that must be used in order
to make the dynamic discovery of the nvmem cells. This new description
must fit both use cases (the generic situation and the MTD case).
Let's create in both cases a container node named nvmem-layout whose
content will depend on the parser. Right now nvmem-layout.yaml is
"empty", but references to additional layout parser bindings will be
inserted in the near future. The final goal being something that looks
like:
* Most cases (EEPROM & co):
eeprom@x {
compatible = "<eeprom-compatible>";
...
nvmem-layout {
compatible = "<parser-compatible>";
...
};
};
* MTD case:
flash@y {
compatible = "<flash-compatible>";
...
otp {
compatible = "user-otp"; /* or "factory-otp" */
...
nvmem-layout {
compatible = "<parser-compatible>";
...
};
};
};
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20221118063932.6418-10-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Despite not being listed nor required within the top level nvmem yaml
file, the "compatible" property is mandatory and is actually enforced by
all the nvmem provider bindings.
Unfortunately, the lack of compatible in the nvmem.yaml to level
description file lead to the example not matching anything and thus not
being checked at all.
Let's pick a compatible almost randomly (one which is already used with
the qfprom label) to make the example at least valid on a semantic
point of view and getting it checked.
Signed-off-by: Miquel Raynal <miquel.raynal@bootlin.com>
Acked-by: Rob Herring <robh@kernel.org>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20221118063932.6418-7-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The YAML DT encoding has leaked into some array properties. Properties
which are defined as an array should have a schema that's just an array.
That means there should only be a single level of 'minItems',
'maxItems', and/or 'items'.
Signed-off-by: Rob Herring <robh@kernel.org>
Acked-by: Marc Kleine-Budde <mkl@pengutronix.de>
Link: https://lore.kernel.org/r/20220119015627.2443334-1-robh@kernel.org
Allow to extend expression of sub nodes to optionally indicate bit
position. This extension is needed to distinguish between different bit
positions in the same address.
For example, there are two nvmem nodes starting with bit 4 and bit 0
at the same address 0x54. In this case, it can be expressed as follows.
trim@54,4 {
reg = <0x54 1>;
bits = <4 2>;
};
trim@54,0 {
reg = <0x54 1>;
bits = <0 4>;
};
Signed-off-by: Kunihiko Hayashi <hayashi.kunihiko@socionext.com>
Link: https://lore.kernel.org/r/1626661864-15473-2-git-send-email-hayashi.kunihiko@socionext.com
Signed-off-by: Rob Herring <robh@kernel.org>
Introduce boolean property st,non-secure-otp for OTP data located
in a factory programmed area that only secure firmware can access
by default and that shall be reachable from the non-secure world.
This change also allows additional properties for NVMEM nodes that
were forbidden prior this change.
Signed-off-by: Etienne Carriere <etienne.carriere@st.com>
Signed-off-by: Rob Herring <robh@kernel.org>
Several memories have a write-protect pin, that when pulled high, it
blocks the write operation.
On some boards, this pin is connected to a GPIO and pulled high by
default, which forces the user to manually change its state before
writing.
Instead of modifying all the memory drivers to check this pin, make
the NVMEM subsystem check if the write-protect GPIO being passed
through the nvmem_config or defined in the device tree and pull it
low whenever writing to the memory.
Add a new optional property to the device tree binding document, which
allows to specify the GPIO line to which the write-protect pin is
connected.
Signed-off-by: Khouloud Touil <ktouil@baylibre.com>
Reviewed-by: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
The nvmem providers and consumers have a bunch of generic properties that
are needed in a device tree. Add a YAML schemas for those.
Reviewed-by: Rob Herring <robh@kernel.org>
Signed-off-by: Maxime Ripard <maxime.ripard@bootlin.com>
[Srini: Changed licence to (GPL-2.0 OR BSD-2-Clause)]
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Signed-off-by: Rob Herring <robh@kernel.org>
