From: mateusz.nowicki@posteo.net
To: Guenter Roeck <linux@roeck-us.net>
Cc: Wim Van Sebroeck <wim@linux-watchdog.org>,
linux-watchdog@vger.kernel.org,
Julius Werner <jwerner@chromium.org>,
Evan Benn <evanbenn@chromium.org>, Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Maxime Coquelin <mcoquelin.stm32@gmail.com>,
Alexandre Torgue <alexandre.torgue@foss.st.com>,
Antonio Borneo <antonio.borneo@foss.st.com>,
Marek Vasut <marex@nabladev.com>,
devicetree@vger.kernel.org,
linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH 0/3] watchdog: arm_smc_wdt: allow a list of SMC function ids
Date: Wed, 04 Nov 2026 18:10:37 +0000 [thread overview]
Message-ID: <37f9e5e73070972f224583bc1581e400@posteo.net> (raw)
In-Reply-To: <c742c878-d4b2-48d8-972e-a09aa4d215c7@roeck-us.net>
On 11/4/26 Guenter Roeck wrote:
> On 11/4/26 08:16, Mateusz Nowicki wrote:
>> My earlier patch, commit ae4d08bbe3f4 ("arm64: dts: st: fix arm,smc-id
>> of the SMC watchdog on stm32mp2"), switched the dtsi to 0xbc000000.
>> That
>> made the watchdog work with current OP-TEE, but it broke boards that
>> run
>> the older firmware. So today 6.18.y uses one id and 7.4 the other.
>> When
>> the kernel and the firmware disagree, nobody pets the watchdog that
>> the
>> bootloader started, and the board resets after 32 seconds. Marek hit
>> this even with a recovery kernel, which is about the worst place for
>> it.
>>
>
> So the DT on the board is updated to use the new ID but the firmware
> itself
> isn't ? That seems a bit odd; I would have assumed that the DT on a
> board
> is kept in sync with its firmware. Is that not the case here ?
Not necessarily. On these boards the DTB is built from the kernel tree
and installed with the kernel, U-Boot just loads it from the boot
partition. TF-A and OP-TEE sit in the FIP and are updated separately, so
updating the kernel alone changes the ID. That's how Marek got hit: he
updated OP-TEE, but his recovery kernel still had the old DTB.
>> The idea from that thread: let arm,smc-id be a list. The driver tries
>> the ids one by one and keeps the first one the firmware accepts. Older
>> kernels only read the first cell, so they behave exactly as they do
>> now. For stm32mp2 the list is <0xbc000000 0xb200005a>. Calling an id
>> that belongs to some other firmware service would be bad, so the
>> binding says the list may only hold ids known to be this watchdog.
>>
>
> Would it possibly make sense to check keep a list of known IDs in the
> driver ? It already checks 0x82003D06, so it might as well check a
> sequence.
Fine with me, and it avoids the binding issue. I'd just rather not try
the ST IDs on every platform, so how about making the list per
compatible:
compatible = "st,stm32mp25-smc-wdt", "arm,smc-wdt";
with { 0xbc000000, 0xb200005a } as match data for it. arm,smc-id stays a
single u32 and, if present, is tried first. Older kernels just match
"arm,smc-wdt" and behave as today.
If that works for you and the DT folks, I'll send v2.
Thanks,
Mateusz
next prev parent reply other threads:[~2026-11-04 18:10 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-04 16:16 [RFC PATCH 0/3] watchdog: arm_smc_wdt: allow a list of SMC function ids Mateusz Nowicki
2026-11-04 16:16 ` [RFC PATCH 1/3] dt-bindings: watchdog: arm-smc-wdt: allow a list of SMC ids Mateusz Nowicki
2026-11-04 16:25 ` sashiko-bot
2026-11-04 16:47 ` Marek Vasut
2026-11-04 16:16 ` [RFC PATCH 2/3] watchdog: arm_smc_wdt: try every id of arm,smc-id Mateusz Nowicki
2026-11-04 16:16 ` [RFC PATCH 3/3] arm64: dts: st: list both watchdog SMC ids on stm32mp23 and stm32mp25 Mateusz Nowicki
2026-11-04 16:39 ` [RFC PATCH 0/3] watchdog: arm_smc_wdt: allow a list of SMC function ids Guenter Roeck
2026-11-04 16:46 ` Marek Vasut
2026-11-04 18:10 ` mateusz.nowicki [this message]
2026-11-04 18:59 ` Guenter Roeck
2026-11-05 2:13 ` Julius Werner
2026-11-05 10:04 ` mateusz.nowicki
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=37f9e5e73070972f224583bc1581e400@posteo.net \
--to=mateusz.nowicki@posteo.net \
--cc=alexandre.torgue@foss.st.com \
--cc=antonio.borneo@foss.st.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=evanbenn@chromium.org \
--cc=jwerner@chromium.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-stm32@st-md-mailman.stormreply.com \
--cc=linux-watchdog@vger.kernel.org \
--cc=linux@roeck-us.net \
--cc=marex@nabladev.com \
--cc=mcoquelin.stm32@gmail.com \
--cc=robh@kernel.org \
--cc=wim@linux-watchdog.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