History log of /linux-6.15/drivers/nvmem/Makefile (Results 1 – 25 of 46)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.15, v6.15-rc7, v6.15-rc6, v6.15-rc5, v6.15-rc4, v6.15-rc3, v6.15-rc2, v6.15-rc1, v6.14, v6.14-rc7, v6.14-rc6, v6.14-rc5, v6.14-rc4, v6.14-rc3, v6.14-rc2, v6.14-rc1, v6.13, v6.13-rc7, v6.13-rc6, v6.13-rc5, v6.13-rc4, v6.13-rc3, v6.13-rc2, v6.13-rc1, v6.12, v6.12-rc7, v6.12-rc6
# 1530b923 30-Oct-2024 Geert Uytterhoeven <[email protected]>

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 ...


Revision tags: v6.12-rc5, v6.12-rc4, v6.12-rc3, v6.12-rc2, v6.12-rc1, v6.11, v6.11-rc7, v6.11-rc6, v6.11-rc5, v6.11-rc4, v6.11-rc3, v6.11-rc2, v6.11-rc1, v6.10, v6.10-rc7, v6.10-rc6, v6.10-rc5, v6.10-rc4, v6.10-rc3, v6.10-rc2, v6.10-rc1, v6.9, v6.9-rc7, v6.9-rc6, v6.9-rc5, v6.9-rc4, v6.9-rc3, v6.9-rc2, v6.9-rc1, v6.8, v6.8-rc7, v6.8-rc6, v6.8-rc5, v6.8-rc4, v6.8-rc3, v6.8-rc2, v6.8-rc1, v6.7, v6.7-rc8, v6.7-rc7, v6.7-rc6
# fc29fd82 15-Dec-2023 Miquel Raynal <[email protected]>

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 ...


Revision tags: v6.7-rc5, v6.7-rc4, v6.7-rc3, v6.7-rc2, v6.7-rc1, v6.6, v6.6-rc7, v6.6-rc6, v6.6-rc5, v6.6-rc4, v6.6-rc3, v6.6-rc2, v6.6-rc1, v6.5
# c471245b 23-Aug-2023 Komal Bajaj <[email protected]>

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 ...


# 0861110b 23-Aug-2023 Richard Alpe <[email protected]>

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 ...


Revision tags: v6.5-rc7, v6.5-rc6, v6.5-rc5, v6.5-rc4, v6.5-rc3, v6.5-rc2, v6.5-rc1, v6.4, v6.4-rc7, v6.4-rc6
# 22e9e6fc 11-Jun-2023 Peng Fan <[email protected]>

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 ...


Revision tags: v6.4-rc5, v6.4-rc4, v6.4-rc3, v6.4-rc2, v6.4-rc1, v6.3, v6.3-rc7, v6.3-rc6
# 266570f4 04-Apr-2023 Michael Walle <[email protected]>

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 ...


Revision tags: v6.3-rc5, v6.3-rc4, v6.3-rc3, v6.3-rc2, v6.3-rc1, v6.2, v6.2-rc8
# 6a0bc352 06-Feb-2023 Patrick Delaunay <[email protected]>

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 ...


Revision tags: v6.2-rc7, v6.2-rc6, v6.2-rc5, v6.2-rc4, v6.2-rc3, v6.2-rc2, v6.2-rc1, v6.1, v6.1-rc8, v6.1-rc7, v6.1-rc6, v6.1-rc5, v6.1-rc4, v6.1-rc3, v6.1-rc2, v6.1-rc1, v6.0, v6.0-rc7, v6.0-rc6
# 9e8f208a 16-Sep-2022 Horatiu Vultur <[email protected]>

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 ...


# a06d9e5a 16-Sep-2022 Rafał Miłecki <[email protected]>

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 ...


# 28fc7c98 16-Sep-2022 Rafał Miłecki <[email protected]>

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 ...


# d5542923 16-Sep-2022 Rafał Miłecki <[email protected]>

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 ...


Revision tags: v6.0-rc5, v6.0-rc4, v6.0-rc3, v6.0-rc2, v6.0-rc1, v5.19, v5.19-rc8, v5.19-rc7, v5.19-rc6
# 98830350 06-Jul-2022 Claudiu Beznea <[email protected]>

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 ...


Revision tags: v5.19-rc5, v5.19-rc4, v5.19-rc3, v5.19-rc2, v5.19-rc1, v5.18, v5.18-rc7, v5.18-rc6, v5.18-rc5
# b6b7ef93 29-Apr-2022 Sven Peter <[email protected]>

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 ...


Revision tags: v5.18-rc4, v5.18-rc3, v5.18-rc2, v5.18-rc1, v5.17, v5.17-rc8, v5.17-rc7, v5.17-rc6
# 8747ec2e 23-Feb-2022 Vincent Shih <[email protected]>

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 ...


Revision tags: v5.17-rc5
# f7845101 20-Feb-2022 Michael Walle <[email protected]>

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 ...


Revision tags: v5.17-rc4, v5.17-rc3, v5.17-rc2, v5.17-rc1, v5.16, v5.16-rc8, v5.16-rc7, v5.16-rc6, v5.16-rc5, v5.16-rc4, v5.16-rc3, v5.16-rc2, v5.16-rc1, v5.15, v5.15-rc7, v5.15-rc6, v5.15-rc5, v5.15-rc4, v5.15-rc3, v5.15-rc2, v5.15-rc1, v5.14, v5.14-rc7, v5.14-rc6
# 3683b761 10-Aug-2021 Emmanuel Gil Peyrot <[email protected]>

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 ...


Revision tags: v5.14-rc5, v5.14-rc4, v5.14-rc3, v5.14-rc2, v5.14-rc1, v5.13, v5.13-rc7, v5.13-rc6, v5.13-rc5, v5.13-rc4, v5.13-rc3, v5.13-rc2, v5.13-rc1, v5.12, v5.12-rc8, v5.12-rc7, v5.12-rc6
# 3fef9ed0 30-Mar-2021 Rafał Miłecki <[email protected]>

nvmem: brcm_nvram: new driver exposing Broadcom's NVRAM

This driver provides access to Broadcom's NVRAM.

Signed-off-by: Rafał Miłecki <[email protected]>
Signed-off-by: Srinivas Kandagatla <srinivas

nvmem: brcm_nvram: new driver exposing Broadcom's NVRAM

This driver provides access to Broadcom's NVRAM.

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 ...


Revision tags: v5.12-rc5, v5.12-rc4, v5.12-rc3, v5.12-rc2, v5.12-rc1, v5.12-rc1-dontuse, v5.11, v5.11-rc7, v5.11-rc6
# 5a3fa75a 29-Jan-2021 Nicolas Saenz Julienne <[email protected]>

nvmem: Add driver to expose reserved memory as nvmem

Firmware/co-processors might use reserved memory areas in order to pass
data stemming from an nvmem device otherwise non accessible to Linux.
For

nvmem: Add driver to expose reserved memory as nvmem

Firmware/co-processors might use reserved memory areas in order to pass
data stemming from an nvmem device otherwise non accessible to Linux.
For example an EEPROM memory only physically accessible to firmware, or
data only accessible early at boot time.

In order to expose this data to other drivers and user-space, the driver
models the reserved memory area as an nvmem device.

Tested-by: Tim Gover <[email protected]>
Reviewed-by: Rob Herring <[email protected]>
Signed-off-by: Nicolas Saenz Julienne <[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 ...


Revision tags: v5.11-rc5, v5.11-rc4, v5.11-rc3, v5.11-rc2, v5.11-rc1, v5.10, v5.10-rc7, v5.10-rc6, v5.10-rc5, v5.10-rc4, v5.10-rc3, v5.10-rc2, v5.10-rc1, v5.9, v5.9-rc8, v5.9-rc7, v5.9-rc6, v5.9-rc5, v5.9-rc4, v5.9-rc3, v5.9-rc2, v5.9-rc1, v5.8, v5.8-rc7, v5.8-rc6, v5.8-rc5, v5.8-rc4, v5.8-rc3, v5.8-rc2, v5.8-rc1, v5.7, v5.7-rc7, v5.7-rc6, v5.7-rc5, v5.7-rc4, v5.7-rc3, v5.7-rc2, v5.7-rc1, v5.6
# 84400305 25-Mar-2020 Srinivas Kandagatla <[email protected]>

nvmem: core: remove nvmem_sysfs_get_groups()

Now that we are using is_bin_visible callback, we do not need
nvmem_sysfs_get_groups() anymore so move all the relevant data-structures
and code to core.

nvmem: core: remove nvmem_sysfs_get_groups()

Now that we are using is_bin_visible callback, we do not need
nvmem_sysfs_get_groups() anymore so move all the relevant data-structures
and code to core.c

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 ...


Revision tags: v5.6-rc7, v5.6-rc6
# 4a2addc2 10-Mar-2020 PrasannaKumar Muralidharan <[email protected]>

nvmem: add driver for JZ4780 efuse

This patch brings support for the JZ4780 efuse. Currently it only exposes
a read only access to the entire 8K bits efuse memory and nvmem cells.

To fetch for exam

nvmem: add driver for JZ4780 efuse

This patch brings support for the JZ4780 efuse. Currently it only exposes
a read only access to the entire 8K bits efuse memory and nvmem cells.

To fetch for example the MAC address:

dd if=/sys/devices/platform/134100d0.efuse/jz4780-efuse0/nvmem bs=1 skip=34 count=6 status=none | xxd

Tested-by: Mathieu Malaterre <[email protected]>
Signed-off-by: PrasannaKumar Muralidharan <[email protected]>
Signed-off-by: Mathieu Malaterre <[email protected]>
Signed-off-by: H. Nikolaus Schaller <[email protected]>
Signed-off-by: Paul Cercueil <[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 ...


Revision tags: v5.6-rc5, v5.6-rc4, v5.6-rc3, v5.6-rc2, v5.6-rc1, v5.5, v5.5-rc7
# 40ce9798 16-Jan-2020 Anirudh Ghayal <[email protected]>

nvmem: add QTI SDAM driver

QTI SDAM driver allows PMIC peripherals to access the shared memory
that is available on QTI PMICs.

Use subsys_initcall as PMIC SDAM NV memory is accessed by multiple PMI

nvmem: add QTI SDAM driver

QTI SDAM driver allows PMIC peripherals to access the shared memory
that is available on QTI PMICs.

Use subsys_initcall as PMIC SDAM NV memory is accessed by multiple PMIC
drivers (charger, fuel gauge) to store/restore data across reboots
required during their initialization.

Signed-off-by: Anirudh Ghayal <[email protected]>
Signed-off-by: Shyam Kumar Thella <[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 ...


Revision tags: v5.5-rc6, v5.5-rc5, v5.5-rc4, v5.5-rc3, v5.5-rc2, v5.5-rc1, v5.4, v5.4-rc8, v5.4-rc7, v5.4-rc6
# 755864fe 29-Oct-2019 Finley Xiao <[email protected]>

nvmem: add Rockchip OTP driver

Newer Rockchip socs like the px30 use a different one-time-programmable
memory controller for things like cpu-id and leakage information,
so add the necessary driver f

nvmem: add Rockchip OTP driver

Newer Rockchip socs like the px30 use a different one-time-programmable
memory controller for things like cpu-id and leakage information,
so add the necessary driver for it.

Signed-off-by: Finley Xiao <[email protected]>
[ported from vendor 4.4, converted to clock-bulk API and cleanups]
Signed-off-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 ...


# 096030e7 29-Oct-2019 Freeman Liu <[email protected]>

nvmem: sprd: Add Spreadtrum SoCs eFuse support

The Spreadtrum eFuse controller is widely used to dump chip ID,
configuration setting, function select and so on, as well as
supporting one-time progra

nvmem: sprd: Add Spreadtrum SoCs eFuse support

The Spreadtrum eFuse controller is widely used to dump chip ID,
configuration setting, function select and so on, as well as
supporting one-time programming.

Signed-off-by: Freeman Liu <[email protected]>
Signed-off-by: Baolin Wang <[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 ...


Revision tags: v5.4-rc5, v5.4-rc4, v5.4-rc3, v5.4-rc2, v5.4-rc1, v5.3, v5.3-rc8, v5.3-rc7, v5.3-rc6, v5.3-rc5, v5.3-rc4, v5.3-rc3, v5.3-rc2, v5.3-rc1, v5.2, v5.2-rc7, v5.2-rc6, v5.2-rc5
# 67ff708b 14-Jun-2019 Peng Fan <[email protected]>

nvmem: imx: add i.MX8 nvmem driver

This patch adds i.MX8 nvmem ocotp driver to access fuse via
RPC to i.MX8 system controller.

Cc: Srinivas Kandagatla <[email protected]>
Cc: Shawn Guo

nvmem: imx: add i.MX8 nvmem driver

This patch adds i.MX8 nvmem ocotp driver to access fuse via
RPC to i.MX8 system controller.

Cc: Srinivas Kandagatla <[email protected]>
Cc: Shawn Guo <[email protected]>
Cc: Sascha Hauer <[email protected]>
Cc: Pengutronix Kernel Team <[email protected]>
Cc: Fabio Estevam <[email protected]>
Cc: NXP Linux Team <[email protected]>
Cc: [email protected]
Signed-off-by: Peng Fan <[email protected]>
Reviewed-by: Dong Aisheng <[email protected]>
Signed-off-by: Srinivas Kandagatla <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...


Revision tags: v5.2-rc4, v5.2-rc3, v5.2-rc2, v5.2-rc1, v5.1, v5.1-rc7, v5.1-rc6
# ae0c2d72 16-Apr-2019 Srinivas Kandagatla <[email protected]>

nvmem: core: add NVMEM_SYSFS Kconfig

Many nvmem providers are not very keen on having default sysfs
nvmem entry, as most of the usecases for them are inside kernel
itself. And in some cases read/wri

nvmem: core: add NVMEM_SYSFS Kconfig

Many nvmem providers are not very keen on having default sysfs
nvmem entry, as most of the usecases for them are inside kernel
itself. And in some cases read/writes to some areas in nvmem are
restricted and trapped at secure monitor level, so accessing them
from userspace would result in board reboots.

This patch adds new NVMEM_SYSFS Kconfig to make binary sysfs entry
an optional one. This provision will give more flexibility to users.
This patch also moves existing sysfs code to a new file so that its
not compiled in when its not really required.

Signed-off-by: Srinivas Kandagatla <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Reviewed-by: Gaurav Kohli <[email protected]>
Tested-by: Gaurav Kohli <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>

show more ...


12