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

Hi,

Am Donnerstag, 16. Januar 2025, 03:09:02 CET schrieb Peng Fan:

quoted

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

Hi,

Am Dienstag, 14. Januar 2025, 09:35:41 CET schrieb Peng Fan:

quoted

quoted

Subject: Re: [PATCH v5 2/2] nvmem: imx-ocotp-ele: Support

accessing

quoted

quoted

controller for i.MX9

Hi,

Am Samstag, 11. Januar 2025, 13:41:58 CET schrieb Peng Fan:

quoted

quoted

Subject: Re: [PATCH v5 2/2] nvmem: imx-ocotp-ele: Support

accessing

quoted

quoted

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

quoted

quoted

quoted

Hi Peng,

Am Mittwoch, 8. Januar 2025, 08:00:18 CET schrieb Peng

Fan

quoted

quoted

(OSS):

quoted

quoted

quoted

quoted

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?

quoted

quoted

quoted

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.

quoted

quoted

How is someone supposed to analyze/debug this?

quoted

At least for Android GKI, this driver needs to be as module.

Any particular reason this needs to be a module?

Android has a minimal kernel which is controlled by Google.
Vendors could only built modules based on Google's Image.

Updating this to y in upstream, means we need to change it back to

m

quoted

in NXP downstream android kernel.

Ok, that's an Android thing.

quoted

If you need it built in, you could modify your downstream config,
right?

I'm not saying I need a built-in. My concern is that a wrong Kconfig will
result in silent errors/lockups.

You wanna me to put this default y in arm64 defconfig in
upstream kernel?

If yes, this could be separate patch to Shawn if this patchset got
merged by Srinivas.

I don't know what others says about adjusting defconfig. But at least
add a comment to the Kconfig help that if built as modules, any
other driver relying on this also needs to be a module as well.

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/