linux-kernel - RE: [EXT] Re: [PATCH] pmdomain: arm: scmi_pm

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:
 <PA4PR04MB94855052830C8F4874237BA6921F2@PA4PR04MB9485.eurprd04.prod.outlook.com>
Date: Mon, 13 Jan 2025 15:30:58 +0000
From: Ranjani Vaidyanathan <ranjani.vaidyanathan@....com>
To: Sudeep Holla <sudeep.holla@....com>, Peng Fan <peng.fan@....com>
CC: "Peng Fan (OSS)" <peng.fan@....nxp.com>, "cristian.marussi@....com"
	<cristian.marussi@....com>, "ulf.hansson@...aro.org"
	<ulf.hansson@...aro.org>, "arm-scmi@...r.kernel.org"
	<arm-scmi@...r.kernel.org>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-pm@...r.kernel.org"
	<linux-pm@...r.kernel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
Subject: RE: [EXT] Re: [PATCH] pmdomain: arm: scmi_pm_domain: Initialize state
 as off

Comments inline.

Regards,
Ranjani Vaidyanathan

-----Original Message-----
From: Sudeep Holla [mailto:sudeep.holla@....com] 
Sent: Monday, January 13, 2025 7:49 AM
To: Peng Fan <peng.fan@....com>
Cc: Peng Fan (OSS) <peng.fan@....nxp.com>; cristian.marussi@....com; Sudeep Holla <sudeep.holla@....com>; ulf.hansson@...aro.org; arm-scmi@...r.kernel.org; linux-arm-kernel@...ts.infradead.org; linux-pm@...r.kernel.org; linux-kernel@...r.kernel.org; Ranjani Vaidyanathan <ranjani.vaidyanathan@....com>
Subject: [EXT] Re: [PATCH] pmdomain: arm: scmi_pm_domain: Initialize state as off

Caution: This is an external email. Please take care when clicking links or opening attachments. When in doubt, report the message using the 'Report this email' button

On Mon, Jan 13, 2025 at 11:37:23AM +0000, Peng Fan wrote:
> > Subject: Re: [PATCH] pmdomain: arm: scmi_pm_domain: Initialize state 
> > as off
> >
> > On Fri, Jan 10, 2025 at 02:13:46PM +0800, Peng Fan (OSS) wrote:
> > > From: Peng Fan <peng.fan@....com>
> > >
> > > Per ARM SCMI Spec DEN0056E, page 16, "The platform may disable a 
> > > resource if no agent has requested to use that resource."
> > >
> >
> > True, but ...
> >
> > > Linux Kernel should not rely on a state that it has not requested, 
> > > so make state as off during initialization.
> > >
> >
> > IIUC, this was done to avoid any transitions if the bootloader like 
> > U- Boot has turned on the resource and OS can just rely on that stay.
>
> But if it is not U-Boot turned it on?

Not sure if I understand what exactly you mean by that.
[RV] Its possible that some other agent (M33/M7 running OS) in the system turned on the power domain. Resources in the same power domain can shared across agents.  That being said, uboot provides mechanism to clean up any power domains/clocks that it enabled. And our implementation of uboot does disable any power domain it powered up for downloading of images or anything else (display is a unique case if splash screen is enabled).

> Or U-Boot is in a separate agent?
>

No, it will be same as OS for the SCMI platform/agent as they use/share the same transport. It is hard to distinguish between them.

> > Anyways if the resource is not used by any driver/device in the 
> > kernel, won't it be turned off anyways ? What am I missing ?
>
> Because the power domain is ON, kernel will not issue SCMI to platform 
> to request it ON when kernel needs this power domain on.
>

Yes, but the agent(via bootloader) has already requested the SCMI platform,
so it should be fine. No ?
[RV] As mentioned above, it need not be the bootloader. And secondly how to handle this power domain during suspend/resume? It's possible that the agent that turned on the power domain initially will have different wakeup requirements. IMO Linux should completely be responsible for the power domains that the drivers need. 

> But in case when kernel is doing some jobs that needs the
> power domain ON, SCMI platform might power down the
> power domain because kernel agent not request that.
>

See my comment/question above.

--
Regards,
Sudeep