linux-kernel - Re: [PATCH v2 2/2] firmware: exynos-acpm: allow use during system shutdown

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: <4f2252fb-841e-46e0-942a-5db9767db89f@kernel.org>
Date: Wed, 26 Mar 2025 08:36:01 +0100
From: Krzysztof Kozlowski <krzk@...nel.org>
To: Tudor Ambarus <tudor.ambarus@...aro.org>,
 André Draszik <andre.draszik@...aro.org>,
 Alim Akhtar <alim.akhtar@...sung.com>
Cc: Peter Griffin <peter.griffin@...aro.org>,
 Will McVicker <willmcvicker@...gle.com>, kernel-team@...roid.com,
 linux-kernel@...r.kernel.org, linux-samsung-soc@...r.kernel.org,
 linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v2 2/2] firmware: exynos-acpm: allow use during system
 shutdown

On 26/03/2025 08:24, Tudor Ambarus wrote:
>>>>
>>>> What happens if system_state is changed to shutdown in this particular
>>>> moment? How did you prevent this from happening?
>>>
>>> Yes, and that's also what the I2C subsystem is doing, AFAICS, see
>>> i2c_in_atomic_xfer_mode() and its use. This is to make a very
>>> specific corner case work, similar to I2C which has to deal with
>>> the same issue during shutdown.
>>
>> But they don't have a choice so they try to do the best to avoid
>> sleeping. And it is a subsystem, not a driver, which means their
>> patterns are sometimes special. Drivers should not replicate subsystem
>> workarounds.
>>
>>>
>>> Would you have a better suggestion?
>>
>> Yes, you have a choice, you can always use udelay. Driver code is
>> supposed to be always correct.
> 
> Using udelay() is good enough for now. I see that downstream uses a
> usleep_range(50, 100) and I'm concerned that we're going to waste lots
> of cpu cyles once more and more clients get added.


If this is going to be the case, then we can revisit it with some
numbers. Especially if this ACPM turns out to be a bus driver.

> 
> If there's no concurrency on the ACPM queue mutexes at late system
> shutdown, would it work to pass the don't sleep requirement from the
> client to ACPM and use udelay only then?


You mean the client will choose what sort of delay it expects (sleeping
or not)? That would work, but can you actually control it from the
client side?


Best regards,
Krzysztof