From: Tudor Ambarus <tudor.ambarus@linaro.org>
To: "Krzysztof Kozlowski" <krzk@kernel.org>,
"André Draszik" <andre.draszik@linaro.org>,
"Alim Akhtar" <alim.akhtar@samsung.com>
Cc: Peter Griffin <peter.griffin@linaro.org>,
Will McVicker <willmcvicker@google.com>,
kernel-team@android.com, linux-kernel@vger.kernel.org,
linux-samsung-soc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v2 2/2] firmware: exynos-acpm: allow use during system shutdown
Date: Wed, 26 Mar 2025 07:24:22 +0000 [thread overview]
Message-ID: <42905f72-100b-432a-becb-7e1f835e518e@linaro.org> (raw)
In-Reply-To: <60732c52-7774-48c6-8ec8-44ae82d86267@kernel.org>
On 3/25/25 8:07 AM, Krzysztof Kozlowski wrote:
> On 25/03/2025 09:01, André Draszik wrote:
>> Hi Krzysztof,
>>
>> On Tue, 2025-03-25 at 08:57 +0100, Krzysztof Kozlowski wrote:
>>> On 24/03/2025 16:34, André Draszik wrote:
>>>> +static bool acpm_may_sleep(void)
>>>> +{
>>>> + return system_state <= SYSTEM_RUNNING ||
>>>> + (IS_ENABLED(CONFIG_PREEMPT_COUNT) ? preemptible() : !irqs_disabled());
>>>> +}
>>>> +
>>>> /**
>>>> * acpm_dequeue_by_polling() - RX dequeue by polling.
>>>> * @achan: ACPM channel info.
>>>> @@ -300,7 +314,10 @@ static int acpm_dequeue_by_polling(struct acpm_chan *achan,
>>>> return 0;
>>>>
>>>> /* Determined experimentally. */
>>>> - usleep_range(20, 30);
>>>> + if (!acpm_may_sleep())
>>>> + udelay(10);
>>>> + else
>>>
>>> ... and what do you do if IRQs get disabled exactly in this moment? This
>>> is just racy. You cannot check for a condition and assume it will be
>>> valid for whatever time you want it to be valid.
>>>
>>> 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 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?
Cheers,
ta
next prev parent reply other threads:[~2025-03-26 7:24 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-24 15:34 [PATCH v2 0/2] " André Draszik
2025-03-24 15:34 ` [PATCH v2 1/2] firmware: exynos-acpm: use ktime APIs for timeout detection André Draszik
2025-03-24 15:34 ` [PATCH v2 2/2] firmware: exynos-acpm: allow use during system shutdown André Draszik
2025-03-25 7:57 ` Krzysztof Kozlowski
2025-03-25 8:01 ` André Draszik
2025-03-25 8:07 ` Krzysztof Kozlowski
2025-03-26 7:24 ` Tudor Ambarus [this message]
2025-03-26 7:36 ` Krzysztof Kozlowski
2025-03-26 9:15 ` André Draszik
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42905f72-100b-432a-becb-7e1f835e518e@linaro.org \
--to=tudor.ambarus@linaro.org \
--cc=alim.akhtar@samsung.com \
--cc=andre.draszik@linaro.org \
--cc=kernel-team@android.com \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-samsung-soc@vger.kernel.org \
--cc=peter.griffin@linaro.org \
--cc=willmcvicker@google.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®