[PATCH 1/2] dt-bindings: watchdog: gpio: add minimum interval

[PATCH 1/2] dt-bindings: watchdog: gpio: add minimum interval

[Isaac True]

Add the "min_hw_margin_ms" parameter to gpio_wdt devices, allowing a
minimum interval to be specified, stopping watchdog devices from being
fed too quickly if they require a certain interval between feeds.

Signed-off-by: Isaac True <isaac.true@canonical.com>
---
 Documentation/devicetree/bindings/watchdog/gpio-wdt.txt | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt b/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
index 198794963786..4f13dbbf12fd 100644
--- a/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
+++ b/Documentation/devicetree/bindings/watchdog/gpio-wdt.txt
@@ -12,6 +12,8 @@ Required Properties:
     the opposite level disables the WDT. Active level is determined
     by the GPIO flags.
 - hw_margin_ms: Maximum time to reset watchdog circuit (milliseconds).
+- min_hw_margin_ms: Minimum time to reset watchdog circuit (milliseconds).
+  Defaults to 0 ms.
 
 Optional Properties:
 - always-running: If the watchdog timer cannot be disabled, add this flag to
-- 
2.34.1

[PATCH 2/2] watchdog: gpio: add configurable minimum interval

[Isaac True]

Add the "min_hw_margin_ms" parameter to gpio_wdt devices, allowing a
minimum interval to be specified, stopping watchdog devices from being
fed too quickly if they require a certain interval between feeds.

Signed-off-by: Isaac True <isaac.true@canonical.com>
---
 drivers/watchdog/gpio_wdt.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/drivers/watchdog/gpio_wdt.c b/drivers/watchdog/gpio_wdt.c
index 0923201ce874..309f66536a14 100644
--- a/drivers/watchdog/gpio_wdt.c
+++ b/drivers/watchdog/gpio_wdt.c
@@ -110,6 +110,7 @@ static int gpio_wdt_probe(struct platform_device *pdev)
 	struct gpio_wdt_priv *priv;
 	enum gpiod_flags gflags;
 	unsigned int hw_margin;
+	unsigned int min_hw_margin;
 	const char *algo;
 	int ret;
 
@@ -144,6 +145,16 @@ static int gpio_wdt_probe(struct platform_device *pdev)
 	if (hw_margin < 2 || hw_margin > 65535)
 		return -EINVAL;
 
+	ret = of_property_read_u32(np, "min_hw_margin_ms", &min_hw_margin);
+	if (ret)
+		min_hw_margin = 0;
+
+	if (min_hw_margin > hw_margin) {
+		dev_err(dev,
+			"Minimum interval cannot be greater than the watchdog interval");
+		return -EINVAL;
+	}
+
 	priv->always_running = of_property_read_bool(np,
 						     "always-running");
 
@@ -152,6 +163,7 @@ static int gpio_wdt_probe(struct platform_device *pdev)
 	priv->wdd.info		= &gpio_wdt_ident;
 	priv->wdd.ops		= &gpio_wdt_ops;
 	priv->wdd.min_timeout	= SOFT_TIMEOUT_MIN;
+	priv->wdd.min_hw_heartbeat_ms = min_hw_margin;
 	priv->wdd.max_hw_heartbeat_ms = hw_margin;
 	priv->wdd.parent	= dev;
 	priv->wdd.timeout	= SOFT_TIMEOUT_DEF;
-- 
2.34.1

Re: [PATCH 2/2] watchdog: gpio: add configurable minimum interval

[Rob Herring]

On Wed, Jun 29, 2022 at 01:06:26PM +0200, Isaac True wrote:
> Add the "min_hw_margin_ms" parameter to gpio_wdt devices, allowing a
> minimum interval to be specified, stopping watchdog devices from being
> fed too quickly if they require a certain interval between feeds.

I assume there is some real platform with a real problem you are trying 
to solve? Details please.

Can you just hardcode some min? Maybe 10% of the max or something. Is 
there a downside to a larger than necessary min?

Wouldn't be better to fix this without requiring a DT change and that 
could work on stable kernels if needed.

Rob

Re: [PATCH 2/2] watchdog: gpio: add configurable minimum interval

[Guenter Roeck]

On 7/1/22 10:18, Rob Herring wrote:
> On Wed, Jun 29, 2022 at 01:06:26PM +0200, Isaac True wrote:
>> Add the "min_hw_margin_ms" parameter to gpio_wdt devices, allowing a
>> minimum interval to be specified, stopping watchdog devices from being
>> fed too quickly if they require a certain interval between feeds.
> 
> I assume there is some real platform with a real problem you are trying
> to solve? Details please.
> 

Agreed, this should be explained in more detail.

> Can you just hardcode some min? Maybe 10% of the max or something. Is
> there a downside to a larger than necessary min?
> 

That would result in extra overhead in the watchdog core which would not
be required for all other hardware using this driver. I'd rather avoid that.

> Wouldn't be better to fix this without requiring a DT change and that
> could work on stable kernels if needed.
> 

Presumably that is some new hardware. Most of the watchdog drivers
needing this value can derive it from the compatible property. The
gpio watchdog driver is a bit different since it is supposed to work
on a variety of hardware using gpio pins for watchdog control.

Guenter

Re: [PATCH 2/2] watchdog: gpio: add configurable minimum interval

[Isaac True]

On Fri, 1 Jul 2022 at 19:48, Guenter Roeck <linux@roeck-us.net> wrote:
>
> On 7/1/22 10:18, Rob Herring wrote:
> > On Wed, Jun 29, 2022 at 01:06:26PM +0200, Isaac True wrote:
> >> Add the "min_hw_margin_ms" parameter to gpio_wdt devices, allowing a
> >> minimum interval to be specified, stopping watchdog devices from being
> >> fed too quickly if they require a certain interval between feeds.
> >
> > I assume there is some real platform with a real problem you are trying
> > to solve? Details please.
> >
>
> Agreed, this should be explained in more detail.

Yes this is a real platform using a TI TPS3850 watchdog chip. With
this chip you can configure a "window" which can detect early faults
(i.e. too frequent) in addition to the standard watchdog features. I
needed to add this minimum timeout to avoid watchdog resets in
situations such as where first U-Boot and then the Linux kernel feed
the watchdog with too short of an interval between them, or when
systemd was configured to use the watchdog device and was feeding it
too soon after taking over from the kernel.

> > Can you just hardcode some min? Maybe 10% of the max or something. Is
> > there a downside to a larger than necessary min?
> >
>
> That would result in extra overhead in the watchdog core which would not
> be required for all other hardware using this driver. I'd rather avoid that.
>

In the case of the TI TPS3850, the minimum timeout is configurable, so
I didn't want to add a hard-coded value to the driver.

> > Wouldn't be better to fix this without requiring a DT change and that
> > could work on stable kernels if needed.
> >
>
> Presumably that is some new hardware. Most of the watchdog drivers
> needing this value can derive it from the compatible property. The
> gpio watchdog driver is a bit different since it is supposed to work
> on a variety of hardware using gpio pins for watchdog control.
>

Yes this is new hardware. This use case is also not very common as
most watchdog chips don't have this window function or a minimum
interval, at least in my experience, so I did not want to make it the
default for everything.

Re: [PATCH 2/2] watchdog: gpio: add configurable minimum interval

[Rob Herring]

On Mon, Jul 04, 2022 at 01:05:04PM +0200, Isaac True wrote:
> On Fri, 1 Jul 2022 at 19:48, Guenter Roeck <linux@roeck-us.net> wrote:
> >
> > On 7/1/22 10:18, Rob Herring wrote:
> > > On Wed, Jun 29, 2022 at 01:06:26PM +0200, Isaac True wrote:
> > >> Add the "min_hw_margin_ms" parameter to gpio_wdt devices, allowing a
> > >> minimum interval to be specified, stopping watchdog devices from being
> > >> fed too quickly if they require a certain interval between feeds.
> > >
> > > I assume there is some real platform with a real problem you are trying
> > > to solve? Details please.
> > >
> >
> > Agreed, this should be explained in more detail.
> 
> Yes this is a real platform using a TI TPS3850 watchdog chip. With
> this chip you can configure a "window" which can detect early faults
> (i.e. too frequent) in addition to the standard watchdog features. I
> needed to add this minimum timeout to avoid watchdog resets in
> situations such as where first U-Boot and then the Linux kernel feed
> the watchdog with too short of an interval between them, or when
> systemd was configured to use the watchdog device and was feeding it
> too soon after taking over from the kernel.
> 
> > > Can you just hardcode some min? Maybe 10% of the max or something. Is
> > > there a downside to a larger than necessary min?
> > >
> >
> > That would result in extra overhead in the watchdog core which would not
> > be required for all other hardware using this driver. I'd rather avoid that.
> >
> 
> In the case of the TI TPS3850, the minimum timeout is configurable, so
> I didn't want to add a hard-coded value to the driver.
> 
> > > Wouldn't be better to fix this without requiring a DT change and that
> > > could work on stable kernels if needed.
> > >
> >
> > Presumably that is some new hardware. Most of the watchdog drivers
> > needing this value can derive it from the compatible property. The
> > gpio watchdog driver is a bit different since it is supposed to work
> > on a variety of hardware using gpio pins for watchdog control.
> >
> 
> Yes this is new hardware. This use case is also not very common as
> most watchdog chips don't have this window function or a minimum
> interval, at least in my experience, so I did not want to make it the
> default for everything.

Okay. However the existing property you copied has 2 problems. It uses 
underscores rather than hypens and doesn't use a standard unit suffix. 
So 'min-hw-margin-ms'.

Though maybe a new property instead:

timeout-range-ms = <min max>;

That's somewhat aligned to 'timeout-sec', and IMO, clearer meaning than 
'hw margin'.

Rob

Re: [PATCH 2/2] watchdog: gpio: add configurable minimum interval

[Isaac True]

On Tue, 5 Jul 2022 at 21:56, Rob Herring <robh@kernel.org> wrote:
>
> On Mon, Jul 04, 2022 at 01:05:04PM +0200, Isaac True wrote:
> > On Fri, 1 Jul 2022 at 19:48, Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > > On 7/1/22 10:18, Rob Herring wrote:
> > > > On Wed, Jun 29, 2022 at 01:06:26PM +0200, Isaac True wrote:
> > > >> Add the "min_hw_margin_ms" parameter to gpio_wdt devices, allowing a
> > > >> minimum interval to be specified, stopping watchdog devices from being
> > > >> fed too quickly if they require a certain interval between feeds.
> > > >
> > > > I assume there is some real platform with a real problem you are trying
> > > > to solve? Details please.
> > > >
> > >
> > > Agreed, this should be explained in more detail.
> >
> > Yes this is a real platform using a TI TPS3850 watchdog chip. With
> > this chip you can configure a "window" which can detect early faults
> > (i.e. too frequent) in addition to the standard watchdog features. I
> > needed to add this minimum timeout to avoid watchdog resets in
> > situations such as where first U-Boot and then the Linux kernel feed
> > the watchdog with too short of an interval between them, or when
> > systemd was configured to use the watchdog device and was feeding it
> > too soon after taking over from the kernel.
> >
> > > > Can you just hardcode some min? Maybe 10% of the max or something. Is
> > > > there a downside to a larger than necessary min?
> > > >
> > >
> > > That would result in extra overhead in the watchdog core which would not
> > > be required for all other hardware using this driver. I'd rather avoid that.
> > >
> >
> > In the case of the TI TPS3850, the minimum timeout is configurable, so
> > I didn't want to add a hard-coded value to the driver.
> >
> > > > Wouldn't be better to fix this without requiring a DT change and that
> > > > could work on stable kernels if needed.
> > > >
> > >
> > > Presumably that is some new hardware. Most of the watchdog drivers
> > > needing this value can derive it from the compatible property. The
> > > gpio watchdog driver is a bit different since it is supposed to work
> > > on a variety of hardware using gpio pins for watchdog control.
> > >
> >
> > Yes this is new hardware. This use case is also not very common as
> > most watchdog chips don't have this window function or a minimum
> > interval, at least in my experience, so I did not want to make it the
> > default for everything.
>
> Okay. However the existing property you copied has 2 problems. It uses
> underscores rather than hypens and doesn't use a standard unit suffix.
> So 'min-hw-margin-ms'.
>
> Though maybe a new property instead:
>
> timeout-range-ms = <min max>;
>
> That's somewhat aligned to 'timeout-sec', and IMO, clearer meaning than
> 'hw margin'.
>
> Rob

I agree that both the original property name and the new one aren't
great, but I didn't want to go changing the existing property for
everyone.  I could definitely add a new "timeout-range-ms" property -
should that be added in parallel to the original hw_margin_ms (i.e.
you can use one or the other), or completely replace the original?

Re: [PATCH 2/2] watchdog: gpio: add configurable minimum interval

[Guenter Roeck]

On Thu, Jul 07, 2022 at 11:00:45AM +0200, Isaac True wrote:
> On Tue, 5 Jul 2022 at 21:56, Rob Herring <robh@kernel.org> wrote:
> >
> > On Mon, Jul 04, 2022 at 01:05:04PM +0200, Isaac True wrote:
> > > On Fri, 1 Jul 2022 at 19:48, Guenter Roeck <linux@roeck-us.net> wrote:
> > > >
> > > > On 7/1/22 10:18, Rob Herring wrote:
> > > > > On Wed, Jun 29, 2022 at 01:06:26PM +0200, Isaac True wrote:
> > > > >> Add the "min_hw_margin_ms" parameter to gpio_wdt devices, allowing a
> > > > >> minimum interval to be specified, stopping watchdog devices from being
> > > > >> fed too quickly if they require a certain interval between feeds.
> > > > >
> > > > > I assume there is some real platform with a real problem you are trying
> > > > > to solve? Details please.
> > > > >
> > > >
> > > > Agreed, this should be explained in more detail.
> > >
> > > Yes this is a real platform using a TI TPS3850 watchdog chip. With
> > > this chip you can configure a "window" which can detect early faults
> > > (i.e. too frequent) in addition to the standard watchdog features. I
> > > needed to add this minimum timeout to avoid watchdog resets in
> > > situations such as where first U-Boot and then the Linux kernel feed
> > > the watchdog with too short of an interval between them, or when
> > > systemd was configured to use the watchdog device and was feeding it
> > > too soon after taking over from the kernel.
> > >
> > > > > Can you just hardcode some min? Maybe 10% of the max or something. Is
> > > > > there a downside to a larger than necessary min?
> > > > >
> > > >
> > > > That would result in extra overhead in the watchdog core which would not
> > > > be required for all other hardware using this driver. I'd rather avoid that.
> > > >
> > >
> > > In the case of the TI TPS3850, the minimum timeout is configurable, so
> > > I didn't want to add a hard-coded value to the driver.
> > >
> > > > > Wouldn't be better to fix this without requiring a DT change and that
> > > > > could work on stable kernels if needed.
> > > > >
> > > >
> > > > Presumably that is some new hardware. Most of the watchdog drivers
> > > > needing this value can derive it from the compatible property. The
> > > > gpio watchdog driver is a bit different since it is supposed to work
> > > > on a variety of hardware using gpio pins for watchdog control.
> > > >
> > >
> > > Yes this is new hardware. This use case is also not very common as
> > > most watchdog chips don't have this window function or a minimum
> > > interval, at least in my experience, so I did not want to make it the
> > > default for everything.
> >
> > Okay. However the existing property you copied has 2 problems. It uses
> > underscores rather than hypens and doesn't use a standard unit suffix.
> > So 'min-hw-margin-ms'.
> >
> > Though maybe a new property instead:
> >
> > timeout-range-ms = <min max>;
> >
> > That's somewhat aligned to 'timeout-sec', and IMO, clearer meaning than
> > 'hw margin'.
> >
> > Rob
> 
> I agree that both the original property name and the new one aren't
> great, but I didn't want to go changing the existing property for
> everyone.  I could definitely add a new "timeout-range-ms" property -
> should that be added in parallel to the original hw_margin_ms (i.e.
> you can use one or the other), or completely replace the original?

I wonder how that made it in in the first place. Embarrassed ...
of course it wasn't reviewed by a DT maintainer. I'd suggest to mark
the old property as deprecated (if that is possible) and define
the new one.

Guenter

Re: [PATCH 2/2] watchdog: gpio: add configurable minimum interval

[Rob Herring]

On Fri, Jul 08, 2022 at 04:44:25AM -0700, Guenter Roeck wrote:
> On Thu, Jul 07, 2022 at 11:00:45AM +0200, Isaac True wrote:
> > On Tue, 5 Jul 2022 at 21:56, Rob Herring <robh@kernel.org> wrote:
> > >
> > > On Mon, Jul 04, 2022 at 01:05:04PM +0200, Isaac True wrote:
> > > > On Fri, 1 Jul 2022 at 19:48, Guenter Roeck <linux@roeck-us.net> wrote:
> > > > >
> > > > > On 7/1/22 10:18, Rob Herring wrote:
> > > > > > On Wed, Jun 29, 2022 at 01:06:26PM +0200, Isaac True wrote:
> > > > > >> Add the "min_hw_margin_ms" parameter to gpio_wdt devices, allowing a
> > > > > >> minimum interval to be specified, stopping watchdog devices from being
> > > > > >> fed too quickly if they require a certain interval between feeds.
> > > > > >
> > > > > > I assume there is some real platform with a real problem you are trying
> > > > > > to solve? Details please.
> > > > > >
> > > > >
> > > > > Agreed, this should be explained in more detail.
> > > >
> > > > Yes this is a real platform using a TI TPS3850 watchdog chip. With
> > > > this chip you can configure a "window" which can detect early faults
> > > > (i.e. too frequent) in addition to the standard watchdog features. I
> > > > needed to add this minimum timeout to avoid watchdog resets in
> > > > situations such as where first U-Boot and then the Linux kernel feed
> > > > the watchdog with too short of an interval between them, or when
> > > > systemd was configured to use the watchdog device and was feeding it
> > > > too soon after taking over from the kernel.
> > > >
> > > > > > Can you just hardcode some min? Maybe 10% of the max or something. Is
> > > > > > there a downside to a larger than necessary min?
> > > > > >
> > > > >
> > > > > That would result in extra overhead in the watchdog core which would not
> > > > > be required for all other hardware using this driver. I'd rather avoid that.
> > > > >
> > > >
> > > > In the case of the TI TPS3850, the minimum timeout is configurable, so
> > > > I didn't want to add a hard-coded value to the driver.
> > > >
> > > > > > Wouldn't be better to fix this without requiring a DT change and that
> > > > > > could work on stable kernels if needed.
> > > > > >
> > > > >
> > > > > Presumably that is some new hardware. Most of the watchdog drivers
> > > > > needing this value can derive it from the compatible property. The
> > > > > gpio watchdog driver is a bit different since it is supposed to work
> > > > > on a variety of hardware using gpio pins for watchdog control.
> > > > >
> > > >
> > > > Yes this is new hardware. This use case is also not very common as
> > > > most watchdog chips don't have this window function or a minimum
> > > > interval, at least in my experience, so I did not want to make it the
> > > > default for everything.
> > >
> > > Okay. However the existing property you copied has 2 problems. It uses
> > > underscores rather than hypens and doesn't use a standard unit suffix.
> > > So 'min-hw-margin-ms'.
> > >
> > > Though maybe a new property instead:
> > >
> > > timeout-range-ms = <min max>;
> > >
> > > That's somewhat aligned to 'timeout-sec', and IMO, clearer meaning than
> > > 'hw margin'.
> > >
> > > Rob
> > 
> > I agree that both the original property name and the new one aren't
> > great, but I didn't want to go changing the existing property for
> > everyone.  I could definitely add a new "timeout-range-ms" property -
> > should that be added in parallel to the original hw_margin_ms (i.e.
> > you can use one or the other), or completely replace the original?
> 
> I wonder how that made it in in the first place. Embarrassed ...
> of course it wasn't reviewed by a DT maintainer. I'd suggest to mark
> the old property as deprecated (if that is possible) and define
> the new one.

Seems doable. Only 1 user upstream.

Also, note that there is also 'rohm,hw-timeout-ms' which is a range.

Rob