nvmem: Add R-Car E-FUSE driver

R-Car Gen4 SoCs contain fuses indicating hardware support or hardware
(e.g. tuning) parameters. Add a driver to access the state of the
fuses. This supports two type

nvmem: Add R-Car E-FUSE driver

R-Car Gen4 SoCs contain fuses indicating hardware support or hardware
(e.g. tuning) parameters. Add a driver to access the state of the
fuses. This supports two types of hardware fuse providers:
1. E-FUSE non-volatile memory accessible through the Pin Function
Controller on R-Car V3U and S4-8,
2. E-FUSE non-volatile memory accessible through OTP_MEM on R-Car V4H
and V4M.

The state of the cells can be read using the NVMEM framework, either
from kernel space (e.g. by the Renesas UFSHCD driver), or from
userspace.

Signed-off-by: Geert Uytterhoeven <[email protected]>
Reviewed-by: Yoshihiro Shimoda <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: layouts: add U-Boot env layout

U-Boot environment variables are stored in a specific format. Actual
data can be placed in various storage sources (MTD, UBI volume, EEPROM,
NVRAM, etc.).

Move

nvmem: layouts: add U-Boot env layout

U-Boot environment variables are stored in a specific format. Actual
data can be placed in various storage sources (MTD, UBI volume, EEPROM,
NVRAM, etc.).

Move all generic (NVMEM device independent) code from NVMEM device
driver to an NVMEM layout driver. Then add a simple NVMEM layout code on
top of it.

This allows using NVMEM layout for parsing U-Boot env data stored in any
kind of NVMEM device.

The old NVMEM glue driver stays in place for handling bindings in the
MTD context. To avoid code duplication it uses exported layout parsing
function. Please note that handling MTD & NVMEM layout bindings may be
refactored in the future.

Signed-off-by: Rafał Miłecki <[email protected]>
Reviewed-by: Miquel Raynal <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: core: Rework layouts to become regular devices

Current layout support was initially written without modules support in
mind. When the requirement for module support rose, the existing base
wa

nvmem: core: Rework layouts to become regular devices

Current layout support was initially written without modules support in
mind. When the requirement for module support rose, the existing base
was improved to adopt modularization support, but kind of a design flaw
was introduced. With the existing implementation, when a storage device
registers into NVMEM, the core tries to hook a layout (if any) and
populates its cells immediately. This means, if the hardware description
expects a layout to be hooked up, but no driver was provided for that,
the storage medium will fail to probe and try later from
scratch. Even if we consider that the hardware description shall be
correct, we could still probe the storage device (especially if it
contains the rootfs).

One way to overcome this situation is to consider the layouts as
devices, and leverage the native notifier mechanism. When a new NVMEM
device is registered, we can populate its nvmem-layout child, if any,
and wait for the matching to be done in order to get the cells (the
waiting can be easily done with the NVMEM notifiers). If the layout
driver is compiled as a module, it should automatically be loaded. This
way, there is no strong order to enforce, any NVMEM device creation
or NVMEM layout driver insertion will be observed as a new event which
may lead to the creation of additional cells, without disturbing the
probes with costly (and sometimes endless) deferrals.

In order to achieve that goal we create a new bus for the nvmem-layouts
with minimal logic to match nvmem-layout devices with nvmem-layout
drivers. All this infrastructure code is created in the layouts.c file.

Signed-off-by: Miquel Raynal <[email protected]>
Tested-by: Rafał Miłecki <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: sec-qfprom: Add Qualcomm secure QFPROM support

For some of the Qualcomm SoC's, it is possible that
some of the fuse regions or entire qfprom region is
protected from non-secure access. In suc

nvmem: sec-qfprom: Add Qualcomm secure QFPROM support

For some of the Qualcomm SoC's, it is possible that
some of the fuse regions or entire qfprom region is
protected from non-secure access. In such situations,
the OS will have to use secure calls to read the region.
With that motivation, add secure qfprom driver.

Signed-off-by: Komal Bajaj <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: Kconfig: Fix typo "drive" -> "driver"

Fix typo where "driver" was meant instead of "drive".
While at it, also capitalize "OTP".

Signed-off-by: Diederik de Haas <[email protected]>
Review

nvmem: Kconfig: Fix typo "drive" -> "driver"

Fix typo where "driver" was meant instead of "drive".
While at it, also capitalize "OTP".

Signed-off-by: Diederik de Haas <[email protected]>
Reviewed-by: Heiko Stuebner <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: add new NXP QorIQ eFuse driver

Add SFP (Security Fuse Processor) read support for NXP (Freescale)
QorIQ series SOC's.

This patch adds support for the T1023 SOC using the SFP offset from
the

nvmem: add new NXP QorIQ eFuse driver

Add SFP (Security Fuse Processor) read support for NXP (Freescale)
QorIQ series SOC's.

This patch adds support for the T1023 SOC using the SFP offset from
the existing T1023 device tree. In theory this should also work for
T1024, T1014 and T1013 which uses the same SFP base offset.

Signed-off-by: Richard Alpe <[email protected]>
Reviewed-by: Niklas Söderlund <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: imx: support i.MX93 OCOTP

Add i.MX93 OCOTP support. i.MX93 OCOTP has two parts: Fuse shadow
block(fsb) and fuse managed by ELE. The FSB part could be directly
accessed with MMIO, the ELE coul

nvmem: imx: support i.MX93 OCOTP

Add i.MX93 OCOTP support. i.MX93 OCOTP has two parts: Fuse shadow
block(fsb) and fuse managed by ELE. The FSB part could be directly
accessed with MMIO, the ELE could only be accessed with ELE API.

Currently the ELE API is not ready, so NULL function callback is used,
but it was tested with downstream ELE API.

Signed-off-by: Peng Fan <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: brcm_nvram: add .read_post_process() for MACs

1. Parse ASCII MAC format into byte based
2. Calculate relative addresses based on index argument

Signed-off-by: Rafał Miłecki <[email protected]

nvmem: brcm_nvram: add .read_post_process() for MACs

1. Parse ASCII MAC format into byte based
2. Calculate relative addresses based on index argument

Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Message-ID: <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: u-boot-env: post-process "ethaddr" env variable

U-Boot environment variables are stored in ASCII format so "ethaddr"
requires parsing into binary to make it work with Ethernet interfaces.

Th

nvmem: u-boot-env: post-process "ethaddr" env variable

U-Boot environment variables are stored in ASCII format so "ethaddr"
requires parsing into binary to make it work with Ethernet interfaces.

This includes support for indexes to support #nvmem-cell-cells = <1>.

Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: core: introduce NVMEM layouts

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 t

nvmem: core: introduce NVMEM layouts

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 <[email protected]>
Signed-off-by: Miquel Raynal <[email protected]>
Signed-off-by: Michael Walle <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: xilinx: zynqmp: make modular

This driver has a MODULE_LICENSE but is not tristate so cannot be
built as a module, unlike all its peers: make it modular to match.

Signed-off-by: Nick Alcock <

nvmem: xilinx: zynqmp: make modular

This driver has a MODULE_LICENSE but is not tristate so cannot be
built as a module, unlike all its peers: make it modular to match.

Signed-off-by: Nick Alcock <[email protected]>
Suggested-by: Michal Simek <[email protected]>
Cc: Luis Chamberlain <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Hitomi Hasegawa <[email protected]>
Cc: Srinivas Kandagatla <[email protected]>
Cc: Michal Simek <[email protected]>
Cc: [email protected]
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: stm32: fix OPTEE dependency

The stm32 nvmem driver fails to link as built-in when OPTEE
is a loadable module:

aarch64-linux-ld: drivers/nvmem/stm32-bsec-optee-ta.o: in function `stm32_bsec:

nvmem: stm32: fix OPTEE dependency

The stm32 nvmem driver fails to link as built-in when OPTEE
is a loadable module:

aarch64-linux-ld: drivers/nvmem/stm32-bsec-optee-ta.o: in function `stm32_bsec:
stm32-bsec-optee-ta.c:(.text+0xc8): undefined reference to `tee_client_open_session'
aarch64-linux-ld: drivers/nvmem/stm32-bsec-optee-ta.o: in function `stm32_bsec:
stm32-bsec-optee-ta.c:(.text+0x1fc): undefined reference to `tee_client_open_context'

Change the CONFIG_NVMEM_STM32_ROMEM definition so it can only
be built-in if OPTEE is either built-in or disabled, and
make NVMEM_STM32_BSEC_OPTEE_TA a hidden symbol instead.

Signed-off-by: Arnd Bergmann <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: stm32: add OP-TEE support for STM32MP13x

For boot with OP-TEE on STM32MP13, the communication with the secure
world no more use STMicroelectronics SMC but communication with the
STM32MP BSEC

nvmem: stm32: add OP-TEE support for STM32MP13x

For boot with OP-TEE on STM32MP13, the communication with the secure
world no more use STMicroelectronics SMC but communication with the
STM32MP BSEC TA, for data access (read/write) or lock operation:
- all the request are sent to OP-TEE trusted application,
- for upper OTP with ECC protection and with word programming only
each OTP are permanently locked when programmed to avoid ECC error
on the second write operation

Signed-off-by: Patrick Delaunay <[email protected]>
Reviewed-by: Etienne Carriere <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: Kconfig: Fix spelling mistake "controlls" -> "controls"

There is a spelling mistake in a Kconfig description. Fix it.

Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Sr

nvmem: Kconfig: Fix spelling mistake "controlls" -> "controls"

There is a spelling mistake in a Kconfig description. Fix it.

Signed-off-by: Colin Ian King <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: lan9662-otp: add support

Add support for OTP controller available on LAN9662. The OTPC controls
the access to a non-volatile memory. The size of the memory is 8KB.
The OTPC can access the mem

nvmem: lan9662-otp: add support

Add support for OTP controller available on LAN9662. The OTPC controls
the access to a non-volatile memory. The size of the memory is 8KB.
The OTPC can access the memory based on an offset.
Implement both the read and the write functionality.

Signed-off-by: Horatiu Vultur <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: sort config symbols alphabetically

1. Match what most subsystems do
2. Simplify maintenance a bit
3. Reduce amount of conflicts for new drivers patches

While at it unify indent level in Make

nvmem: sort config symbols alphabetically

1. Match what most subsystems do
2. Simplify maintenance a bit
3. Reduce amount of conflicts for new drivers patches

While at it unify indent level in Makefile.

Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: prefix all symbols with NVMEM_

This unifies all NVMEM symbols. They follow one style now.

Reviewed-by: Matthias Brugger <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signe

nvmem: prefix all symbols with NVMEM_

This unifies all NVMEM symbols. They follow one style now.

Reviewed-by: Matthias Brugger <[email protected]>
Acked-by: Arnd Bergmann <[email protected]>
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: add driver handling U-Boot environment variables

U-Boot stores its setup as environment variables. It's a list of
key-value pairs stored on flash device with a custom header.

This commit add

nvmem: add driver handling U-Boot environment variables

U-Boot stores its setup as environment variables. It's a list of
key-value pairs stored on flash device with a custom header.

This commit adds an NVMEM driver that:
1. Provides NVMEM access to environment vars binary data
2. Extracts variables as NVMEM cells

Current Linux's NVMEM sysfs API allows reading whole NVMEM data block.
It can be used by user-space tools for reading U-Boot env vars block
without the hassle of finding its location. Parsing will still need to
be re-done there.

Kernel-parsed NVMEM cells can be read however by Linux drivers. This may
be useful for Ethernet drivers for reading device MAC address which is
often stored as U-Boot env variable.

Reviewed-by: Ahmad Fatoum <[email protected]>
Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: microchip-otpc: add support

Add support for Microchip OTP controller available on SAMA7G5. The OTPC
controls the access to a non-volatile memory. The memory behind OTPC is
organized into pack

nvmem: microchip-otpc: add support

Add support for Microchip OTP controller available on SAMA7G5. The OTPC
controls the access to a non-volatile memory. The memory behind OTPC is
organized into packets, packets are composed by a fixed length header
(4 bytes long) and a variable length payload (payload length is available
in the header). When software request the data at an offset in memory
the OTPC will return (via header + data registers) the whole packet that
has a word at that offset. For the OTP memory layout like below:

offset OTP Memory layout

. .
. ... .
. .
0x0E +-----------+ <--- packet X
| header X |
0x12 +-----------+
| payload X |
0x16 | |
| |
0x1A | |
+-----------+
. .
. ... .
. .

if user requests data at address 0x16 the data started at 0x0E will be
returned by controller. User will be able to fetch the whole packet
starting at 0x0E (or parts of the packet) via proper registers. The same
packet will be returned if software request the data at offset 0x0E or
0x12 or 0x1A.

The OTP will be populated by Microchip with at least 2 packets first one
being boot configuration packet and the 2nd one being temperature
calibration packet. The packet order will be preserved b/w different chip
revisions but the packet sizes may change.

For the above reasons and to keep the same software able to work on all
chip variants the read function of the driver is working with a packet
id instead of an offset in OTP memory.

Signed-off-by: Claudiu Beznea <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: sfp: Use regmap

This converts the SFP driver to use regmap. This will allow easily
supporting devices with different endians. We disallow byte-level
access, as regmap_bulk_read doesn't suppor

nvmem: sfp: Use regmap

This converts the SFP driver to use regmap. This will allow easily
supporting devices with different endians. We disallow byte-level
access, as regmap_bulk_read doesn't support it (and it's unclear what
the correct result would be when we have an endianness difference).

Signed-off-by: Sean Anderson <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: Add Apple eFuse driver

Apple SoCs contain eFuses used to store factory-programmed data such
as calibration values for the PCIe or the Type-C PHY. They are organized
as 32bit values exposed as

nvmem: Add Apple eFuse driver

Apple SoCs contain eFuses used to store factory-programmed data such
as calibration values for the PCIe or the Type-C PHY. They are organized
as 32bit values exposed as MMIO.

Signed-off-by: Sven Peter <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: Add driver for OCOTP in Sunplus SP7021

Add driver for OCOTP in Sunplus SP7021

Signed-off-by: Vincent Shih <[email protected]>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@

nvmem: Add driver for OCOTP in Sunplus SP7021

Add driver for OCOTP in Sunplus SP7021

Signed-off-by: Vincent Shih <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: add driver for Layerscape SFP (Security Fuse Processor)

Add support for the Security Fuse Processor found on Layerscape SoCs.
This driver implements basic read access.

Signed-off-by: Michael

nvmem: add driver for Layerscape SFP (Security Fuse Processor)

Add support for the Security Fuse Processor found on Layerscape SoCs.
This driver implements basic read access.

Signed-off-by: Michael Walle <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: NVMEM_NINTENDO_OTP should depend on WII

The Nintendo Wii and Wii U OTP is only present on Nintendo Wii and Wii U
consoles. Hence add a dependency on WII, to prevent asking the user
about thi

nvmem: NVMEM_NINTENDO_OTP should depend on WII

The Nintendo Wii and Wii U OTP is only present on Nintendo Wii and Wii U
consoles. Hence add a dependency on WII, to prevent asking the user
about this driver when configuring a kernel without Nintendo Wii and Wii
U console support.

Fixes: 3683b761fe3a10ad ("nvmem: nintendo-otp: Add new driver for the Wii and Wii U OTP")
Reviewed-by: Emmanuel Gil Peyrot <[email protected]>
Signed-off-by: Geert Uytterhoeven <[email protected]>
Link: https://lore.kernel.org/r/01318920709dddc4d85fe895e2083ca0eee234d8.1631611652.git.geert+renesas@glider.be
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...

nvmem: nintendo-otp: Add new driver for the Wii and Wii U OTP

This OTP is read-only and contains various keys used by the console to
decrypt, encrypt or verify various pieces of storage.

Its size d

nvmem: nintendo-otp: Add new driver for the Wii and Wii U OTP

This OTP is read-only and contains various keys used by the console to
decrypt, encrypt or verify various pieces of storage.

Its size depends on the console, it is 128 bytes on the Wii and
1024 bytes on the Wii U (split into eight 128 bytes banks).

It can be used directly by writing into one register and reading from
the other one, without any additional synchronisation.

This driver was written based on reversed documentation, see:
https://wiiubrew.org/wiki/Hardware/OTP

Tested-by: Jonathan Neuschäfer <[email protected]> # on Wii
Tested-by: Emmanuel Gil Peyrot <[email protected]> # on Wii U
Signed-off-by: Emmanuel Gil Peyrot <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...