Thread (12 messages) 12 messages, 3 authors, 2025-01-16

Re: [PATCH v5 2/2] nvmem: imx-ocotp-ele: Support accessing controller for i.MX9

From: Alexander Stein <hidden>
Date: 2025-01-13 12:16:55
Also in: imx, linux-devicetree, lkml

Hi,

Am Samstag, 11. Januar 2025, 13:41:58 CET schrieb Peng Fan:
quoted
Subject: Re: [PATCH v5 2/2] nvmem: imx-ocotp-ele: Support accessing
controller for i.MX9

Hi,

Am Donnerstag, 9. Januar 2025, 04:34:18 CET schrieb Peng Fan:
quoted
On Wed, Jan 08, 2025 at 11:15:40AM +0100, Alexander Stein wrote:
quoted
Hi Peng,

Am Mittwoch, 8. Januar 2025, 08:00:18 CET schrieb Peng Fan (OSS):
quoted
From: Peng Fan <peng.fan@nxp.com>

i.MX9 OCOTP supports a specific peripheral or function being
fused
quoted
quoted
quoted
which means disabled, so
 - Introduce ocotp_access_gates to be container of efuse gate info
 - Iterate all nodes to check accessing permission. If not
   allowed to be accessed, detach the node

Signed-off-by: Peng Fan <peng.fan@nxp.com>
---
 drivers/nvmem/imx-ocotp-ele.c | 172
+++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 171 insertions(+), 1 deletion(-)
[....]
quoted
quoted
+
+	return imx_ele_ocotp_access_control(priv);
In [1] you mentioned devlink should solve the probe order. How
does
quoted
quoted
this play when the driver is compiled in (e.g. ethernet for NFS boot)
but this OCOTP driver is just a module?
OCOTP needs to built in for using devlink. Or the users needs to be
built as module.
I don't like this kind of assumption. Would it make more sense to make
CONFIG_NVMEM_IMX_OCOTP_ELE as bool instead of tristate?
No. Users could setup their own system with this driver build in
or built related drivers as modules.
Sure, but if the kernel locks/fails/panics while accessing peripherals
just because of the kernel config seems at east very unfortunate to me.
How is someone supposed to analyze/debug this?
At least for Android GKI, this driver needs to be as module.
Any particular reason this needs to be a module?
Which means any affected driver needs to be a module as well just because if
a DT reference, no? With no means to know which drivers are affected, despite
checking for the DT references manually?

Best regards,
Alexander
-- 
TQ-Systems GmbH | Mühlstraße 2, Gut Delling | 82229 Seefeld, Germany
Amtsgericht München, HRB 105018
Geschäftsführer: Detlef Schneider, Rüdiger Stahl, Stefan Schneider
http://www.tq-group.com/


Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help