| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-ID:
<DB9PR04MB84615C152538FD411F462B19881D2@DB9PR04MB8461.eurprd04.prod.outlook.com>
Date: Sat, 11 Jan 2025 12:41:58 +0000
From: Peng Fan <peng.fan@....com>
To: Alexander Stein <alexander.stein@...tq-group.com>, "Peng Fan (OSS)"
<peng.fan@....nxp.com>
CC: Srinivas Kandagatla <srinivas.kandagatla@...aro.org>, Rob Herring
<robh@...nel.org>, Krzysztof Kozlowski <krzk+dt@...nel.org>, Conor Dooley
<conor+dt@...nel.org>, Shawn Guo <shawnguo@...nel.org>, Sascha Hauer
<s.hauer@...gutronix.de>, Pengutronix Kernel Team <kernel@...gutronix.de>,
Fabio Estevam <festevam@...il.com>, "linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>, "devicetree@...r.kernel.org"
<devicetree@...r.kernel.org>, "imx@...ts.linux.dev" <imx@...ts.linux.dev>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v5 2/2] nvmem: imx-ocotp-ele: Support accessing controller
for i.MX9
> 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:
> > On Wed, Jan 08, 2025 at 11:15:40AM +0100, Alexander Stein wrote:
> > >Hi Peng,
> > >
> > >Am Mittwoch, 8. Januar 2025, 08:00:18 CET schrieb Peng Fan (OSS):
> > >> From: Peng Fan <peng.fan@....com>
> > >>
> > >> i.MX9 OCOTP supports a specific peripheral or function being
> fused
> > >> 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@....com>
> > >> ---
> > >> drivers/nvmem/imx-ocotp-ele.c | 172
> > >> +++++++++++++++++++++++++++++++++++++++++-
> > >> 1 file changed, 171 insertions(+), 1 deletion(-)
> > >>
> > [....]
> > >> +
> > >> + return imx_ele_ocotp_access_control(priv);
> > >
> > >In [1] you mentioned devlink should solve the probe order. How
> does
> > >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.
At least for Android GKI, this driver needs to be as module.
Thanks,
Peng.
>
> > >I'm not well versed with devlink, but is
> > >> access-controllers = <&ocotp IMX93_OCOTP_ENET1_GATE>;
> > >already enough to create that link?
> >
> > Yes, the drivers/of/property.c has this
> > "DEFINE_SIMPLE_PROP(access_controllers, "access-controllers",
> "#access-controller-cells")"
> >
> > The fw_devlink driver will create consumer/supplier to make sure
> > proper order.
>
> Okay, thanks for confirming.
>
> Best regards,
> Alexander
>
> > Regards,
> > Peng
> >
> > >
> > >Best regards,
> > >Alexander
> > >
> > >> }
> > >>
> > >> +struct access_gate imx93_access_gate[] = {
> > >> + [IMX93_OCOTP_NPU_GATE] = { .word =
> 19, .mask = BIT(13) },
> > >> + [IMX93_OCOTP_A550_GATE] = { .word =
> 19, .mask = BIT(14) },
> > >> + [IMX93_OCOTP_A551_GATE] = { .word =
> 19, .mask = BIT(15) },
> > >> + [IMX93_OCOTP_M33_GATE] = { .word =
> 19, .mask = BIT(24) },
> > >> + [IMX93_OCOTP_CAN1_FD_GATE] = { .word =
> 19, .mask = BIT(28) },
> > >> + [IMX93_OCOTP_CAN2_FD_GATE] = { .word =
> 19, .mask = BIT(29) },
> > >> + [IMX93_OCOTP_CAN1_GATE] = { .word =
> 19, .mask = BIT(30) },
> > >> + [IMX93_OCOTP_CAN2_GATE] = { .word =
> 19, .mask = BIT(31) },
> > >> + [IMX93_OCOTP_USB1_GATE] = { .word =
> 20, .mask = BIT(3) },
> > >> + [IMX93_OCOTP_USB2_GATE] = { .word =
> 20, .mask = BIT(4) },
> > >> + [IMX93_OCOTP_ENET1_GATE] = { .word =
> 20, .mask = BIT(5) },
> > >> + [IMX93_OCOTP_ENET2_GATE] = { .word =
> 20, .mask = BIT(6) },
> > >> + [IMX93_OCOTP_PXP_GATE] = { .word =
> 20, .mask = BIT(10) },
> > >> + [IMX93_OCOTP_MIPI_CSI1_GATE] = { .word =
> 20, .mask = BIT(17) },
> > >> + [IMX93_OCOTP_MIPI_DSI1_GATE] = { .word =
> 20, .mask = BIT(19) },
> > >> + [IMX93_OCOTP_LVDS1_GATE] = { .word =
> 20, .mask = BIT(24) },
> > >> + [IMX93_OCOTP_ADC1_GATE] = { .word =
> 21, .mask = BIT(7) },
> > >> +};
> > >> +
> > >> +static const struct ocotp_access_gates imx93_access_gates_info =
> {
> > >> + .num_words = 3,
> > >> + .words = {19, 20, 21},
> > >> + .num_gates = ARRAY_SIZE(imx93_access_gate),
> > >> + .gates = imx93_access_gate,
> > >> +};
> > >> +
> > >> static const struct ocotp_devtype_data imx93_ocotp_data = {
> > >> + .access_gates = &imx93_access_gates_info,
> > >> .reg_off = 0x8000,
> > >> .reg_read = imx_ocotp_reg_read,
> > >> .size = 2048,
> > >> @@ -183,7 +307,53 @@ static const struct ocotp_devtype_data
> imx93_ocotp_data = {
> > >> },
> > >> };
> > >>
> > >> +struct access_gate imx95_access_gate[] = {
> > >> + [IMX95_OCOTP_CANFD1_GATE] = { .word =
> 17, .mask = BIT(20) },
> > >> + [IMX95_OCOTP_CANFD2_GATE] = { .word =
> 17, .mask = BIT(21) },
> > >> + [IMX95_OCOTP_CANFD3_GATE] = { .word =
> 17, .mask = BIT(22) },
> > >> + [IMX95_OCOTP_CANFD4_GATE] = { .word =
> 17, .mask = BIT(23) },
> > >> + [IMX95_OCOTP_CANFD5_GATE] = { .word =
> 17, .mask = BIT(24) },
> > >> + [IMX95_OCOTP_CAN1_GATE] = { .word =
> 17, .mask = BIT(25) },
> > >> + [IMX95_OCOTP_CAN2_GATE] = { .word =
> 17, .mask = BIT(26) },
> > >> + [IMX95_OCOTP_CAN3_GATE] = { .word =
> 17, .mask = BIT(27) },
> > >> + [IMX95_OCOTP_CAN4_GATE] = { .word =
> 17, .mask = BIT(28) },
> > >> + [IMX95_OCOTP_CAN5_GATE] = { .word =
> 17, .mask = BIT(29) },
> > >> + [IMX95_OCOTP_NPU_GATE] = { .word =
> 18, .mask = BIT(0) },
> > >> + [IMX95_OCOTP_A550_GATE] = { .word =
> 18, .mask = BIT(1) },
> > >> + [IMX95_OCOTP_A551_GATE] = { .word =
> 18, .mask = BIT(2) },
> > >> + [IMX95_OCOTP_A552_GATE] = { .word =
> 18, .mask = BIT(3) },
> > >> + [IMX95_OCOTP_A553_GATE] = { .word =
> 18, .mask = BIT(4) },
> > >> + [IMX95_OCOTP_A554_GATE] = { .word =
> 18, .mask = BIT(5) },
> > >> + [IMX95_OCOTP_A555_GATE] = { .word =
> 18, .mask = BIT(6) },
> > >> + [IMX95_OCOTP_M7_GATE] = { .word =
> 18, .mask = BIT(9) },
> > >> + [IMX95_OCOTP_DCSS_GATE] = { .word =
> 18, .mask = BIT(22) },
> > >> + [IMX95_OCOTP_LVDS1_GATE] = { .word =
> 18, .mask = BIT(27) },
> > >> + [IMX95_OCOTP_ISP_GATE] = { .word =
> 18, .mask = BIT(29) },
> > >> + [IMX95_OCOTP_USB1_GATE] = { .word =
> 19, .mask = BIT(2) },
> > >> + [IMX95_OCOTP_USB2_GATE] = { .word =
> 19, .mask = BIT(3) },
> > >> + [IMX95_OCOTP_NETC_GATE] = { .word =
> 19, .mask = BIT(4) },
> > >> + [IMX95_OCOTP_PCIE1_GATE] = { .word =
> 19, .mask = BIT(6) },
> > >> + [IMX95_OCOTP_PCIE2_GATE] = { .word =
> 19, .mask = BIT(7) },
> > >> + [IMX95_OCOTP_ADC1_GATE] = { .word =
> 19, .mask = BIT(8) },
> > >> + [IMX95_OCOTP_EARC_RX_GATE] = { .word =
> 19, .mask = BIT(11) },
> > >> + [IMX95_OCOTP_GPU3D_GATE] = { .word =
> 19, .mask = BIT(16) },
> > >> + [IMX95_OCOTP_VPU_GATE] = { .word =
> 19, .mask = BIT(17) },
> > >> + [IMX95_OCOTP_JPEG_ENC_GATE] = { .word =
> 19, .mask = BIT(18) },
> > >> + [IMX95_OCOTP_JPEG_DEC_GATE] = { .word =
> 19, .mask = BIT(19) },
> > >> + [IMX95_OCOTP_MIPI_CSI1_GATE] = { .word =
> 19, .mask = BIT(21) },
> > >> + [IMX95_OCOTP_MIPI_CSI2_GATE] = { .word =
> 19, .mask = BIT(22) },
> > >> + [IMX95_OCOTP_MIPI_DSI1_GATE] = { .word =
> 19, .mask = BIT(23) },
> > >> +};
> > >> +
> > >> +static const struct ocotp_access_gates imx95_access_gates_info =
> {
> > >> + .num_words = 3,
> > >> + .words = {17, 18, 19},
> > >> + .num_gates = ARRAY_SIZE(imx95_access_gate),
> > >> + .gates = imx95_access_gate,
> > >> +};
> > >> +
> > >> static const struct ocotp_devtype_data imx95_ocotp_data = {
> > >> + .access_gates = &imx95_access_gates_info,
> > >> .reg_off = 0x8000,
> > >> .reg_read = imx_ocotp_reg_read,
> > >> .size = 2048,
> > >>
> > >>
> > >
> > >
> >
> >
>
>
> --
> 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%7C55d61ee
> fd50749808d4a08dd3099320d%7C686ea1d3bc2b4c6fa92cd99c5c301
> 635%7C0%7C0%7C638720156723988367%7CUnknown%7CTWFpbGZ
> sb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW
> 4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=
> %2BCsoNoGLNpZiltu%2BMD%2BUCMAwHcmXCL0LKVq9olfSIoU%3D&r
> eserved=0
>
Powered by blists - more mailing lists