From: Krzysztof Kozlowski <krzk@kernel.org>
To: Daniel Lezcano <daniel.lezcano@linaro.org>, tglx@linutronix.de
Cc: linux-kernel@vger.kernel.org,
Thomas Fossati <thomas.fossati@linaro.org>,
Larisa Grigore <Larisa.Grigore@nxp.com>,
Ghennadi Procopciuc <ghennadi.procopciuc@nxp.com>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
"moderated list:ARM/STM32 ARCHITECTURE"
<linux-stm32@st-md-mailman.stormreply.com>,
"moderated list:ARM/STM32 ARCHITECTURE"
<linux-arm-kernel@lists.infradead.org>, dl-S32 <S32@nxp.com>
Subject: Re: [PATCH 2/2] clocksource/drivers/nxp-timer: Add the System Timer Module for the s32g platform
Date: Tue, 25 Mar 2025 19:42:03 +0100 [thread overview]
Message-ID: <e9216aaf-f53e-4256-bb73-489c2261d4c5@kernel.org> (raw)
In-Reply-To: <ff213c29-2a17-4776-a575-35e398e560ec@linaro.org>
On 25/03/2025 19:38, Daniel Lezcano wrote:
> On 25/03/2025 13:30, Krzysztof Kozlowski wrote:
>> On 25/03/2025 13:23, Daniel Lezcano wrote:
>
> [ ... ]
>
>>>>> + if (!stm_instances->clocksource && (stm_instances->features & STM_CLKSRC)) {
>>>>> +
>>>>> + /*
>>>>> + * First probed STM will be a clocksource
>>>>> + */
>>>>> + ret = nxp_stm_clocksource_init(dev, name, base, clk);
>>>>> + if (ret)
>>>>> + return ret;
>>>>> + stm_instances->clocksource++;
>>>>
>>>> That's racy. Devices can be brought async, ideally. This should be
>>>> rather idr or probably entire structure protected with a mutex.
>>>
>>> Mmh, interesting. I never had to think about this problem before
>>>
>>> Do you know at what moment the probing is parallelized ?
>>
>> You don't have PROBE_PREFER_ASYNCHRONOUS, so currently this will be
>> still sync, but I don't think we want it to be that way forever. I think
>> new drivers should not rely on implicit sync, because converting it
>> later to async will be difficult. It's easier to design it now or even
>> choose async explicitly (after testing).
>
> I gave a try and sometimes I reach the warnings below. I suspect the
> underlying code in the time framework is not yet ready for that.
>
> Even if it could be a good candidate for parallelizing the boot, this
> driver should stay sync ATM. Except if someone has the willing to dig
> into the core framework to find out the race when switching the
> clockevent. I think a thread is setting a timer while we are switching
> the driver.
>
> IMO, this core framework is too sensitive for this kind of change now.
>
> Alternatively, I can put anyway the lock which is harmless for the sync
> code but making the driver race free. The async flag can be put later.
Yes, that's what I meant, although indeed good point that clocksource is
way too early to be async. In that case this part is up to you, maybe my
suggestion was not correct.
Best regards,
Krzysztof
next prev parent reply other threads:[~2025-03-25 18:42 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-03-24 10:00 [PATCH 1/2] dt-bindings: NXP System Timer Module Daniel Lezcano
2025-03-24 10:00 ` [PATCH 2/2] clocksource/drivers/nxp-timer: Add the System Timer Module for the s32g platform Daniel Lezcano
2025-03-25 7:28 ` Ghennadi Procopciuc
2025-03-25 10:53 ` Daniel Lezcano
2025-03-25 11:40 ` Ghennadi Procopciuc
2025-03-25 12:09 ` Daniel Lezcano
2025-03-25 12:21 ` Ghennadi Procopciuc
2025-03-25 12:51 ` Daniel Lezcano
2025-03-25 13:21 ` Ghennadi Procopciuc
2025-03-25 13:54 ` Daniel Lezcano
2025-03-26 7:44 ` Ghennadi Procopciuc
2025-03-26 8:06 ` Daniel Lezcano
2025-03-26 9:19 ` Daniel Lezcano
2025-03-26 9:57 ` Ghennadi Procopciuc
2025-03-26 10:31 ` Daniel Lezcano
2025-03-26 13:31 ` Ghennadi Procopciuc
2025-03-25 7:30 ` Krzysztof Kozlowski
2025-03-25 12:23 ` Daniel Lezcano
2025-03-25 12:30 ` Krzysztof Kozlowski
2025-03-25 18:38 ` Daniel Lezcano
2025-03-25 18:42 ` Krzysztof Kozlowski [this message]
2025-03-24 14:21 ` [PATCH 1/2] dt-bindings: NXP System Timer Module Rob Herring (Arm)
2025-03-24 14:35 ` Krzysztof Kozlowski
2025-03-24 14:44 ` Rob Herring
2025-03-31 10:49 ` Ghennadi Procopciuc
2025-03-31 11:59 ` Ghennadi Procopciuc
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=e9216aaf-f53e-4256-bb73-489c2261d4c5@kernel.org \
--to=krzk@kernel.org \
--cc=Larisa.Grigore@nxp.com \
--cc=S32@nxp.com \
--cc=alexandre.torgue@foss.st.com \
--cc=daniel.lezcano@linaro.org \
--cc=ghennadi.procopciuc@nxp.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=tglx@linutronix.de \
--cc=thomas.fossati@linaro.org \
/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®