linux-arm.git - Russell King's ARM Linux kernel tree

Age	Commit message (Collapse)	Author
2023-10-21	nvmem: add explicit config option to read old syntax fixed OF cells	Rafał Miłecki
	Binding for fixed NVMEM cells defined directly as NVMEM device subnodes has been deprecated. It has been replaced by the "fixed-layout" NVMEM layout binding. New syntax is meant to be clearer and should help avoiding imprecise bindings. NVMEM subsystem already supports the new binding. It should be a good idea to limit support for old syntax to existing drivers that actually support & use it (we can't break backward compatibility!). That way we additionally encourage new bindings & drivers to ignore deprecated binding. It wasn't clear (to me) if rtc and w1 code actually uses old syntax fixed cells. I enabled them to don't risk any breakage. Signed-off-by: Rafał Miłecki <rafal@milecki.pl> [for meson-{efuse,mx-efuse}.c] Acked-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com> [for mtk-efuse.c, nvmem/core.c, nvmem-provider.h] Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> [MT8192, MT8195 Chromebooks] Tested-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> [for microchip-otpc.c] Reviewed-by: Claudiu Beznea <claudiu.beznea@microchip.com> [SAMA7G5-EK] Tested-by: Claudiu Beznea <claudiu.beznea@microchip.com> Acked-by: Jernej Skrabec <jernej.skrabec@gmail.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20231020105545.216052-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2022-07-08	nvmem: microchip-otpc: add support	Claudiu Beznea
	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 <claudiu.beznea@microchip.com> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org> Link: https://lore.kernel.org/r/20220706100627.6534-3-srinivas.kandagatla@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>