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] [day] [month] [year] [list]
Message-ID: <Z72uLenEmCwDCV5c@bogus>
Date: Tue, 25 Feb 2025 11:49:01 +0000
From: Sudeep Holla <sudeep.holla@....com>
To: Peng Fan <peng.fan@....nxp.com>
Cc: Peng Fan <peng.fan@....com>, Chuck Cannon <chuck.cannon@....com>,
	Cristian Marussi <cristian.marussi@....com>,
	Sudeep Holla <sudeep.holla@....com>,
	Shawn Guo <shawnguo@...nel.org>,
	Sascha Hauer <s.hauer@...gutronix.de>,
	Pengutronix Kernel Team <kernel@...gutronix.de>,
	Fabio Estevam <festevam@...il.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"arm-scmi@...r.kernel.org" <arm-scmi@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>,
	"imx@...ts.linux.dev" <imx@...ts.linux.dev>
Subject: Re: [PATCH 3/5] firmware: arm_scmi: imx: Add LMM and CPU
 documentation

On Tue, Feb 25, 2025 at 08:42:03PM +0800, Peng Fan wrote:
> On Tue, Feb 25, 2025 at 10:21:58AM +0000, Sudeep Holla wrote:
> >On Thu, Jan 23, 2025 at 01:30:43AM +0000, Peng Fan wrote:
> >>
> >> This is to manage the M7 core by Linux. I just put more documentation here.
> >> CPU protocol is also used by ATF to manage AP cores.
> >>
> >
> >Good
> >
> >> > Also what other CPUs are we talking here.
> >>
> >> M7 core
> >>
> >
> >Are they referred by any other name in the system ? I reason I ask is using
> >plain "CPU" is too generic and confusing. At the same time using "M7" may be
> >too specific. I am trying to see if there is any middle ground.
>
> "CPU", if you mean the protocol name SCMI_CPU, there is no good choices.
> I could add a note that "CPU indicates the various cores of i.MX SoC,
> one CPU represents one core"
>

Just a wild suggestion, you don't have to take this. Can it be called
SM CPU or something ? If you can't change the firmware documents which
is understandable, I suggest we call it sm_cpu or something appended before
cpu to distinguish it from the AP CPUs on which Linux runs.

> The documentation origin from https://github.com/nxp-imx/imx-sm
> hard for me to drive a change to use other name.
>
> Anyway if you have ideas, I could bring to our firmware owner.
>
> >
> >> In general I would like to
> >> > explore the possibility of collapsing this with LM protocol. CPUs within
> >> > LM is LM's responsibility to bring up. And CPU can be seen as an LM for
> >> > sake of this vendor protocol. I am not get into details here yet before I
> >> > can understand what these CPUs are really in the system and why we
> >> > need this.
> >>
> >> Our system supports M7 and A55 in one LM, so A55 use CPU protocol to
> >> manage M7. When M7 and A55 in different LM, use LM protocol to
> >> manage M7 LM.
> >>
> >
> >The LM(assuming Logical Module/Machine) is an abstract construct, it should
> >apply to even subset of components within an LM. Just wondering what are
> >specific reasons do you think applying LM protocol you have on those M7
> >CPUs alone in A55+M7 LM would not fit well.
>
> We have internal mail "NXP-ARM SCMI OEM extension" between NXP-ARM that I
> could not post here. In that mail, LM is explained.
>

Fair enough. Please don't share any info that can't be. I understand.

> It is the LM protocol design that it only applies to the whole LM.
> If the LM has A55+M7, A55+M7 will both be handled.
> If the LM only has A55, A55 only be handled.
> If the LM only has M7, M7 only be handled.
>
> When M7 + A55 in one LM, using LM protocol to handle M7 will make A55 not
> work properly. The current linux usecase is remoteproc, that means
> stop M7 will make A55 also stop. So need use CPU protocol here.
>
> When M7 and A55 in separate LM, using LM protocol to handle M7 LM works well.
> The usecase is still remoteproc. In separate LM, A55 CPU protocol will be
> blocked to handle M7 CPU per firmware security.
>

Thanks, I am now clear on LM has A55+M7 and M7 only. However your above
statement relating to LMs with A55 only is not clear. If they run Linux,
they just need to still use PSCI and this CPU protocol shouldn't be used
to control them. Can you clarify on that ?

Other than that, it looks like we do need both LM and CPU. Just asking
all the details so that if in future we have a similar need that needs to
be a standard protocol, it would help us better.

--
Regards,
Sudeep

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ