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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20250226031021.GA16342@nxa18884-linux>
Date: Wed, 26 Feb 2025 11:11:26 +0800
From: Peng Fan <peng.fan@....nxp.com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: Peng Fan <peng.fan@....com>, Chuck Cannon <chuck.cannon@....com>,
	Cristian Marussi <cristian.marussi@....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 11:49:01AM +0000, Sudeep Holla wrote:
>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.

ok. Let me try this in v3 and see how it looks like.

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

yes. For A55 only case, the PSCI should be used, and ATF will use CPU
protocol to manage A55 cores when needed.

>
>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.

Appreciate on help reviewing. Not sure you have time on V2 patchset[1].
I plan to send out V3 early next week(should be before RC5) with your new
comments in V1 and Cristian's comments in V2 addressed. Please let me know
if you have any conern.

[1]https://lore.kernel.org/all/20250212-imx-lmm-cpu-v2-0-3aee005968c1@nxp.com/

Thanks,
Peng
>
>--
>Regards,
>Sudeep

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ