Re: [PATCH 1/2] dt-bindings: watchdog: Add arm,smc-wdt watchdog arm,smc-wdt compatible

From: Xingyu Chen
Date: Fri Feb 21 2020 - 10:35:46 EST


Hi, Evan

Because the ATF does not define standard wdt index, each vendor defines its own index.
So I don't think that the current driver[0] can fully cover my usecases. As discussed in your
previous email, the meson wdt driver [1] can use the arm_smccc instead of meson_sm_call.

[0]: https://patchwork.kernel.org/patch/11395579/
[1]: https://patchwork.kernel.org/patch/11331271/

Best Regards

On 2020/2/20 14:41, Evan Benn wrote:
Dear Xingyu,

Could this driver also cover your usecase? I am not familiar with
meson, but it seems like the meson calls could
be replaced with arm_smccc calls. Then this driver will cover both
chips. I am not sure if your firmware is upstream
somewhere, but this might be adapted;
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3405

Thanks


On Thu, Feb 20, 2020 at 10:20 AM Guenter Roeck <linux@xxxxxxxxxxxx> wrote:
On Wed, Feb 19, 2020 at 03:04:54PM -0800, Julius Werner wrote:
You are not the first 'watchdog in firmware accessed via an SMC call'.
Is there some more detail about what implementation this is? Part of
TF-A? Defined by some spec (I can dream)?
This is just some random implementation written by me because we
needed one. I would like it to be the new generic implementation, but
it sounds like people here prefer the naming to be MediaTek specific
(at least for now). The other SMC watchdog we're aware of is
imx_sc_wdt but unfortunately that seems to hardcode platform-specific
There is one more pending, for Meson SMC.

https://patchwork.kernel.org/project/linux-watchdog/list/?series=227733

Unfortunately it uses Meson firmware API functions, though it has pretty
much the same functionality since those ultimately end up calling
arm_smccc_smc().

Guenter

details in the interface (at least in the pretimeout SMC) so we can't
just expand that. With this driver I tried to directly wrap the kernel
watchdog interface so it should be platform-agnostic and possible to
expand this driver to other platforms later if desired. The SMC
function ID would still always have to be platform-specific,
unfortunately (but we could pass it in through the device tree), since
the Arm SMC spec doesn't really leave any room for OS-generic SMCs
like this.
.