Subject: Re: [PATCH v5 2/2] nvmem: imx-ocotp-ele: Support accessing
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

(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?

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?

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 in NXP downstream android kernel.

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

Thanks,
Peng.

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
https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2F
www.tq-
group.com%2F&data=05%7C02%7Cpeng.fan%40nxp.com%7C4f423e5
af548475e6b0208dd33cc2d1e%7C686ea1d3bc2b4c6fa92cd99c5c301
635%7C0%7C0%7C638723674209718864%7CUnknown%7CTWFpbGZ
sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW
4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=e
qPs5lOuVSiIZYQwwNecUzgIL%2FtWiJP5bjd7b60Ul7A%3D&reserved=0