All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marek Behun <marek.behun@nic.cz>
To: Guenter Roeck <linux@roeck-us.net>
Cc: linux-watchdog@vger.kernel.org, wim@linux-watchdog.org
Subject: Re: [PATCH 1/2] watchdog: Add support for Armada 37xx CPU watchdog
Date: Thu, 30 Aug 2018 20:42:23 +0200	[thread overview]
Message-ID: <20180830204223.391d6066@nic.cz> (raw)
In-Reply-To: <20180830162853.GA27086@roeck-us.net>

On Thu, 30 Aug 2018 09:28:53 -0700
Guenter Roeck <linux@roeck-us.net> wrote:

> >  .../bindings/watchdog/armada-37xx-wdt.txt          |  23 ++  
> 
> Deviceptree properties need to be in a separate patch and have to be
> approved by devicetree maintainers.

OK :) I will divide the patch. Should I add devicetree maintainers to
Cc? Who is then responsible for applying the devicetree property, them
or you?

> > +config ARMADA_37XX_WATCHDOG
> > +	tristate "Armada 37xx watchdog"
> > +	depends on ARCH_MVEBU || COMPILE_TEST  
> 
> Did you test this with a couple of architectures ?

This watchdog si specific to Armada 3720, which currently means
EspressoBin and Turris Mox. I don't think another vendor would create a
SOC with same structure for watchdog as this. I also don't have access
to other boards. This works on EspressoBin and Turris Mox.

> > +static unsigned int timeout = WATCHDOG_TIMEOUT;  
> 
> This defeats the purpose of using watchdog_init_timeout() to get a
> value from devicetree. That value will never be used.

I shall rewrite this in the next version.

> > +static u64 get_counter_value(struct armada_37xx_watchdog *dev)
> > +{
> > +	u64 val;
> > +
> > +	val = readl(dev->reg + CNTR_COUNT_HIGH);
> > +	val = (val << 32) | readl(dev->reg + CNTR_COUNT_LOW);  
> 
> Is this guaranteed to be consistent ? What happens if there is a
> 32-bit wrap between those two operations ?

hmmm. The address is not divisible by 8, so I can't use readq :( what
do you propose?

> > +static int armada_37xx_wdt_ping(struct watchdog_device *wdt)
> > +{
> > +	struct armada_37xx_watchdog *dev =
> > watchdog_get_drvdata(wdt); +
> > +	armada_37xx_wdt_counter_disable(dev);
> > +	set_counter_value(dev);
> > +	armada_37xx_wdt_counter_enable(dev);
> > +  
> 
> Is it really necessary to stop the watchdog for each ping ? That
> leaves the system in a vulnerable state. Or does CNTR_CTRL_ENABLE
> only enable writing into the counter register ?

Well, it probably is possible to do this without stopping the watchdog,
but two counters would need to be used for this. A trigger can be set
to counter 1 to start counting from initial value when counter 2 ended.
I will have to try if it works, though.

> > +static int armada_37xx_wdt_start(struct watchdog_device *wdt)
> > +{
> > +	struct armada_37xx_watchdog *dev =
> > watchdog_get_drvdata(wdt);
> > +	u32 reg;
> > +
> > +	reg = readl(dev->reg + CNTR_CTRL);
> > +
> > +	if (reg & CNTR_CTRL_ACTIVE)
> > +		return -EBUSY;  
> 
> This is highly unusual. What problem are you solving here ?

Hmm, you are right, this should not happen if the rest of this driver
works well so that code is redundant.

> > +	ret = clk_prepare_enable(dev->clk);
> > +	if (ret)
> > +		return ret;
> > +
> > +	dev->clk_rate = clk_get_rate(dev->clk);  
> 
> Some clock drivers can return 0 here, which would result in a
> division by 0 later. It is prudent to check the return value.

Yes, I shall do that.

> > +
> > +	/*
> > +	 * Since the timeout in seconds is given as 32 bit
> > unsigned int, and
> > +	 * the counters hold 64 bit values, even after
> > multiplication by clock
> > +	 * rate the counter can hold timeout of UINT_MAX seconds.
> > +	 */
> > +	dev->wdt.min_timeout = 0;  
> 
> That value is set to 1 above, which makes more sense. What is the
> point of setting it to 0 here, and what is the impact of setting the
> actual timeout to 0 ? Are you sure that doesn't result in an
> immediate reboot ?

Yes, setting it to 0 does immediate reset. The = 1 line is redundant,
sorry.

> > +	armada_37xx_wdt_set_timeout(&dev->wdt, dev->wdt.timeout);
> > +
> > +	if (armada_37xx_wdt_is_running(dev))
> > +		set_bit(WDOG_HW_RUNNING, &dev->wdt.status);
> > +	else
> > +		armada_37xx_wdt_stop(&dev->wdt);  
> 
> Why stop it if it isn't running ?

There are 4 counters and every one of them can be set to be a watchdog
counter. This driver, as described in the commit message, works with
counter ID 1. The armada_37xx_wdt_stop unsets all 4 counters from
being watchdog counters, so that if something, for example u-boot, set
another counter as watchdog counter, the system would not reboot.

If you think this shouldn't be done I shall take it away, and rewrite
armada_37xx_wdt_stop to only touch counter ID 1.

Marek

  reply	other threads:[~2018-08-30 18:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-30 14:22 [PATCH 1/2] watchdog: Add support for Armada 37xx CPU watchdog Marek Behún
2018-08-30 14:22 ` [PATCH 2/2] arm64: dts: marvell: armada-37xx: add nodes to support watchdog Marek Behún
2018-08-30 14:28 ` [PATCH 1/2] watchdog: Add support for Armada 37xx CPU watchdog Marek Behun
2018-08-30 14:40   ` Guenter Roeck
2018-08-30 16:28 ` Guenter Roeck
2018-08-30 18:42   ` Marek Behun [this message]
2018-08-30 18:50     ` Marek Behun
2018-08-30 19:12       ` Guenter Roeck
2018-09-01  0:29         ` Marek Behun
2018-09-01  0:47           ` Guenter Roeck
2018-09-02 20:12             ` Marek Behun
2018-09-03  0:55               ` Guenter Roeck
2018-08-30 19:07     ` Guenter Roeck

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=20180830204223.391d6066@nic.cz \
    --to=marek.behun@nic.cz \
    --cc=linux-watchdog@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.