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
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <10618164.nUPlyArG6x@steina-w>
Date: Wed, 12 Feb 2025 09:10:53 +0100
From: Alexander Stein <alexander.stein@...tq-group.com>
To: Peng Fan <peng.fan@....nxp.com>
Cc: Peng Fan <peng.fan@....com>, 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>, Srinivas Kandagatla <srinivas.kandagatla@...aro.org>, "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, "imx@...ts.linux.dev" <imx@...ts.linux.dev>, "linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v2 04/10] arm64: dts: imx8mn: Add access-controller references

Am Dienstag, 11. Februar 2025, 04:33:41 CET schrieb Peng Fan:
> 
> On Mon, Feb 10, 2025 at 04:48:56PM +0100, Alexander Stein wrote:
> >Am Montag, 10. Februar 2025, 03:36:48 CET schrieb Peng Fan:
> >> > Subject: Re: [PATCH v2 04/10] arm64: dts: imx8mn: Add access-
> >> > controller references
> >> > 
> >> > Hi Peng,
> >> > 
> >> > Am Freitag, 7. Februar 2025, 13:02:13 CET schrieb Peng Fan:
> >> > > On Fri, Feb 07, 2025 at 09:36:09AM +0100, Alexander Stein wrote:
> >> > > >Mark ocotp as a access-controller and add references on peripherals
> >> > > >which can be disabled (fused).
> >> > >
> >> > > I am not sure whether gpcv2 changes should be included in this
> >> > > patchset or not. Just add access-controller for fused IP will not work.
> >> > 
> >> > Well, I was able to successfully boot a i.MX8M Nano DualLite.
> >> > 
> >> > > i.MX8M BLK-CTRL/GPC will hang if the related power domain is still
> >> > > touched by kernel. The pgc can't power up/down because clock is
> >> > gated.
> >> > 
> >> > Well, with GPU node disabled, no one should enable the power domain.
> >> > But to be on the safe side I would also add access-controllers to the
> >> > corresponding power domains as well.
> >> > 
> >> > > This comment also apply to i.MX8MM/P.
> >> > 
> >> > Sure. Do you have any information what is actually disabled by those
> >> > fused?
> >> > It seems it's the IP and their power domains. Anything else?
> >> 
> >> In NXP downstream there is a patch for  drivers/pmdomain/imx/imx8m-blk-ctrl.c
> >> 
> >> soc: imx8m-blk-ctrl: Support fused modules
> >>     
> >>     For fused module, its pgc can't power up/down and clock is gated.
> >>     Because imx8m-blk-ctrl driver will pm_runtime_get_sync/pm_runtime_put
> >>     all power domains during suspend/resume. So we have to remove the
> >>     pgc and clock of fused module from blk-ctrl DTS node.
> >>     Update the driver to support such case.
> >> 
> >> But this patch also needs U-Boot to update device tree nodes,
> >> I recalled that U-Boot will remove gpc nodes, but not update blk-ctrl nodes.
> >
> >Does it work, if we add the access-controller as well for pgc_gpu3d
> >on imx8mp? There is nothing in blk-ctrl AFAICS. But for VPU there is.
> 
> Adding access-controller under pgc_gpu node will not make fwdevlink
> work for the pgc_gpu nodes. It does not have compatible, and device
> is created by gpcv2 driver using platform_device_alloc. Same to vpu.
> 
> >Which clock needs to be removed there in case g1 is disabled?
> 
> Take i.MX8MP VC8000E as example, the vpumix blk ctrl, the vc8000e
> reference under vpumix blkctrl should be removed, including pd and clock.

Wait, so you want to remove the last entry from these properties?

> clocks = <&clk IMX8MP_CLK_VPU_G1_ROOT>,
> 	 <&clk IMX8MP_CLK_VPU_G2_ROOT>,
> 	 <&clk IMX8MP_CLK_VPU_VC8KE_ROOT>;
> clock-names = "g1", "g2", "vc8000e";

This violates the DT binding.

> So for non-blkctrl nodes, it is fine to use access-controller and rely
> on fwdelink to defer probe. But for blk ctrl nodes, it will not work.
> 
> For pgc nodes, it may or may not matter, not very sure for now.
> 
> For blk ctrl nodes, we need provide a generic API saying
> access_control_check or directly using nvmem API.

Reading access-controllers.yaml this should still be feasible for
providing the necessary information.
But I'm note sure where to implement this. In e.g. imx-ocotp would be a very
SoC-specific API.

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/



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ