linux-watchdog.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Guenter Roeck <linux@roeck-us.net>
To: Chris Packham <Chris.Packham@alliedtelesis.co.nz>,
	"wim@linux-watchdog.org" <wim@linux-watchdog.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"linux-watchdog@vger.kernel.org" <linux-watchdog@vger.kernel.org>
Subject: Re: [PATCH v4] watchdog: orion_wdt: use timer1 as a pretimeout
Date: Thu, 29 Aug 2019 05:34:15 -0700	[thread overview]
Message-ID: <ef5d2227-90ad-19d4-5d40-5cd21c669266@roeck-us.net> (raw)
In-Reply-To: <6da9aaef9d1dab3436dc9204edf94ef0782dde00.camel@alliedtelesis.co.nz>

On 8/28/19 10:05 PM, Chris Packham wrote:
> On Wed, 2019-08-28 at 21:45 -0700, Guenter Roeck wrote:
>> On 8/28/19 6:53 PM, Chris Packham wrote:
>>> The orion watchdog can either reset the CPU or generate an interrupt.
>>> The interrupt would be useful for debugging as it provides panic()
>>> output about the watchdog expiry, however if the interrupt is used the
>>> watchdog can't reset the CPU in the event of being stuck in a loop with
>>> interrupts disabled or if the CPU is prevented from accessing memory
>>> (e.g. an unterminated DMA).
>>>
>>> The Armada SoCs have spare timers that aren't currently used by the
>>> Linux kernel. We can use timer1 to provide a pre-timeout ahead of the
>>> watchdog timer and provide the possibility of gathering debug before the
>>> reset triggers.
>>>
>>> Signed-off-by: Chris Packham <chris.packham@alliedtelesis.co.nz>
>>> ---
>>>
>>> This was submitted previously[1], the other patches two from the series have
>>> been picked up but this one seems to have fallen through the gaps.
>>>
>>
>> I had marked it as "under review" but I don't recall why. Maybe it was because
>> it depended on the other patches, but I don't recall, and I didn't keep track
>> of those patches either. Sorry for that.
>>
> 
> No problem. I think it was related to discussions around the other
> patches. I had meant to follow up earlier.
> 
>>> Changes in v3:
>>> - rebase against linux/master
>>> Changes in v2:
>>> - apply changes to armada-38x only
>>>
>>> [1] - https://lore.kernel.org/linux-watchdog/20190305201924.14853-4-chris.packham@alliedtelesis.co.nz/
>>>
>>>    drivers/watchdog/orion_wdt.c | 59 ++++++++++++++++++++++++++++++------
>>>    1 file changed, 50 insertions(+), 9 deletions(-)
>>>
>>> diff --git a/drivers/watchdog/orion_wdt.c b/drivers/watchdog/orion_wdt.c
>>> index cdb0d174c5e2..f2e90bfd7186 100644
>>> --- a/drivers/watchdog/orion_wdt.c
>>> +++ b/drivers/watchdog/orion_wdt.c
>>> @@ -46,6 +46,11 @@
>>>    #define WDT_AXP_FIXED_ENABLE_BIT BIT(10)
>>>    #define WDT_A370_EXPIRED	BIT(31)
>>>    
>>> +#define TIMER1_VAL_OFF		0x001c
>>> +#define TIMER1_ENABLE_BIT	BIT(2)
>>> +#define TIMER1_FIXED_ENABLE_BIT	BIT(12)
>>> +#define TIMER1_STATUS_BIT	BIT(8)
>>> +
>>
>> It would be better to group the bits associated with a single register together.
>> The bits above are not associated with TIMER1_VAL_OFF, yet the grouping suggests
>> that this may be the case.
> 
> Will fix.
> 
>>
>>>    static bool nowayout = WATCHDOG_NOWAYOUT;
>>>    static int heartbeat = -1;		/* module parameter (seconds) */
>>>    
>>> @@ -158,6 +163,7 @@ static int armadaxp_wdt_clock_init(struct platform_device *pdev,
>>>    				   struct orion_watchdog *dev)
>>>    {
>>>    	int ret;
>>> +	u32 val;
>>>    
>>>    	dev->clk = of_clk_get_by_name(pdev->dev.of_node, "fixed");
>>>    	if (IS_ERR(dev->clk))
>>> @@ -169,38 +175,48 @@ static int armadaxp_wdt_clock_init(struct platform_device *pdev,
>>>    	}
>>>    
>>>    	/* Enable the fixed watchdog clock input */
>>> -	atomic_io_modify(dev->reg + TIMER_CTRL,
>>> -			 WDT_AXP_FIXED_ENABLE_BIT,
>>> -			 WDT_AXP_FIXED_ENABLE_BIT);
>>> +	val = WDT_AXP_FIXED_ENABLE_BIT | TIMER1_FIXED_ENABLE_BIT;
>>
>> This always sets TIMER1_FIXED_ENABLE_BIT, but later the enable bit is set
>> only conditionally. I don't know what is correct, but this asks for a comment.
> 
> The fixed part is safe to set. It just means that the rate is constant.
> I'll add a comment.
> 
>>
>>> +	atomic_io_modify(dev->reg + TIMER_CTRL, val, val);
>>>    
>>>    	dev->clk_rate = clk_get_rate(dev->clk);
>>> +
>>
>> We can only hope we won't see another patch two days from now where someone
>> removes this added line.
>>
>> I can understand such changes if they fix a checkpatch issue,
>> but otherwise please refrain from whitespace changes.
> 
> I think it was to appease checkpatch, the one below certainly was. If
> it's not needed for checkpatch I'll drop it in the next version.
> 
>>
>>>    	return 0;
>>>    }
>>>    
>>>    static int orion_wdt_ping(struct watchdog_device *wdt_dev)
>>>    {
>>>    	struct orion_watchdog *dev = watchdog_get_drvdata(wdt_dev);
>>> +
>>>    	/* Reload watchdog duration */
>>>    	writel(dev->clk_rate * wdt_dev->timeout,
>>>    	       dev->reg + dev->data->wdt_counter_offset);
>>> +	if (dev->wdt.info->options & WDIOF_PRETIMEOUT)
>>> +		writel(dev->clk_rate * (wdt_dev->timeout - wdt_dev->pretimeout),
>>> +		       dev->reg + TIMER1_VAL_OFF);
>>> +
>>>    	return 0;
>>>    }
>>>    
>>>    static int armada375_start(struct watchdog_device *wdt_dev)
>>>    {
>>>    	struct orion_watchdog *dev = watchdog_get_drvdata(wdt_dev);
>>> -	u32 reg;
>>> +	u32 reg, val;
>>>    
>>
>> Is the second variable here and below really necessary ?
>>
> 
> No I can use reg.
> 
>>>    	/* Set watchdog duration */
>>>    	writel(dev->clk_rate * wdt_dev->timeout,
>>>    	       dev->reg + dev->data->wdt_counter_offset);
>>> +	if (dev->wdt.info->options & WDIOF_PRETIMEOUT)
>>> +		writel(dev->clk_rate * (wdt_dev->timeout - wdt_dev->pretimeout),
>>> +		       dev->reg + TIMER1_VAL_OFF);
>>>    
>>>    	/* Clear the watchdog expiration bit */
>>>    	atomic_io_modify(dev->reg + TIMER_A370_STATUS, WDT_A370_EXPIRED, 0);
>>>    
>>>    	/* Enable watchdog timer */
>>> -	atomic_io_modify(dev->reg + TIMER_CTRL, dev->data->wdt_enable_bit,
>>> -						dev->data->wdt_enable_bit);
>>> +	val = dev->data->wdt_enable_bit;
>>> +	if (dev->wdt.info->options & WDIOF_PRETIMEOUT)
>>> +		val |= TIMER1_ENABLE_BIT;
>>> +	atomic_io_modify(dev->reg + TIMER_CTRL, val, val);
>>>    
>>>    	/* Enable reset on watchdog */
>>>    	reg = readl(dev->rstout);
>>> @@ -277,7 +293,7 @@ static int orion_stop(struct watchdog_device *wdt_dev)
>>>    static int armada375_stop(struct watchdog_device *wdt_dev)
>>>    {
>>>    	struct orion_watchdog *dev = watchdog_get_drvdata(wdt_dev);
>>> -	u32 reg;
>>> +	u32 reg, mask;
>>>    
>>>    	/* Disable reset on watchdog */
>>>    	atomic_io_modify(dev->rstout_mask, dev->data->rstout_mask_bit,
>>> @@ -287,7 +303,10 @@ static int armada375_stop(struct watchdog_device *wdt_dev)
>>>    	writel(reg, dev->rstout);
>>>    
>>>    	/* Disable watchdog timer */
>>> -	atomic_io_modify(dev->reg + TIMER_CTRL, dev->data->wdt_enable_bit, 0);
>>> +	mask = dev->data->wdt_enable_bit;
>>> +	if (wdt_dev->info->options & WDIOF_PRETIMEOUT)
>>> +		mask += TIMER1_ENABLE_BIT;
>>
>> FWIW, += is a bit unusual for a mask. Is it guaranteed that
>> the bit is never already set ? Any special reason for using +=
>> instead of |= here, but not above ?
>>
> 
> I have no idea why on earth I used +=, slip of the keyboard perhaps, |=
> is obviously the correct thing to use.
> 
>>> +	atomic_io_modify(dev->reg + TIMER_CTRL, mask, 0);
>>>    
>>>    	return 0;
>>>    }
>>> @@ -349,7 +368,7 @@ static unsigned int orion_wdt_get_timeleft(struct watchdog_device *wdt_dev)
>>>    	return readl(dev->reg + dev->data->wdt_counter_offset) / dev->clk_rate;
>>>    }
>>>    
>>> -static const struct watchdog_info orion_wdt_info = {
>>> +static struct watchdog_info orion_wdt_info = {
>>>    	.options = WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING | WDIOF_MAGICCLOSE,
>>>    	.identity = "Orion Watchdog",
>>>    };
>>> @@ -368,6 +387,16 @@ static irqreturn_t orion_wdt_irq(int irq, void *devid)
>>>    	return IRQ_HANDLED;
>>>    }
>>>    
>>> +static irqreturn_t orion_wdt_pre_irq(int irq, void *devid)
>>> +{
>>> +	struct orion_watchdog *dev = devid;
>>> +
>>> +	atomic_io_modify(dev->reg + TIMER_A370_STATUS,
>>> +			 TIMER1_STATUS_BIT, 0);
>>> +	watchdog_notify_pretimeout(&dev->wdt);
>>> +	return IRQ_HANDLED;
>>> +}
>>> +
>>>    /*
>>>     * The original devicetree binding for this driver specified only
>>>     * one memory resource, so in order to keep DT backwards compatibility
>>> @@ -589,6 +618,18 @@ static int orion_wdt_probe(struct platform_device *pdev)
>>>    		}
>>>    	}
>>>    
>>> +	irq = platform_get_irq(pdev, 1);
>>
>> platform_get_irq() may return -EPROBE_DEFER. Are you sure you want to ignore
>> the interrupt (and thus disable the pretimeout) if that is the case ?
>>
> 
> In any current system that uses this driver I can't imagine a case
> where we would see -EPROBE_DEFER here and not for the index 0 interrupt
> above. And even then these are SoC interrupt sources so it's unlikely
> that they would be deferred.
> 
> I do need to handle the case where the 2nd irq is not provided (which
> is what I was going for here). IMHO I think it's better to get on with
> things rather than deferring the entire driver probe just because an
> optional feature isn't ready for use. But if you want me to handle
> -EPROBE_DEFER here I will.
> 

Your call, but maybe add a comment to avoid future questions.

Thanks,
Guenter

>>> +	if (irq > 0) {
>>> +		orion_wdt_info.options |= WDIOF_PRETIMEOUT;
>>> +		ret = devm_request_irq(&pdev->dev, irq, orion_wdt_pre_irq,
>>> +				       0, pdev->name, dev);
>>> +		if (ret < 0) {
>>> +			dev_err(&pdev->dev, "failed to request IRQ\n");
>>> +			goto disable_clk;
>>> +		}
>>> +	}
>>> +
>>> +
>>>    	watchdog_set_nowayout(&dev->wdt, nowayout);
>>>    	ret = watchdog_register_device(&dev->wdt);
>>>    	if (ret)
>>>
>>
>>


      reply	other threads:[~2019-08-29 12:34 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-29  1:53 [PATCH v4] watchdog: orion_wdt: use timer1 as a pretimeout Chris Packham
2019-08-29  4:45 ` Guenter Roeck
2019-08-29  5:05   ` Chris Packham
2019-08-29 12:34     ` Guenter Roeck [this message]

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=ef5d2227-90ad-19d4-5d40-5cd21c669266@roeck-us.net \
    --to=linux@roeck-us.net \
    --cc=Chris.Packham@alliedtelesis.co.nz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-watchdog@vger.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;
as well as URLs for NNTP newsgroup(s).