kernel/linux.git/drivers/nvmem/Makefile, branch v6.6.132

nvmem: sec-qfprom: Add Qualcomm secure QFPROM support

2023-08-23T14:34:01+00:00

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

nvmem: add new NXP QorIQ eFuse driver

2023-08-23T14:34:01+00:00

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 Reviewed-by: Niklas Söderlund Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20230823132744.350618-13-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman

nvmem: imx: support i.MX93 OCOTP

2023-06-15T11:42:17+00:00

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 Signed-off-by: Srinivas Kandagatla Message-ID: <20230611140330.154222-22-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: stm32: add OP-TEE support for STM32MP13x

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

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 Reviewed-by: Etienne Carriere Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20230206134356.839737-18-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman

nvmem: lan9662-otp: add support

2022-09-24T12:54:38+00:00

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

nvmem: sort config symbols alphabetically

2022-09-24T12:54:38+00:00

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

nvmem: prefix all symbols with NVMEM_

2022-09-24T12:54:38+00:00

This unifies all NVMEM symbols. They follow one style now. Reviewed-by: Matthias Brugger Acked-by: Arnd Bergmann Signed-off-by: Rafał Miłecki Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220916122100.170016-8-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman

nvmem: add driver handling U-Boot environment variables

2022-09-24T12:54:37+00:00

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 Signed-off-by: Rafał Miłecki Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20220916122100.170016-2-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman

nvmem: microchip-otpc: add support

2022-07-08T13:45:05+00:00

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