kernel/linux.git/drivers/nvmem/Kconfig, branch v6.12.80

nvmem: layouts: add U-Boot env layout

2024-09-11T14:05:15+00:00

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

nvmem: core: Rework layouts to become regular devices

2023-12-15T12:30:07+00:00

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

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: Kconfig: Fix typo "drive" -> "driver"

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

Fix typo where "driver" was meant instead of "drive". While at it, also capitalize "OTP". Signed-off-by: Diederik de Haas Reviewed-by: Heiko Stuebner Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20230823132744.350618-15-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: brcm_nvram: add .read_post_process() for MACs

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

1. Parse ASCII MAC format into byte based 2. Calculate relative addresses based on index argument Signed-off-by: Rafał Miłecki Signed-off-by: Srinivas Kandagatla Message-ID: <20230611140330.154222-5-srinivas.kandagatla@linaro.org> Signed-off-by: Greg Kroah-Hartman

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

2023-04-05T17:41:13+00:00

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 Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20230404172148.82422-36-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: xilinx: zynqmp: make modular

2023-04-05T17:41:10+00:00

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 Suggested-by: Michal Simek Cc: Luis Chamberlain Cc: linux-modules@vger.kernel.org Cc: linux-kernel@vger.kernel.org Cc: Hitomi Hasegawa Cc: Srinivas Kandagatla Cc: Michal Simek Cc: linux-arm-kernel@lists.infradead.org Signed-off-by: Srinivas Kandagatla Link: https://lore.kernel.org/r/20230404172148.82422-4-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman