[1/2] dt-bindings: watchdog: Add arm,smc-wdt watchdog arm,smc-wdt compatible
diff mbox series

Message ID 20200214172512.1.I02ebc5b8743b1a71e0e15f68ea77e506d4e6f840@changeid
State Changes Requested
Headers show
Series
  • Add a watchdog driver that uses ARM Secure Monitor Calls.
Related show

Checks

Context Check Description
robh/dt-meta-schema success
robh/checkpatch success

Commit Message

Evan Benn Feb. 14, 2020, 6:26 a.m. UTC
This watchdog can be used on ARM systems with a Secure
Monitor firmware to forward watchdog operations to
firmware via a Secure Monitor Call.

Signed-off-by: Evan Benn <evanbenn@chromium.org>
---

 .../bindings/watchdog/arm,smc-wdt.yaml        | 30 +++++++++++++++++++
 MAINTAINERS                                   |  6 ++++
 2 files changed, 36 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/watchdog/arm,smc-wdt.yaml

Comments

Rob Herring Feb. 19, 2020, 10:30 p.m. UTC | #1
On Fri, Feb 14, 2020 at 05:26:36PM +1100, Evan Benn wrote:
> This watchdog can be used on ARM systems with a Secure
> Monitor firmware to forward watchdog operations to
> firmware via a Secure Monitor Call.
> 
> Signed-off-by: Evan Benn <evanbenn@chromium.org>
> ---
> 
>  .../bindings/watchdog/arm,smc-wdt.yaml        | 30 +++++++++++++++++++
>  MAINTAINERS                                   |  6 ++++
>  2 files changed, 36 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/watchdog/arm,smc-wdt.yaml
> 
> diff --git a/Documentation/devicetree/bindings/watchdog/arm,smc-wdt.yaml b/Documentation/devicetree/bindings/watchdog/arm,smc-wdt.yaml
> new file mode 100644
> index 000000000000..5170225b0c98
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/watchdog/arm,smc-wdt.yaml
> @@ -0,0 +1,30 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/watchdog/arm,smc-wdt.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: ARM Secure Monitor Call based watchdog

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)?

> +
> +allOf:
> +  - $ref: "watchdog.yaml#"
> +
> +maintainers:
> +  - Julius Werner <jwerner@chromium.org>
> +
> +properties:
> +  compatible:
> +    enum:
> +      - arm,smc-wdt
> +
> +required:
> +  - compatible
> +
> +examples:
> +  - |
> +    watchdog {

I'd expect this to be a child of whatever firmware implements this 
function.

> +      compatible = "arm,smc-wdt";
> +      timeout-sec = <15>;
> +    };
> +
> +...
> diff --git a/MAINTAINERS b/MAINTAINERS
> index e48ab79879ac..5c45536e1177 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -1421,6 +1421,12 @@ S:	Maintained
>  F:	Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.txt
>  F:	drivers/irqchip/irq-al-fic.c
>  
> +ARM SMC WATCHDOG DRIVER
> +M:	Julius Werner <jwerner@chromium.org>
> +R:	Evan Benn <evanbenn@chromium.org>
> +S:	Maintained
> +F:	devicetree/bindings/watchdog/arm,smc-wdt.yaml
> +
>  ARM SMMU DRIVERS
>  M:	Will Deacon <will@kernel.org>
>  R:	Robin Murphy <robin.murphy@arm.com>
> -- 
> 2.25.0.265.gbab2e86ba0-goog
>
Julius Werner Feb. 19, 2020, 11:04 p.m. UTC | #2
> 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
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.
Guenter Roeck Feb. 19, 2020, 11:20 p.m. UTC | #3
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.
Evan Benn Feb. 20, 2020, 6:41 a.m. UTC | #4
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@roeck-us.net> 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.
Guenter Roeck Feb. 20, 2020, 3:43 p.m. UTC | #5
On Thu, Feb 20, 2020 at 05:41:09PM +1100, 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
> 
FWIW, the Meson driver has more functionality.

Guenter

> Thanks
> 
> 
> On Thu, Feb 20, 2020 at 10:20 AM Guenter Roeck <linux@roeck-us.net> 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.
Xingyu Chen Feb. 21, 2020, 3:36 p.m. UTC | #6
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@roeck-us.net> 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.
> .
Julius Werner Feb. 21, 2020, 7:41 p.m. UTC | #7
> 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.

I think the best way to solve this would be to put the SMC function ID
as another field into the device tree, so that multiple vendors could
share the same driver even if their firmware interface uses a
different SMC. But they still have to implement the same API for that
SMC, of course, not sure if the Meson driver is suitable for that (but
if it is then I think merging those drivers would be a good idea).
Guenter Roeck Feb. 21, 2020, 8:46 p.m. UTC | #8
On Fri, Feb 21, 2020 at 11:41:47AM -0800, Julius Werner wrote:
> > 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.
> 
> I think the best way to solve this would be to put the SMC function ID
> as another field into the device tree, so that multiple vendors could
> share the same driver even if their firmware interface uses a
> different SMC. But they still have to implement the same API for that
> SMC, of course, not sure if the Meson driver is suitable for that (but
> if it is then I think merging those drivers would be a good idea).

More common would be to have a single driver and multiple compatible
strings. The driver would then pick the SMC function ID from the compatible
string. After all, we'd not only need the SMC function ID; parameters
are also different.

Guenter
Xingyu Chen Feb. 22, 2020, 4:01 a.m. UTC | #9
Hi, Julius

On 2020/2/22 3:41, Julius Werner wrote:
>> 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.
> I think the best way to solve this would be to put the SMC function ID
> as another field into the device tree, so that multiple vendors could
> share the same driver even if their firmware interface uses a
> different SMC. But they still have to implement the same API for that
> SMC, of course, not sure if the Meson driver is suitable for that (but
> if it is then I think merging those drivers would be a good idea).
The SMC function ID may be solved by the DTS, but the wdt indexs(Eg: 
SMCWD_INFO) are also different
for each vendor. The imx_sc_wdt.c is also use the SMC to operate the 
WDT, but the wdt indexs(Eg: IMX_SIP_TIMER_START_WDOG)
are different from ours. IMO, If the ATF can implement a common hal 
interface and index for watchdog, then writing a
common smc wdt driver will be easier to compatible with all vendors.

Best Regards
>
> .
Evan Benn Feb. 24, 2020, 1:10 a.m. UTC | #10
Hello,

I think the intention is that this driver talks to a 'standard' arm
smc firmware watchdog call:

https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3405

Each device could re-implement that ATF driver to talk to the specific hardware,
and could perhaps use a custom SMCWD_FUNC_ID, defined in the dts.

The goal was to provide an ATF patch and linux driver patch that would
be generic. But the above ATF patch
is only for mt8173. Right now it just specifies an interface. It has
less functionality than your meson driver Xingyu.
If it is not suitable, that is fine.

The above ATF patch is deployed on oak, elm, and hana mt8173
chromebook devices, this driver is intended to support those devices.

Evan


On Sat, Feb 22, 2020 at 3:01 PM Xingyu Chen <xingyu.chen@amlogic.com> wrote:
>
> Hi, Julius
>
> On 2020/2/22 3:41, Julius Werner wrote:
> >> 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.
> > I think the best way to solve this would be to put the SMC function ID
> > as another field into the device tree, so that multiple vendors could
> > share the same driver even if their firmware interface uses a
> > different SMC. But they still have to implement the same API for that
> > SMC, of course, not sure if the Meson driver is suitable for that (but
> > if it is then I think merging those drivers would be a good idea).
> The SMC function ID may be solved by the DTS, but the wdt indexs(Eg:
> SMCWD_INFO) are also different
> for each vendor. The imx_sc_wdt.c is also use the SMC to operate the
> WDT, but the wdt indexs(Eg: IMX_SIP_TIMER_START_WDOG)
> are different from ours. IMO, If the ATF can implement a common hal
> interface and index for watchdog, then writing a
> common smc wdt driver will be easier to compatible with all vendors.
>
> Best Regards
> >
> > .
Julius Werner Feb. 25, 2020, 1:23 a.m. UTC | #11
> The SMC function ID may be solved by the DTS, but the wdt indexs(Eg:
> SMCWD_INFO) are also different
> for each vendor. The imx_sc_wdt.c is also use the SMC to operate the
> WDT, but the wdt indexs(Eg: IMX_SIP_TIMER_START_WDOG)
> are different from ours. IMO, If the ATF can implement a common hal
> interface and index for watchdog, then writing a
> common smc wdt driver will be easier to compatible with all vendors.

The MediaTek driver is still in flux (e.g. still being reviewed in
Trusted Firmware here:
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3405),
we can still change it. So if we can now decide on making this a
"standard" driver, we can change the MediaTek interface to match IMX
and standardize on that. (There are existing Chromebooks shipped with
a different interface, but we could handle those separately with
downstream patches. I think having a unified interface that will
prevent this problem in the future would be worth some extra
complication right now.)
Xingyu Chen Feb. 25, 2020, 7:44 a.m. UTC | #12
Hi, Julius

On 2020/2/25 9:23, Julius Werner wrote:
>> The SMC function ID may be solved by the DTS, but the wdt indexs(Eg:
>> SMCWD_INFO) are also different
>> for each vendor. The imx_sc_wdt.c is also use the SMC to operate the
>> WDT, but the wdt indexs(Eg: IMX_SIP_TIMER_START_WDOG)
>> are different from ours. IMO, If the ATF can implement a common hal
>> interface and index for watchdog, then writing a
>> common smc wdt driver will be easier to compatible with all vendors.
> The MediaTek driver is still in flux (e.g. still being reviewed in
> Trusted Firmware here:
> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/3405),
> we can still change it. So if we can now decide on making this a
> "standard" driver, we can change the MediaTek interface to match IMX
> and standardize on that. (There are existing Chromebooks shipped with
> a different interface, but we could handle those separately with
> downstream patches. I think having a unified interface that will
> prevent this problem in the future would be worth some extra
> complication right now.)
If the ATF provides a common watchdog hal interface and index, I am 
happy to match
the generic sec wdt driver. Compared to the current MTK wdt index [0], 
the following
indexes need to be supported for meson wdt [1].
- *_INIT.
- *_GETTIMEOUT.
- *_RESETNOW.  It is used to reset the system right now, similar to your 
SOFT RESET.

For another platform-specific parameter "SMC function ID", the generic 
sec wdt driver can get it from the dts, but if
the driver want to compatible with more vendors in the future, maybe we 
should consider Guenter's suggestion at [2]

[0]: https://patchwork.kernel.org/patch/11395579/
[1]: https://patchwork.kernel.org/patch/11331271/
[2]: 
https://lore.kernel.org/linux-watchdog/20200220155159.GB29658@roeck-us.net/T/#md00328548222965054cd19ec7dda074f8fc09fe2

Best Regards
> .

Patch
diff mbox series

diff --git a/Documentation/devicetree/bindings/watchdog/arm,smc-wdt.yaml b/Documentation/devicetree/bindings/watchdog/arm,smc-wdt.yaml
new file mode 100644
index 000000000000..5170225b0c98
--- /dev/null
+++ b/Documentation/devicetree/bindings/watchdog/arm,smc-wdt.yaml
@@ -0,0 +1,30 @@ 
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/watchdog/arm,smc-wdt.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: ARM Secure Monitor Call based watchdog
+
+allOf:
+  - $ref: "watchdog.yaml#"
+
+maintainers:
+  - Julius Werner <jwerner@chromium.org>
+
+properties:
+  compatible:
+    enum:
+      - arm,smc-wdt
+
+required:
+  - compatible
+
+examples:
+  - |
+    watchdog {
+      compatible = "arm,smc-wdt";
+      timeout-sec = <15>;
+    };
+
+...
diff --git a/MAINTAINERS b/MAINTAINERS
index e48ab79879ac..5c45536e1177 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1421,6 +1421,12 @@  S:	Maintained
 F:	Documentation/devicetree/bindings/interrupt-controller/amazon,al-fic.txt
 F:	drivers/irqchip/irq-al-fic.c
 
+ARM SMC WATCHDOG DRIVER
+M:	Julius Werner <jwerner@chromium.org>
+R:	Evan Benn <evanbenn@chromium.org>
+S:	Maintained
+F:	devicetree/bindings/watchdog/arm,smc-wdt.yaml
+
 ARM SMMU DRIVERS
 M:	Will Deacon <will@kernel.org>
 R:	Robin Murphy <robin.murphy@arm.com>