<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux-toradex.git/drivers/nvmem/sec-qfprom.c, branch v7.0-rc2</title>
<subtitle>Linux kernel for Apalis and Colibri modules</subtitle>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/'/>
<entry>
<title>nvmem: add explicit config option to read old syntax fixed OF cells</title>
<updated>2023-10-21T17:19:06+00:00</updated>
<author>
<name>Rafał Miłecki</name>
<email>rafal@milecki.pl</email>
</author>
<published>2023-10-20T10:55:41+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=2cc3b37f5b6df8189d55d0e812d9658ce256dfec'/>
<id>2cc3b37f5b6df8189d55d0e812d9658ce256dfec</id>
<content type='text'>
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 &amp; use it (we can't break backward compatibility!). That way we
additionally encourage new bindings &amp; 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 &lt;rafal@milecki.pl&gt;
[for meson-{efuse,mx-efuse}.c]
Acked-by: Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;
[for mtk-efuse.c, nvmem/core.c, nvmem-provider.h]
Reviewed-by: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@collabora.com&gt;
[MT8192, MT8195 Chromebooks]
Tested-by: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@collabora.com&gt;
[for microchip-otpc.c]
Reviewed-by: Claudiu Beznea &lt;claudiu.beznea@microchip.com&gt;
[SAMA7G5-EK]
Tested-by: Claudiu Beznea &lt;claudiu.beznea@microchip.com&gt;
Acked-by: Jernej Skrabec &lt;jernej.skrabec@gmail.com&gt;
Signed-off-by: Srinivas Kandagatla &lt;srinivas.kandagatla@linaro.org&gt;
Link: https://lore.kernel.org/r/20231020105545.216052-3-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &amp; use it (we can't break backward compatibility!). That way we
additionally encourage new bindings &amp; 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 &lt;rafal@milecki.pl&gt;
[for meson-{efuse,mx-efuse}.c]
Acked-by: Martin Blumenstingl &lt;martin.blumenstingl@googlemail.com&gt;
[for mtk-efuse.c, nvmem/core.c, nvmem-provider.h]
Reviewed-by: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@collabora.com&gt;
[MT8192, MT8195 Chromebooks]
Tested-by: AngeloGioacchino Del Regno &lt;angelogioacchino.delregno@collabora.com&gt;
[for microchip-otpc.c]
Reviewed-by: Claudiu Beznea &lt;claudiu.beznea@microchip.com&gt;
[SAMA7G5-EK]
Tested-by: Claudiu Beznea &lt;claudiu.beznea@microchip.com&gt;
Acked-by: Jernej Skrabec &lt;jernej.skrabec@gmail.com&gt;
Signed-off-by: Srinivas Kandagatla &lt;srinivas.kandagatla@linaro.org&gt;
Link: https://lore.kernel.org/r/20231020105545.216052-3-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
<entry>
<title>nvmem: sec-qfprom: Add Qualcomm secure QFPROM support</title>
<updated>2023-08-23T14:34:01+00:00</updated>
<author>
<name>Komal Bajaj</name>
<email>quic_kbajaj@quicinc.com</email>
</author>
<published>2023-08-23T13:27:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.toradex.cn/cgit/linux-toradex.git/commit/?id=c471245bd9f25152e398fb49f65cf6e1ed7febbd'/>
<id>c471245bd9f25152e398fb49f65cf6e1ed7febbd</id>
<content type='text'>
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 &lt;quic_kbajaj@quicinc.com&gt;
Signed-off-by: Srinivas Kandagatla &lt;srinivas.kandagatla@linaro.org&gt;
Link: https://lore.kernel.org/r/20230823132744.350618-18-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</content>
<content type='xhtml'>
<div xmlns='http://www.w3.org/1999/xhtml'>
<pre>
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 &lt;quic_kbajaj@quicinc.com&gt;
Signed-off-by: Srinivas Kandagatla &lt;srinivas.kandagatla@linaro.org&gt;
Link: https://lore.kernel.org/r/20230823132744.350618-18-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;
</pre>
</div>
</content>
</entry>
</feed>
