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