linux-kernel - Re: [PATCH v3 2/3] firmware: add exynos ACPM protocol driver

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: <faghtvhan6xmhoezeaocmdusxkmy4g3vrldzn7mlukbh33isr6@c27o6p7a6a6f>
Date: Mon, 9 Dec 2024 09:29:58 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Markuss Broks <markuss.broks@...il.com>
Cc: Daniel Lezcano <daniel.lezcano@...aro.org>, 
	Tudor Ambarus <tudor.ambarus@...aro.org>, robh@...nel.org, krzk+dt@...nel.org, conor+dt@...nel.org, 
	alim.akhtar@...sung.com, linux-kernel@...r.kernel.org, linux-samsung-soc@...r.kernel.org, 
	devicetree@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, andre.draszik@...aro.org, 
	kernel-team@...roid.com, willmcvicker@...gle.com, peter.griffin@...aro.org, 
	javierm@...hat.com, tzimmermann@...e.de, vincent.guittot@...aro.org, 
	ulf.hansson@...aro.org, arnd@...db.de
Subject: Re: [PATCH v3 2/3] firmware: add exynos ACPM protocol driver

On Sun, Dec 08, 2024 at 06:38:50PM +0200, Markuss Broks wrote:
> 
> On 12/6/24 9:50 PM, Daniel Lezcano wrote:
> > On 12/6/24 14:28, Krzysztof Kozlowski wrote:
> > > On Fri, Dec 06, 2024 at 12:39:56AM +0100, Daniel Lezcano wrote:
> > > > > +# SPDX-License-Identifier: GPL-2.0-only
> > > > > +
> > > > > +config EXYNOS_ACPM_PROTOCOL
> > > > > +    tristate "Exynos Alive Clock and Power Manager (ACPM)
> > > > > Message Protocol"
> > > > 
> > > > Given the importance of this driver where a lot of PM services
> > > > rely on, does
> > > > it really make sense to allow it as a module ?
> > > > 
> > > > Some PM services may be needed very early in the boot process
> > > > 
> > > 
> > > If it works as module e.g. on Android, it is beneficial. I think the
> > > platform was booting fine without it, at least to some shell, so I can
> > > imagine this can be loaded a bit later.
> > 
> > Usually the firmware sets the frequency to the maximum in order to boot
> > the kernel as fast as possible. That may lead to thermal issues at boot
> > time where the thermal framework won't be able to kick in as some
> > components will depends on ACPM while the system stays at its highest
> > performance state.

I disagree with the first assumption: usually firmware selects high, but
safe frequency. Otherwise you would not be able to wait in bootloader
prompt.

> Also, as far as I understand, ACPM is used here as an interface to the PMIC,
> so every driver which would need power management from the main SoC PMIC
> would get deferred until the ACPM module has been loaded. This would make it

It was an issue 10 years ago, not anymore. Drivers handle deferred
probe.

> impossible to e.g. initialize the UFS or the MMC card before initramfs.

Which is not a problem, because you are supposed to have initramfs. This
is preferred way. Being this a module does not force you to use it as a
module, e.g. if in your setup you do not have initramfs (although it is
unlikely for arm64 platforms...).

Best regards,
Krzysztof